3 AGILE FRAMEWORKS

Scrum

How does Scrum work?  Here's a quick summary:

• A team works in short timeboxes (called Sprints), typically 2-4 weeks long but do not exceed a calendar month. 
• An ordered list of work needed for the product called the Product Backlog is created.
• Before each Sprint, the Scrum Team co-creates a Sprint Goals for that Sprint, and they select necessary Product Backlog Items to deliver that goal. 
• Each day, the team meets for no more than 15 minutes in a Daily Scrum meeting to discuss progress towards the Sprint Goal and make any necessary plan changes.
• At the end of the Sprint, the completed work should be in a state that meets the definition of done (DoD) and is ready for release.  
• The Scrum Team then holds a Sprint Review where they review what was accomplished, gather feedback, and discuss what they will do next.
• The Scrum Team then inspects the Sprint during a Sprint Retrospective and reflects on what they have learned and what they can improve upon for the next Sprint.  

Kanban

Kanban developed as a subcomponent of the Toyota Production System and has its origins in these Lean and Just In Time (JIT) manufacturing processes.

In Kanban the workflow is visualised: work is broken down into small, discrete items and written on a card which is stuck to a board; the board has different columns and as the work progresses through different stages (e.g., ready, in progress, ready for review etc) the card is moved accordingly.

In Kanban the number of items that can be in progress at any one time is strictly limited. This is different from Scrum as it encourages flow and seeks to keep work items from being stuck, blocked, or delayed. The idea is that the team works on fewer items, focusing on reducing the time spent on each development stage. This way, there is not a lot of time between when tasks or features start and finish.

The average time it takes to complete an item (sometimes called the ‘cycle time’) is tracked and optimised so that the process becomes as efficient and predictable as possible. The elimination of waste is paramount.

There are fundamental guidelines for implementing Kanban:

• Work in progress: The key to Kanban is to limit the number of items in development (tasks or features), not so you do less, but so you define and visualize the workflow. Collectively decide and place all work items on a wall and use columns to show their status. This allows the team and the whole office to see the progress.
• Actively manage the flow: By analyzing where items get stuck, blocked, or slowed down, you can identify (and then remove) situations where there are too many tasks in a short time frame (bottlenecks). The Kanban system team should always work to unblock items as quickly as possible.
• Improve the workflow: Continuous improvement and teamwork are vital concepts in Kanban. 

Extreme Programming (XP)

Extreme Programming (or XP) is an agile framework that focuses a lot on the quality of practice and the habits of the software practitioner (i.e., the developers on the team). It is a framework which focuses heavily on ensuring the quality of delivered software and which prescribes engineering solutions towards that end.

Its main guidelines are as follows:

• Developers will adhere to coding standards, all writing code the same way.
• Use test-driven development. In this process, developers write the code for a test that a feature should pass (or validate) before proceeding. It is a key part of XP.
• Developers write code in pairs. Usually, one developer writes the test code, and the other writes feature code.
• Work is done in short iterations (usually two weeks), and planning happens before each iteration.
• Just enough design and architecture are involved in building the features for the current iteration.
• Code is frequently checked against the master code base to instantly detect errors (this is called continuous integration of code with the code base).

An XP team (comprised of all who contribute to the project) engage in Release Planning and Iteration Planning. They work in very short development cycles so that changes requested by the customer (who works on-site with the team) can be incorporated frequently.

Through more than a dozen core practices which include Test Driven Development, Customer Testing, Continuous Integration, Small Releases and Pair Programming, XP works towards a continuously improving, high quality product which can respond to changes in customer requirements.

 

COMPARISONS

Kanban vs Scrum

Scrum is more prescriptive than Kanban, which eschews defining roles and teams and which has no formal structure of meetings. Kanban doesn’t prescribe iterations either – though they can be incorporated if desired.

The process visualisation techniques of Kanban make it ideally suited to co-located teams who are working on a backlog of items that is subject to frequent change (for example, Kanban is often used by support teams).

The Kanban board though is often adopted by Scrum teams in the form of a task board and is used to track progress throughout a sprint.

The limit to Work In Progress rule in Kanban also makes it suitable for teams with limited resources or where input from every member is required on each item. This could apply, for example, to a communications team within a large organisation.

While Scrum limits the amount of work going into each sprint, the workload is determined by the relative estimation of the size of each story (in points) and is agreed by the Scrum team in each planning session.

While a Kanban team tracks ‘cycle time’ and optimises for lead times that are as short and as predictable as possible, a Scrum team aims to improve its output over successive sprints and to improve the ‘velocity’ of the team (the number of relative estimation points completed in a sprint). This arguably makes Scrum more suitable for scaling – it certainly feels more familiar and predictable which can be reassuring for large organisations.

Scrum vs XP

In Scrum, teams and meetings are fairly set in stone whereas the question of how work actually gets done is left to the teams to decide themselves. XP on the other hand comes with a set of core practices that could seem overwhelming to the Agile beginner.

It could be said that Scrum is a methodology, which is more concerned with productivity while XP is more concerned with engineering.

The value that XP practices can add though is undisputable and many organisations which use Scrum adopt Pair Programming, Test Driven Development and Refactoring as practices which improve quality, speed up the release process and/or reduce the need to revisit work due to technical debt.

Alongside shorter iterations, some other important things which differentiate XP from Scrum are:

•      XP teams work on items in a strict priority order whereas a Scrum team might not necessarily tackle each item in priority order once in sprint
•       XP teams can bring new items of work into an iteration and switch out items of equivalent size (as long as they haven’t been started) if the customer decides on a new priority
•      In terms of similarities, the role of the customer in XP is very similar to that of the Product Owner in Scrum – in that they help write user stories, prioritise them and are always available to developers – though less well defined.
•       Both Scrum and XP mandate a daily stand up meeting.
•       While both stress the importance of co-location, only XP makes it deal-breaker.

All three methodologies adhere to the principals laid out in the Agile Manifesto which aims at providing as much value to customers as possible in the time available. The differences between them are a result of trying to uphold the Agile principles in radically different contexts.

Kanban is a really useful way for teams with a continually changing backlog of items to increase efficiency by limiting the amount of work-in-progress, whilst respecting existing roles and responsibilities.

Scrum is more suitable for teams who can devote their collective time to a project or product. It brings much more in the way of structure to help teams make major productivity gains through frequent communication and planning while still providing the freedom to decide among themselves how to engineer solutions.

XP adds another level of sophistication, bringing a strong focus on quality by insisting on a set of core engineering practices which keeps code clean and software stable.

As we’ve seen in the comparisons, elements can be added/subtracted from a methodology to find a framework that fits your specific context. It might take a bit of trial and error to get there, but if you keep the Agile principles foremost in your thinking you’ll undoubtedly be on the right path.

Conclusion

The object of this comparison was never to choose a ‘best’ methodology but to explore the differences between them and to tease out potential reasons for choosing one over another in a specific scenario.

All three methodologies adhere to the principals laid out in the Agile Manifesto which aims at providing as much value to customers as possible in the time available. The differences between them are a result of trying to uphold the Agile principles in radically different contexts.

Kanban is a really useful way for teams with a continually changing backlog of items to increase efficiency by limiting the amount of work-in-progress, whilst respecting existing roles and responsibilities.

Scrum is more suitable for teams who can devote their collective time to a project or product. It brings much more in the way of structure to help teams make major productivity gains through frequent communication and planning while still providing the freedom to decide among themselves how to engineer solutions.

XP adds another level of sophistication, bringing a strong focus on quality by insisting on a set of core engineering practices which keeps code clean and software stable.

As we’ve seen in the comparisons, elements can be added/subtracted from a methodology to find a framework that fits your specific context. It might take a bit of trial and error to get there, but if you keep the Agile principles foremost in your thinking you’ll undoubtedly be on the right path. 

Coach Ram
www.coach-ram.in