My last post covered the role of the CIO in adopting agile where I gave some important tips with links to some other posts covering organizational issues. In this post, I'd like to share some concepts on maturing the agile software development lifecycle. Note that this is not a maturity model, as I've stated previously Agile Does Not Need A Maturity Model and on maturing agile without a model. The concepts below highlight the progression of adopting agile without going into a specific model, measurement, or approach.
Agile Maturity Comes in Four Overlapping Phases
Unlike other approaches to mature a practice , I believe agile practices mature in phases that overlap. Let me first describe them:
- Pilot project(s) - Agile is best started by selecting an appropriate project, getting a few things in order prior to project start, and then diving in. If you have little agile experience, get a coach and seek out some training for team members. Make sure the business project is appropriate (I will cover in a future post) and make sure its sponsors are willing to participate in the program. Then follow a guide for starting agile. Your coach will probably have a program, but here's one on How to Implement Scrum in 10 Easy Steps. Also, see my Top Ten Thoughts for SCRUM Newbies. (Can't believe I wrote this almost a year ago!). Also, I wrote on the Top Seven Ingredients to Establishing an Agile Develpment Practice.
- Establish the SDLC - As you're team completes iterations successfully, the team's practices will begin to gel into a process. It's at this point, you'll want to decide what aspects to formalize and what it means to formalize them. How long is the iteration? How are stories conceptualized, written, reviewed, sized, and prioritized? What meetings are needed, when should they be scheduled and who should be invited? When should the build close, how should final testing be conducted, and when should it be deployed? These are just a few of the questions that should be debated and structured during the pilot project, then reviewed and upgraded as the process matures.
- Rebuild the Business / IT Working Relationship - Shocked that I haven't really covered this in previous post, so here's my commitment to cover this one. One big area is understanding the roles/responsibilities of the product manager (which many businesses have and are part strategic, part tactical) and the product owner (an agile role that is tactical and requiring both business and technical skills). This series on the Agile Product Manager has many good insights and tips. Second, the agile practice requires active business participation in each iteration to review and prioritize new stories and to sign off on completed ones. So in short, agile forces a different business process for developing new products and enhancements, so expect to work these changes in as the Development Team matures its practice.
- Scaling the practice - At some point, you'll be thinking, "Ok, I have this working with one team and one product, now how to make this work with multiple teams? product lines? multiple businesses?" Will you make all projects follow an agile practice, or will you set guidelines on when to use agile vs. other practices? You might wrestle with what practices to standardize, how to set principles around self organization, and how to retain and hire talent into the practice. How will you roll out tools that multiple teams can utilize in semi-uniform way? What metrics will you utilize? Solving many of these concerns essentially help determine how the practice will live on beyond project and team #1.
- Start with the pilot project
- Approximately 30-40% into the pilot project, begin work on the SDLC and the Business / IT relationship - ideally simultaneously.
- Once you have a working SDLC and new working practice with the Business, start thinking about how you will scale it. Ideally, the complexities in scaling the practice should be addressed by both the business / IT working relationship and and technical process (aka, the agile sdlc).
- Revisit and mature all practices as new teams take on the process.