Product Dig #2: Agile Or Not Agile That Is The Question
January 2020 2 min read
Agile is not the universal solution. Though it’s so popular that sometimes a team can go Agile just for the sake of being actual, trading efficiency for political safety or just to do it as a top company does.
The first essential and not that easy to do step is to find out whether Agile processes will add value or destroy it in your particular case. It could be that you might benefit from some techniques that you would like to have in your project both from Agile and traditional management worlds. It’s a possibility that understanding the project reality well, it’s possible to find a unique solution that then can be marketed as a better way of doing things. Rather than stick to a dogmatic rules of a current best practice.
One day, a colleague, who’s a software developer told me that she liked much better how we worked before the team started practicing Agile. It was easier for her to do the job, and by fact, I know that the quality of the job that has been done that time was high. That risky project was delivered in time and within budget.
It could be that Agile implementation was immature or that team needs time to get into new processes, these arguments are both valid. Though what if with Agile the process became unnecessary complicated.
Are we here to hate Agile?
Not at all. Agile designed for highly volatile environments and fits great with Customer Development model and Lean Startup approaches. Which are essential for navigating troubled waters of constantly re-segmenting markets.
Agile provides flexibility at a cost. Sometimes it’s just no reason to pay that cost if benefits provided won’t be used.
So what to do?
I propose to find out what parts of your project and to what degree will likely to be changed from an initial planning to the project completion. Rational, means traditional processes fit there. For parts where uncertainty is high to imminent, empirical solution is the best match.
The formula is super simple, I acknowledge that. What matters is exact techniques￼ to be applied and the way you define what means stable and what means changing for your project. It comes with experience with successes and failures. Though experience can’t be effectively acquired by following only one way.
As Dwight Eisenhower famously said: “Plans are worthless, but planning is everything”. Knowing that planning is detailed in an army, does Eisenhower is non-Agile when doing a solid planning beforehand or is Agile by being able to throw out the plan and create a new one afterwards?