Agile continues to be the preferred way of delivering
business outcomes. Still organizations use waterfall techniques especially to
the system of records. But it is agile that is becoming de rigeur for system of
innovation and differentiation. Agile’s willingness to fail is the primary
reason that endears it to the business.
I have been involved with more and more teams, especially in
Europe. There are some very clear observations that are quite evident.
- The mentality and emotion quotient surrounding a
waterfall project team is still based on avoidance of risk. Of course, they do
fill up the RAID log as it is commonly known. Documentation trumps up all other
requirements.
Agile Model in action - A pre-mature optimization happens in the delivery of such waterfall projects. Many factors contribute to it. One is the time lag behind the business requirements and delivery when everything changes around you in a faster manner. Second, the freezing of architecture and design without understanding some of the future-changes start pushing the projects into a tight corner.
- Integration happens at the last and that’s where new but significant risks start to emerge as the project deals with other adjacencies.
- Agile embraces risks and that’s what makes it adopt a different approach. The team starts in a humble manner and learn as they progress. Early and constant feedback changes the games.
- With each sprint / release, integration happens. The product may be incomplete but it is brutally subjected to feedback and criticism. In general, the right behaviour, in agile teams, doesn’t make them nice and avoid negative feedback. The old adage “Silence is golden” doesn’t work.
- As the teams, in waterfall, are split into smaller units for tighter control and delivery, the risks due to dependencies (known or unknown) rise faster. Michael Nygard says in Architecture without an end state “The problem with dependencies is that you can’t depend on them.”
- Waterfall assumes the leader is quite capable and prone to enforcing a herd mentality. This works well to avoid a difficult terrain but not when the business is waiting to expand. In agile, the management trusts the teams to find their own way. This is not to was off one’s hands completely. After spending time to help the teams understand the big picture, trust the team to negotiate further. Equipping and empowering culture are important.
- Recognizing that change is quite frequent, it is better to work on what we know latest instead of applying an artificial freeze. Agile teams remain flexible.
- Team happiness becomes critical in agile teams. Continue to measure it.
- Agile teams indulge in such planning where more minds are put to work. Instead of waiting for someone to solve their problems, they are encouraged to find their own. The team, typically, rises to the challenges and comes with measures.
Not all parts of IT need to become fully agile for the sake of it. But, the entire IT, as a coherent entity, needs to be agile o rnimble enough to the changing business. Where it
makes sense and where IT remains a blocker to realizing business outcomes are
those areas that should embrace this culture.
Finally, a word of caution. Do not
brand agile with no-process or free-for-all approach. It is where you lay the
stress that becomes different. Projects in agile mode are also supported by
quality and rigorous document and associated metrics. Informality should not be
confused with indiscipline.
