For more than a decade, agile project management has been a common theme in the business world, particularly in IT. Yet, I observe real difficulties for organizations to implement a successful agile transformation.
The jargon, the expensive certifications, the injunctions to agility… What is a real culture, a work paradigm radically different from the one it tends to replace often seems distorted. The dilution of the founding values in the rigid application of frameworks such as SCRUM or XP makes the implementation of agile approaches inefficient, sometimes even harmful for an organization. Dave Thomas already spoke about the denaturation of the agile movement in 2015, during a memorable conference on the death of agility.
Does agile project management is death ?
Rest assured, agile approaches are fine! In an increasingly complex and chaotic world, I even believe that they have a bright future. During his conference, Thomas explains that the transformation of the adjective agile into the noun “agility” proves the recovery of movement by a market that has built a business based on fear. The fear of not following the trend, of not being up to date, of being overwhelmed.
OK fine. But ultimately, what is agility? Or rather, given that it is an adjective, what is it like to work with an agile approach? A good drawing is worth more than a long speech, I will try to show you what seems to me to be the DNA of agile approaches with a simple graphic representation. To your pencils!
Draw me project management
Let’s take two triangles modeling a project. Gray represents the project managed with a sequential approach, blue with an agile approach. Each vertex represents an axis of the project; its cost, deadlines and scope (alternative to the eternal Quality, Cost, Delay triangle). The perimeter represents the extent of the functionalities proposed by the object of the project, it is therefore the functional perimeter of the future application if we are talking about an IT development project. The cost and timing shouldn’t need any more explanation!
In traditional project management, i.e. in a sequential approach (V-Cycle, Waterfall), the team strives to define the needs, write specifications then specifications before realizing, testing and finally delivering the project. ‘application. The scope is therefore fixed by the specifications, the cost and the deadlines can vary (and in general, vary!), even if you have worked on a very precise Gantt chart and meticulous costing. Finally, the piloting of the project is done via a PLAN defined by the team in the specifications and specifications. The Gantt, or the project schedule, regardless of its formalism, specifies what will be done and when. The team’s compass is therefore the specifications, this thick document intended to be exhaustive. It is he who defines what you are going to do during the next X months and who allows you to plan all the tasks of the team from the start.
How are agile approaches different ?
In an agile approach, the team works in a different way. The cost and deadlines can be simply set by defining a number of iterations (the famous sprints if you work with SCRUM) and the size of the team in charge of the project. On the other hand, the team agrees to evolve the scope from iterations to iterations, according to the real needs of the users. It is the regular feedback from stakeholders (customers, future users, experts, etc.) that will guide the team in achieving what it is going to build, hence the importance of organizing regular demonstrations and testing (review). In an agile approach, what guides the team in the development of an application is therefore the VALUE delivered to users.
This is the quintessence of agile project management approach; consider that the team will deliver more value by iterating quickly and regularly collecting feedback from users and stakeholders. From then on, the traditional weeks spent specifying and planning in detail become useless, the team does not seek to achieve an objective set by a plan written sometimes several months ago, it strives to regularly deliver value and to interact with its customers and/or users in order to prioritize future developments.
Why does it work ?
Inspired by the world of construction, sequential approaches are based on hidden assumptions:
- We know all the needs of users upstream
- We are able to determine the best technical solution before we start developing it
These assumptions push us to adopt traditional engineering practices where formalism and planning make it possible to limit the risks and to make the progress of the project relatively predictable. The problem is that these assumptions don’t hold up in the harsh reality of software (and product) development in general. Even in a low-risk environment, hazards often interfere with the precise execution of a plan. In computing, this lack of predictability is reinforced by the continuous emergence of new technologies.
Finally, with a little experience in the matter, we can recognize antagonistic facts to the hypotheses listed above:
- Between the expression of the need and the delivery it can take several months during which the need will evolve
- Users really don’t know what they want after testing a first version of the app
The development of a product or the management of a project using an agile project management approach aligns with these observations. Therefore, short-cycle experimentation takes precedence over planning. The team needs to know what it is going to do, you tell me! Yes, the team compass will be a strong and shared vision of goals. Building an agile roadmap will also allow you to stake out your project with expected results and objectives rather than with specific but quickly obsolete tasks.
And you, rather gray triangle or blue triangle ?