Fantastic beasts in software development methodologies /part 1
This article answers how the agile approach could be too way risky for software development teams.
Before we start it is worth saying that I have been working in the software development industry for 12 years and have seen a lot of projects where weird approaches to product development gave awful results.
We are going to discuss a good example of the definition of a “weird approach” — a fixed-price expectation with agile methodology (scrum-fall 🥴).
— [Here comes any drum roll effect you can imagine] —
Let’s take a usual case where a customer comes with a request to create or update his product and spice it with a few details:
(1) The account manager on the vendor side signs a T&M contract. During negotiations, it was agreed that the release date going to be projected based on avg. velocity and high-level scope.
(3) The team conducts the discovery phase, gives high-level estimates, prioritizes features in a backlog, and starts scrum/kanban with the preliminary agreed release date.
(4) Everybody is happy to start a new great project and everything looks hopeful.
— [Rainbow picture] —
A few weeks/months later it turns out that everything is burning including quality, people, money, and timeline. The development team hates the customer and the customer doesn’t trust the team.
— [micromanagement, overtime, burn-out, …] —
Get pm_from_it’s stories in your inbox
Join Medium for free to get updates from this writer.
Let’s review what happened.
*Worth to say the agile methodology is not a cause — it’s just a tool that should be adopted.
** Purely agile project by default has a big chance of being successfully completed.
(1) The blatantly obvious question that probably wasn’t asked: Does a project need to be delivered on a specific date?
Also, worth to mention, there is such kind of customers who deliberately don’t say this expectation.
(2) Of course, the Product Owner changes the scope each sprint, adding new features, for sure, there is no responsible person who tracks scope changes and yes, the customer manages product development as they think the best (usually as worse as possible).
(3) Somewhere in the middle of the project customer could say something like: “At the beginning of the project you gave me a projection with the target date, but now I see the deviation is +30% to that date. I invested millions $ in the marketing company and expected the project to be delivered on time”
The dev. team usually makes futile attempts to explain the target date was projected on high-level estimates, but almost always it’s a waste of time and energy — the team is in a trap, and the cost of failure going to be huge.
[Recommendation]
If you were lucky to ask the formal question and the project must be delivered on a specific date:
- All your management activities should answer the question “Why are you sure the project will be delivered on that date? ”
- Use a toolset that on daily basis gives visibility on scope increase/decrease, average velocity, total scope size, percentage of precisely estimated scope, and deviation between initial and actual efforts.
- The team structure must have roles that are responsible for change management, scope management (don’t rely on a Product owner), and project monitoring/planning.
Have you ever faced a situation when an agile project turns into a fixed-price?
