Agility Concept, a Project lifecycle – out of the Agile Scrum Hanbook

By July 17, 2018

[vc_row][vc_column][vc_column_text]If your goal is to learn something that can benefit you in your projects, you should consider two crucial things that are misunderstood most of the time:

What you may often hear is “Agile is a mindset”. The fact is that Agile needs a mindset, like everything else, but it’s not correct to say that it is a mindset. Saying “Agile is a mindset” has only one practical consequence: being able to work as you wish, just calling it Agile, without accepting criticism and looking for real improvements.
If you have the slightest familiarity with the way authoritarian systems work, you know that they always need to have an enemy. This concept fills in the gaps they have in their system and helps them control the crowd. Many Agile practitioners use the word “waterfall” to refer to the enemy; and while this “waterfall” is never clearly defined, they imply that it’s about the established project management systems. If your goal is success in projects, you don’t need the illusion of an external enemy; and you should remember that any successful system builds on top of the existing systems instead of starting from scratch; and while criticism is absolutely necessary, it has to be with respect and knowledge.

So, let’s start talking about the real nature of Agile.

Project Delivery Method and Lifecycle

When you’re developing a piece of software, the following steps are done in one way or another, for separate features, or for the solution as a whole:

Analyze
Design
Construct
Integrate
Test

You can, of course, use other names for those steps, merge them into fewer steps, or split them into more; that’s fine. These steps can be called delivery processes.

Now, the question is, how are you going to arrange and run these processes? Think about a few options before reading the rest of this chapter.

So, how many options did you think of?

You may have many options in mind, but they should all belong to one of the two generic forms. By the way, these options can be called the development lifecycle.

One generic lifecycle is something like this:

In this lifecycle, each process is completed before we proceed to the next; i.e. we completely analyze the requirement and decide what we want to have in the solution; then we design the architecture of the solution and find out what’s the best way to form the features. Then, programmers start working on different units, and then units are integrated into one solution, and then the solution is tested.

Obviously, the steps can overlap; e.g. you don’t need to wait until all units are complete before integrating and testing them. Your lifecycle may look like this:

This is not fundamentally different from the previous lifecycle; we still have a sequence of development processes as the main driver for the lifecycle.

As you see, this type of lifecycle is based on an initial effort to understand what we’re going to produce. We have an upfront specification, upfront design, and consequently, an upfront plan. That’s why some people call it a plan-driven development. Also, we try to predict what we want and how it can be produced, and that’s why a common name for it is predictive.

Predictive lifecycles are the normal and appropriate way to develop many projects, such as a construction project. You plan and design first, and then follow them. However, this is not a comfortable way to work for some projects.

Think of a typical IT development project. You can spend a lot of time specifying and analyzing the requirements, and then base everything else on that. What happens next? The customer won’t be happy when they see the result! They will ask for changes, and changes are expensive in this lifecycle because you may have to revise all the previous work.

As it’s common to say in this industry, the customer doesn’t know what they want until they see the product. When do they see the product? Towards the end of the project. At that point, cost of change is maximum.

To overcome this problem, we can sacrifice the comfort and structure of a predictive lifecycle and use one that creates the product incrementally, i.e. in multiple versions, each time with more features. This is a luxury we have in IT development projects that not everyone else can have: multiple versions of working software, each time with more features. Think about a construction project; there are no meaningful increments for that, and the product is not usable until the end.

To be fair, this disadvantage of a construction project is balanced with the fact that if you start a project to build a hospital, it doesn’t matter how many changes you have, the final result will be a hospital, not, for example, a theme park! However, in IT development, you may start a project to create something like a hospital and end up with something like a theme park.

So, we can have incremental delivery in IT development projects; let’s exploit this opportunity by a lifecycle like this:

There’s no real prediction in this lifecycle. Instead of predicting the product and relying on that, we have short periods of time in which we create increments of the product. We will show the increment (latest version of the product) to the customer and end-users, receive their feedback, and decide what to do in the next period of time. So, instead of prediction, we go on with the project and adapt to the feedback. What would you like to call this lifecycle? “Adaptive” is a great name: adaptive lifecycle.

To create each increment, we need to run all development processes during that period of time. In the next period, we will repeat the processes: we iterate. That’s why this method of development is sometimes called iterative development. Respectively, the periods of time within which we iterate can be called iterations. This is not the only name used for that; you may already know at least one more name for iterations. We’ll get back to this topic soon.

Want to know more, get the Agile Scrum Handbook or read more in one of the other Agile Scrum Hanbook blogs.