Speed kills - Agility for IT professionals

Embarking in a new project for an organization that isn’t known for its agility but rather for political agendas - yet still being asked to deliver within an aggressive time frame - I am forced to think about how we can successfully implement an agile mindset and increase our chances of success.

This is not so much about implementing agile software development techniques - we have full control over whatever techniques/tools/processes we want to use. This is more about how we can effectively engage our client to participate and if not become a more agile organization at least create a collaborative and trusting environment.

Christopher Avery summed up some findings and opinions of executives from his think tank session at the Agile 2007 conference. Not surprisingly the consensus about risk is around:

• An agile front line — i.e., development teams — with a traditional management approach (read “silo” mentality and culture) over them is not sustainable.
• An agile development environment deserves and requires a collaborative executive leadership that treats change as easily as does the front line.

He then pointed out that “… for agile development practices truly to be adopted, executive teams must become more agile as well” (meaning to adopt pairing, daily stand-up meetings, retrospectives etc). I like the idea - A LOT! I can only suggest you go ahead and read his entire post.

Coming back to my original concern however as an (external) IT service provider it is unlikely that we can change the culture in the short term. So what can we do? Well, for starters we can identify all critical stakeholders and get them in a room (in Agile Project Management we call this a RAP session) to

• Define success: What are the criteria to consider the project a success?
• Define scope: What’s in scope? What’s out of scope but related? Who is responsible for out-of-scope items to happen?
• Identify stakeholders: Who has interest? Who is impacted? Who can stop or delay the project? (If you don’t have all of the latter in the room consider running another RAP with them)
• Define quality: What does quality mean for this project? What is good enough?
• Identify risk: What are the risks?

This session will expose misunderstandings and differences in expectations between stakeholders. It will also help establishing a trusting and open relationship. With that in place we are already half-way there.

We can then proceed to create a collaborative environment. Start by siting next to each other or facing each other (by all means avoid sitting with your back to each other). Have an environment set up and ready to demonstrate the solution to interesting parties. Have regular presentations (e.g. end-of-iteration presentations) to keep the business involved and interested (not to mention the shortened feedback cycle).  Invite stakeholders to your daily stand-up as observers and give them visibility of progress (be it access to a portal or point them to a whiteboard with sticky notes on it).

Over time people will pick up what works well and find out how they can bring it to their tasks!

If you are an executive and it is your own organization Mike has some suggestions how to create a more productive and open environment.

Bookmark to: