We are building a car #2 – agile methodology
In the previous article, we were wondering why well described projects often end up as bad investments or cause high friction on the customer-supplier line. Those of you who are interested, I direct to the first part.
In the second part, I stay with the project “fast car”, but I change the approach to agile. I am a strong fan of this approach, and you may get the impression that I am a bit biased about the matter, but I will try to substantiate all arguments substantively so that you can decide for yourself what will be better for your project.
What went wrong
In the example from the previous article, it turned out that someone came up with an idea of reaching 0-100km/h acceleration by shooting a car using a cannon. The end result is that in this way the functional requirement could be checked, while the final product lacked what is difficult to capture on paper – value.
If you went to a car dealer, you would certainly avoid such unpleasant surprises. By choosing a dedicated (regardless of the extent) solution, you become the beneficiary of innovation. This is the main feature that separates products from the assembly line from those created according to individual customer’s requirements.
Let’s go back to the waterfall approach. Here, a detailed design specification is created before the implementation work begins. In other words, you are betting the project’s value that one year before the works were completed, everything was well-thought-out. Is it reasonable? Of course not! The risk you incur is enormous:
- someone will misunderstand the record,
- the sales market will change,
- the law will change,
- competition will change,
- trends will change,
Therefore, any error in a several-hundred-pages specification will cause problems to accumulate, which will eventually lead to a loss of value.
I had the pleasure to conduct several business analyzes of dynamically developing companies. The documentation could become obsolete during the process. The same applies to the very nature of the project. If we are talking about the Internet, it is difficult to predict a moment when the slump will occur. Just recall brands such as Amazon, Zalando or Uber.
How does Agile handle this?
Agile methodology is best described as a mixer, to which we throw the entire waterfall process. The next step is to “spill evenly”, as a result of this we get cycles, each of which:
- is planned a bit ahead of time,
- is described at the beginning,
- contains a reasonable scope of work,
- is subject to separate tests and handing over to the client.
Considering how short the individual cycles are (usually from 2 to 4 weeks), not only do we significantly shorten the horizon of uncertainty, but we can also focus on the current design background.
Another important element, which does not have to occur in the waterfall approach, is the so-called retrospection i.e. work on improving the quality of cooperation. This is a moment when we can tell ourselves what went wrong, find the cause and in the next iteration meet mutual expectations.
What does agile bring to the table?
I tell the following to every current and future client – in order for Agile to work, we all have to love the project. You, being a product owner, will actively participate in the production cycles, having a real impact on the design of the project at every stage. A well-chosen contractor will be a counterweight to your ideas at the business level and support at the functional level.
Another important aspect is that there is less of formalization. In Agile, we do not produce tons of unnecessary documents, focusing instead on delivering value. Being an activist for healthy relations and project dynamics, for me, that is the greatest value resulting from a change of methodology. Having a comparison, XC projects in which instead of hiding behind a wall of paper, we spent more time on discussions, drawing conclusions and work, came out much better.
The paperwork is overwhelming
How does it relate to the car?
Let’s get back to our car. In an alternative history:
- business goal (0-100km / h in 3 seconds) will be set right away,
- functionality will be clarified when necessary,
- everyone will have an influence on the shape of the functionality.
The last point will be especially important to you. You will be able to brainstorm the team and start out with ideas that do not coincide with your design vision.
An idea for a quick car
A good idea for a quick car
That is all it took in this example. Good project relations, a common desire to do “something big” and planning when there is such a necessity. What is at the root of the agile methodology does not necessarily have to be in a waterfall at all.
What are you betting at in Agile?
It is not that Agile does not have its risks. The center of gravity is transferred to your trust in the company. What can go wrong:
- no good relations will be built (a barren project),
- problems with budgeting the project.
These two problems are the main obstacle when it comes to increasing the share of methodology in the services market. In fact, you need a lot of trust in the company to entrust it with the Agile implementation of the project. Even if it is a lot easier to substitute such company in Agile, let’s be honest – in an advanced stage of the project, it is not that easy.
If the project is to make you a beneficiary of innovation, you should at least think about benefits of an agile approach, if it is possible. With the right selection of the company (we will talk about it for sure), you not only gain a contractor, but above all, a partner whose main task will be to concentrate with you on the value provided. This chemistry makes the majority of the documentation obsolete.
Agile also means greater control over the design and the ability to influence its shape at any time, which is reflected in the effect suited to the current needs.
Will I always recommend Agile? No, I know cases where it does not make much sense. More on this subject soon.