By John Hennessy, Customer Solutions Director, MKS Inc.
A common perception is that going Agile is the panacea for large project failings. Agile sounds wonderful. It makes perfect sense, right? “Shorter cycles giving rapid feedback and faster time to market”, “Constant re-prioritization allowing agility as business priorities change”, “Deliver highest value items first, with actual working software” and of course happy smiling programmers. Utopia!
However, as you press for change within the enterprise, the reality of resistance to change sinks in.
The version of ‘Scrum but’ you hear is, “We would love to do SCRUM, but we don’t have executive support..”, “But the timing is wrong..”, “But our clients gave us their “approved” requirements documents”, “But we need electronic signature support..”, “But the processes are validated..”, “But we must follow the approved SDLC..” etc.
Where do you start? You can’t change everything overnight. Leverage what’s working well such as the real-time visibility, traceability, impact analysis and enterprise metrics from ALM (Application Lifecycle Management) and don’t try to change everything at once.
Development teams wishing to do SCRUM can easily work within your existing ALM framework by taking the enterprise-level requirements and creating user stories from these, to form product backlogs for the Agile teams, while teams not doing SCRUM can continue with business as usual on their parts of the projects.
Having taken Jeff Sutherland’s Certified Scrum Master course, I found his “ScrumBut test” or “Nokia test” very interesting. It became clear to me that Agile teams can score very well in this test working within existing enterprise frameworks without changing everything.
The Nokia Test (Are you doing SCRUM?)
Do you have fixed iterations 4-6 weeks in length?
Have you working software at the end of the iteration?
Have you good user stories tracing to specifications?
Are you testing during your sprint?
Have you a Product Owner who motivates the Team?
Is the Product Owner’s Product backlog prioritized by business value and estimated accurately by the Team based on Planning Poker?
Do you have burndown charts and does the team know its velocity?
Are the teams self organizing and allowed to work without interruption?
By starting with a product backlog of user stories generated from and traced back to the projects requirements, you get the best of both worlds. The enterprise cohesiveness of ALM remains intact and the development teams become more productive with increased agility.
If you want to know how an Agile ALM solution can support an organizational Agile transformation watch this ADTMag.com Supercast. MKS is a recognized leader in Agile for the enterprise.
Please send your comments and let me know your thoughts on working with Agile in an ALM framework.