“There is no such thing as absolute value in this world. You can only estimate what a thing is worth to you.”
As so in software development, everything is about good estimation!
If we are talking about software development tools what is the first thing that you think of? Agile, Waterfall or maybe something else?
Ask yourself Why Agile software development works, not How
Have you ever wondered why there are so many different examples of Agile development? Before we dig into the core idea of Agile we need to define what is Agile. Even more importantly, what Agile is not!
Different people will call Agile differently, especially when they want to sell you their product. For example, if you ask consultant you will probably hear that Agile is a methodology for software development that you can learn if you buy their services. If you ask whiteboard markers they will tell you that the key to being with Agile is writing users personas on whiteboards that they just so happen to be selling.
The actual definition of Agile can be found in official Manifesto for Agile Software Development. There we can see that Agile is not a:
- Methodology
- Framework or process
- Specific way of developing software
So then, what is Agile?
If your team already developed different practices, specific tools or even methodologies it may help them to try and follow the Agile but they are not Agile itself. For example, the team may find that having a daily Menlo reports is helpful. However, the Menlo reports are only Agile to the extent that they are the result of the team following Agile principles.
There is a lot of misconception about what the Agile actually is. What we need to understand is that Agile is a set of values and principles. Having that in mind we can see that Agile is a collection of beliefs that the team can use in making decisions about how to do software development more efficient.
Agile Manifesto
Once you truly understand it, you’ll find out that Agile is surprisingly flexible. It does not make decisions for you. Instead, it gives you a foundation that the team can use to make decisions which result in better software development. As Agile Manifesto suggests, we can develop software better by valuing things on the left side then things on the right side.
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value:”
In addition to Manifesto, there are 12 principles that support the values. Those principles are general and they are less about telling you what to do and more about giving you the ability to make a good decision in the right moment. Once you have a set of values and principles that you have decided to follow, your next step is to make each decision of your next move based on them.
A process of decision making is highly important and you can not shorten the process by taking decisions made by another team. Every team needs to find a best Agile way for themselves. If you don’t do that not only that your team will not be Agile but down the line problem’s gonna pop out sooner or later. So estimate carefully, take the time to make decisions and buckle down.
Waterfall
Once again let’s take a look at why Waterfall works, not how.
Gravity, right?
Since it goes down it can’t go back. The same is with Waterfall software development methodology.
Unlike Agile, Waterfall is a model, methodology for software development. It is based on predefined steps that need to be set before the start. If you set requirements poorly at the beginning either you’re gonna end up with wrong software or you’ll need to start over at some point.
This model follows the same sequential pattern for each project and because of that, it’s easy to implement it and understand it. The team that you plan to put in work on Waterfall project doesn’t need any prior knowledge or training. Each phase has specific deliverables and review, so it’s easy to manage and control. When you have timelines defined you know much time you have for each step which gives you a framework that imposes discipline in your developer soldiers rows.
When is it the best to use Waterfall model?
When we have requirements rightly documented and fixed, the start position is clear. Through the whole project, we can look back and rely on them. The product definition is stable. One significant factor is technology. If we are sure that technology is understood and is not dynamic it doesn’t disrupt our first increment – requirements, which allow a fluent flow of the project. And final, it’s best to use on short projects.
Hybrid?
Sometimes it can be a deathtrap accessing a project with a single approach. If you decide to use just Agile, it may be risky if you are working on large applications. Doing just Agile can make planning be less concrete and documentation can be neglected. On the other side, doing just Waterfall for big project puts a problematics of having attention to the overall architecture of the system at the very start. Judging by this, we can safely say that a lot of things depend on predictability.
Actually, it’s all about predictability!
If the steps can be predicted with the high level of confidence, for example if it is an activity that we completed many times before, it’s more likely that Waterfall is a better approach. Conversely, if the level of confidence is low, Agile is more likely to a better choice. If there are some parts of the project for which you can’t decide about its certainty (uncertainty) you need to divide it in as many parts as you may need. When you reach a sequence of a project where you can define every single deployment part, you are ready to go.
So having this in mind we are back to the story of decision-making. This will be a top-bottom approach. Define next:
- How big is the project (part)? Approximately how long is it going to take?
- How many sequences of the project (part) are there that you never confronted before?
- Divide project (part) into parts.
- *Decision-making process for each part. (Choose approach or continue to step 5)
- Repeat all of these steps for each separate part.
Based on the result of this process you can choose one of the methodologies that implement Agile such as Scrum, Kanban, Crystal Clear, Lean Software Development, etc. or Waterfall based methodologies. You can also put part of an Agile into the Waterfall (WaterGile) and conversely put Waterfall steps in part of your Agile project (AgiFall) where you think is the riskiest part. By the end of this part, you can end up with something like WaterGileFallAgile and so on approach. So if you find the right method to define your needs in every part of the project you are holding all the aces. Doing that can lower the risk of potential parts being poorly done. Combine advantages of both approaches and avoid their disadvantages. Think smart!
Decision-making Process
There are few things that you need to have in mind and answer to couple of key questions when you want to choose the right approach for your project.
- Requirements/definition – Is it changing or is it stable?
- Change – Is the scope always changing?
- Experience – Is this a new technology, is this solution new to your company? Did you have experience implementing it before?
- Resources/Dedication – Do you have the right resources that are dedicated to this project? Do you have people that are part time in our company or not fully dedicated to the project?
- Resources/Physical location – Can these resources be co-located in the same location?
- Customer involvement – You need to have continuous feedback from your customers.
- Timelines – Do you have fixed timelines or due dates?
- Documentation – Do you have the flexibility to require little bit less documentation?
When we have these defined it’s easier to see what’s the best approach. Having all this in mind let’s check out one approach that’s becoming more popular these days and how we can upgrade it.
Scrum under Waterfall (SuM)
A good examples how a hybrid can be effective by leveraging strengths of each separate approach. Let’s hold up to Waterfall but plant in Scrum.
- Scrum for day-to-day dev/test activities
- Detect problems with sprints
- Focus on DoD & working software
- Waterfall for multi-team coordination
- Waterfall for release planning
Let’s imagine that all blue boxes contain green squares which represent teams doing iterations. If we break planning, strategy, and phases into tasks we can proceed with sprints to complete them. We are going to detect problems with sprints and create boundaries in which we are gonna work. When we meet the development phase it would be pretty similar to any other Scrum project, just with more information on start. That gives us the ability to avoid that well-known disadvantage of doing just Waterfall and that’s ending up with the wrong product.
There are some changes that are going to happen for Scrum. Our backlog is going to become project plan. Lot less scope negotiation because there’s little bit more requirements than at typical Scrum development.
But we are still going to follow the definition of done and that is not just a development part but all that goes into making a feature or requirement done. Sprint burndown chart to see are we on target for remaining work. We need to have sprint review meeting at the end so we can demo our software and finish with a retrospective.
Keep this in mind when combining these two. They tend to be hard to swallow sometimes.Don’t hesitate to drop me a comment or question in the section below.
