The third principle behind the Agile manifesto

The third principle of the Agile manifesto states

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Let us suppose you are the project manager for a project that is managed using traditional project management methods. Further, just suppose that the project is going through a particularly difficult phase where the tasks in the critical chain are beset by several issues that are stretching the plan. How would you see through this phase so that the plan is back on track? During 2007 I was part of a project that was similarly beset with a huge defect backlog. This was hampering new feature development and schedules were generally getting delayed. We were not using any Agile method to manage it, a sequential waterfall-like approach it was. The PM immediately swung into action and set up a plan to get things back in control. It was called Operation Arnold and terminating bugs was its mission! New development was (largely) suspended and all focus was on getting defects back in control. Work was prioritized on a daily basis. Developers and testers coordinated closely to ensure that all defects were closed as soon as possible and without regression. There were daily meetings in which developers and the managers participated. All progress was reviewed there and new work was prioritized. Special build setups were configured which facilitated daily builds to the testing team so as to facilitate daily feedback from testers. Again, back then we were not even aware of “Agile” in general and “Scrum” in particular but looking back I feel we were being Agile right there isn’t it? Of course, there was room for improvement but it cannot be denied that we were indeed being Agile. And I think the essence of the third principle of the Agile manifesto was right there – that we deliver working software frequently. Of course the “delivery” was not to an end customer and the delivery process was not a formal release process aimed at the end customer. Rather, this phase ensured disciplined high-quality deliveries on a continuous basis which I feel was the main intention of this principle.  Now, let us explore this a bit further.

The essence in any Agile practice is to keep seeking feedback from the work done, and the process used to do the work, to ensure that we are doing the right thing and in a right way. This feedback must be sought at optimum intervals. If the feedback comes too quick we might not have enough time to adjust, improve and respond. If the feedback is too late then we would have lost it already.

Why is it said so?

.Complexity can be managed only in quick bursts and with frequent reviews
Most Agile literature tends to use examples of driving a car, or predicting the movement of a cyclone, to explain complex systems and how they are managed. They might sound clichéd but they are also so true. In my personal experience, I have always been involved in software development projects which was at any time dependent on a few frameworks and libraries themselves involved in new feature development. Essentially it was an act in creating a new user experience out of several continuously moving parts. Add to it development teams located in different geographies and time-zones. Further add a competitive market where the developers’ skills were much valued and were always chased by suitors with attractive packages. This is all apart from the stiff competition from other SmartPhone players in the market. You can imagine the chaos inherent in this system. The only way out for our development teams then was to keep close communications with our customers to make sure we are developing what they wanted and not developing what they did not want. Close communications meant that working software was turned out in 2-week iterations to the customer and feedback sought. Any issues found would then be rectified within then the next delivery due in 2 weeks. If we were digressing from the plan it would be readily visible and we would have lost at max only 2 weeks.

.PDCA (Plan a little, Do a little, Check a little, Act a little).
This follows from the previous point about complexity. When the need is to keep a close loop of communication and feedback with the customer, working in small iterations makes sense. These iterations must run the whole gamut of software development lifecycle – planning, developing, testing, maintaining and releasing. Every iteration would then be focused on adding a little increment to the working product. The planning, development, verification and validation and other development related activities would be conducted just-enough and just-often-enough for the success of that iteration. Any effort or activity that does not contribute to this effort should be diligently identified and eliminated.

.How long can the customer wait after giving a new requirement until it’s delivery? And, how quickly can the development team move from getting a new requirement to it’s delivery?
The third principle quite aptly says that development teams work with a preference to the shorter timescale. The 2 questions above provide the key considerations that decide how long an iteration can be. A customer would want a requirement delivered as early as possible once the development team has started work on it. Now since the delivery should have the requirement to be working as desired and be of agreed quality standards, the delivery team needs some time for undisturbed development. This creative tension between the customer and the development team decides how frequently will working software be delivered. If the iteration duration is too small the development team will not have enough time to run through the PDCA cycle, and also not have enough time to act on the customer feedback. On the other hand, if the iteration is too long then the customer feedback comes too late in the day. If the team is digressing from the plan then delayed feedback means that the digression is not caught early enough. So we want the shorter timescale to be as short as optimally possible and no shorter.

.Frequent deliveries is frequent value unearthed.
Frequent deliveries provides opportunities for stakeholders and users to use the deliveries and provide feedback on it. This provides opportunities to unearth true customer experiences quicker. This also provides opportunities to identify deviations from plan, or incorrect experiences, quicker and correct the path that much easier. Most importantly, frequent deliveries aided by a fixed durations of iterations provides a perfect cadence to the development teams so they can commit to plans and deliver working software with increasing efficiency.

How is it put in practice?

Almost every Agile method prescribes an iterative delivery process.

Scrum names it’s iteration Sprint which is recommended to last between 2-4 weeks. It is recommended that teams choose one comfortable Sprint duration and stick to it. Again, the larger recommendation is to strike a steady rhythm so that feedback is received at optimum intervals, neither too early nor too late.

Similarly, XP stresses on the need for development teams to strike a Project Heartbeatsimilarly splits planning into Release planning and iteration planning.

Practitioners of Agile methods advocating a continuous flow, like Kanban for instance, too have devised ways to optionally devise iterations.

DSDM stresses on conducting its project lifecycle stages and sub-stages in successive iterations.

Lastly, an important technique that is used to practise this principle is the technique of Timeboxing. Briefly, this means that each activity in Agile software development is provided with a fixed time period within which the planned deliverables of the activity must be done. Importantly, for an Agile method to succeed, this means that the activity is considered complete when the timebox ends, regardless of whether the deliverable is ready or not. This kind of a disciplined approach ensures that the necessary feedback from the process surfaces and the correct learning is identified.

Other links

Related posts on this blog: 1, 2, 3

Other references used in this post:

1. The Agile manifesto
2. The principles of Agile software development
3. An explanation of Sprint [Wikipedia]
4. An introduction to project heartbeat
5. A blog post on conducting pseudo-iterations in Kanban
6. Home of DSDM-Atern
7. An introduction to iterative approach in DSDM [Wikipedia]
8. An entry on Timeboxing [Wikipedia]

One thought on “The third principle behind the Agile manifesto

  1. Pingback: The fourth principle behind the Agile manifesto | Being Nimble

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s