Agile lifecycle - the project side of life | CLEVR

Although iterative software development goes way back to the 1950’s, in the early 90’s the Agile Software Development group understood that a waterfall approach on software development was not sufficient enough to do rapid and flexible development. The Agile Manifesto was released in 2001 and explains how to do iterative development and the advantages of these methods. In a nutshell, the power of iterative development is short periods of development and a clear focus on the list of items to do. It is key to understand that you cannot predict the future and therefore must not spent a lot of time documenting that future. Just start building what you know and make sure you are agile enough to adapt to the changes along the way. From doing tons of waterfall and agile based development I noticed that the agile approach is a proven method and allows swift changes and continuous adjustments.

But you are not reading this blogpost because you want to know everything about agile development (you can read that here).
You are probably wondering how the agile approach can help you in the rest of the product lifecycle. Customers’ expectations are rising and that desperately asks for an agile way of doing projects. This is where the first hurdles need to be taken.

AGILE PROJECTS

There are a few methods in managing ICT based projects, but one of the commonly used ones is PRINCE (PRojects IN Controlled Environments). My project members and I noticed that with a PRINCE approach on projects we were not as flexible as we wanted to be. Writing large documents upfront was not a suitable solution for us, since the scope of the project changed before it was even started. So we thought; ‘what if we reflect the agile development approach on our projects?’
We had a list of items that needed to be developed, we had a person at the customer side that could act as a product owner and we had a project team that needed to build the list of items. Seems like all the ingredients for an agile project were there. We only needed to agree on the number of release cycles (sprints) and make sure we communicated about the items that are added to those sprints. Is it really as easy as it sounds?

Unfortunately it is not. Projects consist of three major aspects. Time, money and items to deliver. Within 80-90% of my projects, the customer wants all three aspects to be fixed. A customers tells you what he wants and wants to know when he can have it and how much it costs. This is a runway for disaster since a change on either one of the aspects will immediately result in a project scope change. To be able to have an agile project, one of the three aspects need to be fixed, the other two need to be variable, and will be influenced by the fixed one in case of a scope change.

FIXED TIME

When a customer needs to have new functionality, it is possible to have a fixed release date. Nobody can guarantee that the requested functionality is available on that release date, but it is possible to deliver the functionality with the highest business value. In most cases you will see that the main functionality is delivered, but that “nice to have” things are skipped or transferred to later releases. Fixed time allows an organization to really focus on the bare minimum (minimal viable product), before worrying about the extended features. In this case, you are able to guarantee a release date of a project. The power of the minimal viable product is clearly explained in ‘The Lean Startup’ book from Eric Ries.

FIXED FUNCTIONALITY

In scoping sessions with customers, most of the time you will hear comments like “We need to have all these features in the coming release, nothing can be skipped”. This is not a problem, as long as you are clear on the fact that the release date is a variable. Based on the functionality you might say something about the number of sprints needed, but that is also an estimation. The number of days needed for the release can never be communicated upfront, but you can guarantee the functionalities that are part of the release.

FIXED BUDGET

The final option is to have a fixed budget. This can then be translated to a number of sprints which can be filled with items to deliver. But since agile means things can (and most likely will) change during the project, it is possible that the team must be extended at some point. With a fixed budget, this automatically results in a decreasing number of sprints and therefore might result in a decrease in the number of delivered items.

OKAY, THAT’S CLEAR, BUT HOW CAN I CONVINCE MY CUSTOMER?

Selling this to your customer might be a challenge. They are still in the “all three aspects must be fixed” mode. The CFO want to have a fixed budget, the project manager wants a fixed timeline and the user of the software wants to have fixed functionality. And all three are stakeholders in your project. Maybe you can convince them with any of these arguments.

• Like I mentoined earlier, in a project, only one of the aspects can be fixed and is therefore the most important aspect during that project. Although the other two aspects are variable, that does not mean they are not important. As a matter of fact, they might be equally important to your customer. When decisions need to be made that influence the project scope, keep all three aspects in mind, but make a decision based on the fixed aspect. Full transparency on project decisions is necessary to inform your customer about the taken decision and the impact it has on the variable aspects. Convince your customer that, although one of the aspects is the “decision aspect”, all three aspects will be kept in mind when making that decision.
• The teams consist of customer employees and external project members and are multidisciplinary. This results in short communication lines, full transparency (as mentioned in the previous bullet) and team responsibility. Everyone knows the state of the project, the decisions that are made, the problems that the team encountered and the milestones until releasing the project.
• By using an agile approach and therefore release in short iterations, the customer has an immediate possibility to steer on changes in any of the three project aspects. Again, full transparency will result in a better insight of the effect the decision has on the project.
• Details of functionalities are analyzed when needed instead of upfront. The customer will be able to state the requirements close before the start of the development. New insights on the functionality can be communicated (and even added) without changing the project scope. This way, the project team can deliver the needed – instead of the analyzed functionality, which will result in better use of the software.
• You are able to build small portions of the requested functionalities before in-depth analysis. People tend to explain functionalities better when shown as a prototype or minimal viable product.
• Since the customer is closely involved in the project, they know exactly what they can expect. They make, or are in the loop of, all decisions within the project and are fully aware of the pros and cons of the decisions and the effect it has on the project.
• Work is preferably done on customer location and will therefore result in closer communication and allows external team members to be part of the customers’ environment.
• Full transparency on all three project aspects through standup meetings, project backlogs, sprint backlogs, burndown charts, retrospectives and sprint meetings (more information on these keywords here).
• Software is built for, but more importantly, with users.
• In the end, the quality, reliability and stability of the software will be better, the customer will know what they get and can continuously steer on the outcome, the effective time spent will decrease and the total costs will go down.

So, based on our own experience in doing a lot of waterfall and agile based projects, I noticed that customers are more satisfied with the results when an agile approach is taken. This does not automatically mean that we deliver more functionality, but the communication, transparency and value of the release is higher than with a waterfall approach. Customers know what they get, when they get it and are fully in control to “turn the knobs” when needed.

In my upcoming blog “Agile lifecycle – The support side of life” I will explain what the effect of the agile approach can have when supporting your customers.