As a follow up to a recent post I made on Leading a Grassroots Initiative, I wanted to share a strategy I’m following to the “Experimentation” phase of my initiative.
Software development has changed dramatically in the last few years. No longer can companies afford to do long requirement-gathering sessions. The needs of the business change too quickly. Scrum/Agile development isn’t anything new, but it is becoming more critical for projects that need to show value faster.
Leading an initiative can follow many of the same methodology practices as software development.
Learn from developers
Building for Businesses and Users.
Roles
- Scrum Master = Project Manager/Champion (no decision making authority)
- Product Owner = Program Manager/Strategy Consultant
- Development Team = Cross-functional team, empowered to agree upon and execute toward sprint commitments
Meetings
- Planning Meeting – Maximum time for planning a 30-day sprint is 8 hours.
- Daily scrum Meeting – 15 minutes total (what was done previous day, what will work on current day)
- Sprint Review Meeting – Demonstration of what was built/learned from the experiment
- Sprint Retrospective Meeting – self reflection on the team process, modify team/process for improvement during next spring
As you can see, a lot of parallels can be drawn to application development roles and process, even if the project does not directly involve development. This is something our team is practicing with success. It’s not universal, but helps a disparate team come together with a framework for working more effectively.