The Dos and Don'ts of Go Live
One of the remarkable things about Agile software development is the consistent output you get from a capable, autonomous team. The team estimates, it commits to the work it will deliver in a sprint, and it is accountable for that work. Implicit in that accountability is a contract with management that grants the team the autonomy and space to meet those commitments. For that period of two or three weeks, management lets the team get on with the job and avoids changing the goal posts.
Of course, real life is never quite so black and white. A critical bug might need attention from the team, or some urgent business priority emerges. But with a quality team and disciplined management this will not happen frequently, and when it does happen, the team can usually accommodate those changes and still meet their commitments.
The ultimate test of Agile methodologies and management discipline comes as you near the end of a project and move into go live. This is the time when the consistency and predictability of a stable, mature development process really shines through. It’s also the time when an immature management approach is most likely to lose focus and fall into regressive behaviours.
A few management Do’s and Don’ts as you approach go live
Do:
- Continue to rely upon and invest in automated testing
- Do basic triage and prioritisation before interrupting the development team
- Stick with your established dev-ops / release processes and schedules
Don’t:
- Praise, reward or expect developer heroics and late nights
- Micro manage the dev team or directly allocate work to developers
- Push through “emergency releases” without proper testing
The processes that lets a team deliver software, sprint after sprint, with consistency and quality, is exactly the same process that will get you through go live. Don’t panic!
Share This Post
Get In Touch
Recent Posts
