Labels

Four Phases of Maturing Enterprise Agile Development

Are you a technology executive looking to adopt or migrate to an agile software development practice? According to a Forrester survey Mainstream Adoption Has Changed Agility, 35% of IT professionals say their development practice most closely resembles an agile development practice causing the media proclamation that agile is now mainstream. But of course this also means that 65% are not practicing agile and I'm certain that a large number of the 35% are only just maturing their practice.

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.

Looking at these four phases, and you should be able to visualize the overlaps:

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.

Obviously, this is somewhat conceptual (it is a blog post....), but hopefully this will help you get past some fears from taking the first steps.

3 comments:

great topic, my company moved to agile 2 years ago, and according to missing some of the points above we had serious problems in our project, but having an agile coach was leading us to the right track.

we did not start with a pilot project, we start with big account.

some roles within agile team were not clear, so some work was left to the last moment which increase the risk.

we apply some of the agile practices, we missed some important practices such as unit testing, TDD, or automation testing.

Hey friend! You’ve got a interesting weblog here. I truly liked it. Very nice post. I just stumbled upon your blog and wanted to say that I have really enjoyed browsing your blog posts.Web development Company