Best Practices from Agile Frameworks

As the Agile Manifesto is a set of abstract principles without sufficient clarity, its principles are often used with several process driven and practice oriented frameworks. There are many flavors of Agile such as Extreme Programming (XP), Feature-Driven Development (FDD), Adaptive System Development (ASD), Dynamic Systems Development Management (DSDM), Lean Software Development (LSD) and Test Driven Development (TDD) among others which complement each other and at the same time, bring something unique to the table. Assuming Agile Scrum Methodology is what we will fundamentally use (the highlights of which I have covered in my article Agile Scrum Methodology on Steroids), here I cherry pick unique and key aspects from other popular frameworks that one can integrate to improve the development cycle further.     

 

1)    Xtreme Programming (XP) – Concepts one can take forward from this include Pair Programming, Mob Programming and Spikes.

a)    Pair Programming - It is a practice where two programmers share a single workstation to code together. This is an efficient practice to on board a new member of the team so the individual can come up to speed with the good design practices and coding standards that are followed by one’s team to prevent technical debt in the near future. Some teams use Pair Programming on a regular basis to prevent extra time spent on Peer Code Review which is another practice suggested here. Additionally, when a Sprint deadline is fast approaching and the Developer is struggling to deliver the required feature/functionality, s/he could be paired with a Senior Member of the team to achieve results faster.

b)    Mob Programming – Sometimes certain Business Logics could be hard to program and uncertainty plays on the minds of the Programmer. During such times, Mob Programming is suggested wherein a part of or the entire team discuss a logical approach to it on a whiteboard followed by sitting around a machine and taking turns of 4 or 5 minute at coding. This also applies when fixing Bugs that have been otherwise proven hard to resolve. It is a good team building exercise which helps the team grow, become more efficient, learn how to get work done and most importantly, improve the competency of inexperienced Developers.

c)    Spikes - They are primarily exploratory activities such as research, design, investigation and prototyping performed towards developing a Proof of Concept. This can be approached by requesting insights from the team, reviewing the technical requirements, analyze the risk and complexity, making a build-versus-buy decision among others. This is then converted into a User Story, placed in the Backlog, estimated and scheduled in a Sprint.

Test Driven Development was first brought to light under Xtreme Programming but we will cover it in the next point as there exists a Methodology of its own.

 

2)    Test Driven Development (TDD) – It recommends the conversion of the User Stories /Functional Specifications to multiple Test Cases covering requirements, specific use cases and exception conditions before the commencement of coding. The flow of this methodology requires

a)      Writing a unit test first

b)      confirming that it fails 

c)       Followed by focusing on writing only the code necessary to pass the test (i.e. this way, it is often cleaner and clearer)

d)      Repeating the Test till it passes

e)      Refactoring and then repeating the above process as code is added

The above points ensure that code will be more modularized, flexible and extensible as the developer thinks of the software in terms of small units that can be written and tested independently and integrated together later.

This prevents the popular Agile anti pattern of having Code Freezes so QA can test the current iteration.

It suggests that growing code base be cleaned up regularly, duplicates removed, new code moved to where it logically belongs among others. This leads to smaller, more focused classes, looser coupling and cleaner interfaces.

 

3)    Kanban Board: It is a control system used to

a)      Improve the Cycle Time by analyzing the workflow and identifying blockers and bottlenecks. This is achieved by the use of a board with sticky notes comprising of 4 swim lanes namely To Do, In Progress, UAT and Done

b)      Limit Work In Progress (WIP) by placing only limited number of work items in the “To Do” lane that matches the team’s capacity. This helps the team focus.

c)       Encourage pull wherein a team member can pull the top most work item from the Backlog as soon as they have bandwidth to take on more work.

d)      Build transparency by depicting real time status for any piece of work on the board.

One needs to take note of a couple of key differences between Scrum and Kanban. They are:

  • Scrum is based on fixed length Sprints (i.e. 2 or 4 week cycles) and release is at the end of it whereas Kanban suggest continuous development and deployment eliminating the need for making estimates and hence, the time spent towards it.
  • The measure of delivery in Scrum is Velocity and in Kanban, Cycle Time.

Hence, a team has to choose one of the two practices with respect to the above mentioned aspects. That said, the visual nature of how work flows through the development cycle is what makes Kanban appealing. Hence, teams integrate the board and sticky notes practice into their Agile Scrum Methodology.

Some teams blend the ideas of Kanban and Scrum into Scrumban. They take fixed length sprints and roles from scrum and the focus on work in progress limits and cycle time from Kanban.

For teams starting out, I would recommend Scrum and as the team evolves into a highly skilled and dependable workforce, one can move to Kanban. 

4) Lean Software Development (LSD) – While the Agile Manifesto values individuals and interactions over Processes and Tools, efficiency can only be driven through a process that helps identifying waste, eliminate bottlenecks and build transparency.

Following are some of the Lean improvements one can consider:

a)      Eliminate waiting time during handovers and prevent bottlenecks by the creation of a process map.

b)      Prevent Developers from multitasking as context switching kills efficiency. 

c)       Avoid re-work by introducing coding standards.

d)      Ensure Quality is built in through Test Driven Development. Acceptance Tests will ensure code with defects is not checked in. 

e)      Encourage Communication and build Transparency through colocation of teams, usage of collaborative work space, Osmotic communication and regular Agile meetings.  

Lean requires the team to focus on identifying the Minimum Viable Product (MVP) and delivering it first, after which, improvements can be made. It lays less emphasis on time boxed delivery and more on continuous deployment similar to Kanban.

 

5) Rational Unified Process (RUP): What makes it different is the fact that it requires one to define a proper scope, major milestones and specific dates. While a proper scope of work is not defined in Scrum and change is embraced, one can inculcate the RUP practice of defining major milestones and achieving them on specific dates. It also lays emphasis on the use of a component based Architecture that requires software components to be built for re-usability. Another take away from it is the fact that it is Risk Focused which requires the team to address the more critical risks first. 

In the next two articles, I will cover:

1) Agile Team Members and their roles.

2) Adopting Scalable Agile Frameworks.

About the Author: 


0 Comments

Leave a Comment