Monday, February 01, 2010

Adopting Agile Development - The role of the CIO

I've been covering the CIO path to credibility. First, the CIO must be able to negotiate priorities and develop a path for consistent delivery - which is why I thing the CIO loves Agile (or should love it). So if you are buying into my methodology, the next step the CIO must determine is how to introduce an agile development life cycle to both the Technology and the Business organizations.

Now my assumption is that if you're reading this blog or post, you know a fair amount about agile development and planning. So I'm going to stay specific to the role of the CIO and responsibilities you must take on.

1) Sell it - The key question - how will the organization benefit from shifting to agile? Expect to get lots of questions. How will it affect business priorities? How will resources be trained? How long and expensive is this shift? The CIO has to anticipate these questions and work with his leadership team to plan the transition and be prepared to answer these types of questions.

2) Identify executive business sponsors - First, migrating to agile is a lot easier if you have a strong business executive sponsor. If you don't have that yet, you'll have a harder time selling and proving the benefits, but that shouldn't discourage you from taking on the challenge. Make sure that you keep executive sponsors (or possible ones) updated on the team's successes and how you're overcoming challenges. Invite them to demos even if they can't come. Here are some of my thoughts on getting Executives to buy into agile.

3) Identify the initial project(s) - I don't believe in shifting multi-team organizations to agile in one shot. Most agile coaches will tell you that the agile process needs to be adapted to the organizational dynamics and business needs. For that reason, it's best to select one, maybe two projects, get agile working, then look to scale a process to to other teams. What makes a good agile project? A good option is to find a business important project that has no/few requirements (early inception stage), will require several months of effort from one or only a few teams, and is most likely to benefit from an iterative delivery cycle.

4) Help the project sponsors - Shifting to agile can also be a major change for business sponsors. You have to sort out how to fill the product owner role (see: Agile Product Owners in the Enterprise). Sponsors have to learn how to work priorities, requirements and scope changes in this product life cycle and IT leadership have to help Sponsors learn their responsibilities. See my posts on Business Responsibilities working with Agile Teams Part 1 and Part 2.

5) Help the team make it successful - Make sure all team members have a basic foundation in an agile (probably scrum) process. I highly recommend training and ideally an agile coach if you can afford it, but at minimum make sure you have a team lead (scrum master...) who's been through a successful agile project. Make sure the team has a basic process in place even for iteration #1 and attend a few stand ups to help with the blocks and other issues that arise. Help individuals understand their role in the process and identify skill set gaps.


6) Find and manage the skeptics - Assume that you'll have skeptics with any process change and even the possibility of saboteurs. Look for the signs and help manage these situations.

7) Define self organization - This is a key tenet of agile, yet there are boundaries in organizations defined by policy and practice. Policy might define financial boundaries, rules on how technology is selected, change management practices, etc. Also, talented teams can easily extend self organizing principles and attempt to take on the responsibilities of other teams. 

8) Don't leave out QA - The QA team has to redefine itself quite a bit when Development teams move to agile. There are some folks in the agile community that believe the QA function is replaces by agile's short/iterative delivery cycle and with the maturity/adoption of unit testing frame works. I'm not one of these people. I'll have another post on this subject but to keep things simple for now, the CIO should get active to make sure that QA responsibilities and resources fit into the organization's agile process and methodology.

What did I leave out? I might need a part 2 to this post...

1 comment:

  1. This comment has been removed by a blog administrator.

    ReplyDelete

Share