Tuesday, June 30, 2009

Agile in the Federal Government

At the April APLN DC meeting, I had the honor of being on a panel for a round table discussion in regards to Agile in the Federal government.
The members of the panel included:
(Thanks to Jesse Fewell for the picture. See his blog entry for his thoughts on this session)
Overall, it was a good time. I use to work for Thad’s company (kind of, it’s a bit complicated) and it was great seeing Thad again. It is entirely possible that we may have closed down a bar or two back when we were working together.

Implementing Agile in the government space is tough. Obstacles include the existing oversight, budgeting and funding cycles and processes, general lack of Agile understanding on the Federal side, and conflicts of interest from the various consulting companies, prime and sub contractors, and government agencies. Agile helps you as a company or organization identify your goals and values and execute towards that end. Similarly, Agile does not solve your problems but rather exposes them. In government organizations, identification of clearly stated goals and values combined with exposing problems is something that will generally be met with obstacles.

However, it’s not all gloom and doom for Agile in the Federal government. In an August 2008 interview with CIO magazine, CIA CIO Al Tarasiuk stated “His team has also moved completely to agile project management methodologies…” Additionally, Dr. David Rico stated during our panel discussion that Boeing has standardized on Scrum.

At the team implementation level, Agile has a good chance of success and I am seeing that at my current client site. Since we control the team and with team acceptance of Agile, the Scrum Master / PM can shield the team from much of the organizational issues that may affect the team’s Agile implementation and performance. This will require more work from the Scrum Master. Many of the reports that will be asked to be generated and given may not naturally seem to fall within Agile practices. It will be up to the Scrum Master to identify the key metrics such reports want to capture and translate the Agile team metrics to metrics more familiar to others in the organization. Examples include translating burn up and burn down charts into EVM reports, iteration and product backlog can translate into Gantt charts, and end of iteration reviews and retrospectives and feed into status reports.

At the executive levels, expressing the values of Agile can be quite convincing to a sympathetic executive. The key is identifying and gaining access to an executive who is ready to hear a message about empowered, optimizing, evolving, value based delivery.

The middle tiers is the most difficult. The oversight and middle management levels can be heavy and if leaning an organization, this would most likely be spotlighted as places where leaning can take place. That combined with the conflicts of interest and personal interest that exists at these levels can make these layers quite problematic. Probably the most effective way to deal with this is for organizational support at higher level to effect certain Agile changes to take place at these layers.

For working Agile in the Federal government, I recommend the following:
  • Choose your battles. There will be a lot that you will want to change and you will not be able to do it all overnight, so start small and pick your battles.
  • Create creditability collateral. Demonstrate a pattern of success so that when the big battles do come, you will have the pattern of success to strengthen your position.
  • Identify what is being asked. You may be asked to provide many reports, presentations, briefings, etc that may seem to be a lot of overhead or waste. I recommend identifying that the goals of these requests are and identifying if there is an Agile translation to the nuggets that these requests are trying to achieve.
  • Lastly, good luck, you’re going to need it!

Friday, June 26, 2009

Shu, Ha, Ri with Alistair Cockburn

Yesterday, I had the chance to spend the day (actually 12 straight hours) with Alistair Cockburn. Excella’s Agile Center of Excellence held a private breakfast event featuring Alistair and he and I met with several clients later in the day as well. It was a great experience and great fun. Not only is Alistair extremely knowledgeable, but he’s a funny and nice fellow as well.

Rich and Alistair

(Alistair and I after a long 12 hour day)


(Alistair with Excella’s OPM team in front of our Scrum wall. Note we are both pointing at the IMPEDIMENTS sign)

Yesterday provided much blogging material, but I will start with Shu, Ha, Ri.

During one of our client meetings yesterday, the topic of Shu, Ha, Ri came up, which Alistair describes in his book Agile Software Development (now in second edition as Agile Software Development: The Cooperative Game).

When Shu-Ha-Ri came up, Alistair asked me to describe it and I provided something along the lines of the following:

Shu, Ha, Ri, comes from Aikido (think Steven Segal in Above the Law, his only good movie …. other than Executive Decision, which barely counts considering he dies in the first 20 minutes … bonus material for blog, not in original statements). Shu, Ha, Ri roughly translates into learn, detach, transcend.

From the perspective of learning Agile (and really learning in general), Shu represents the first level of learning Agile. At this level, one learns a certain skill/technique and essentially mimics it. In the case of Scrum, one learns Scrum and then starts by implementing a set of Scrum based procedures; daily stand-ups, product and iteration backlog, Scrum Board, etc. At this point the Scrum student is learning and implementing the technique.

The next level of learning is Ha. At the Ha stage, one starts looking beyond their technique. For someone looking at Scrum, they realize that textbook Scrum doesn’t speak to areas such as project initiation, engineering practices, and testing techniques. One looks at other areas to broaden and deepen their skill sets.

The third level of learning is Ri. At the Ri stage, the focus is no longer on technique but more on outcomes. When presented objectives and goals, the practitioner doesn’t say they’re going to use a particular method to solve a problem, but rather the practitioner achieves the desired outcomes by applying the appropriate techniques from their repertoire needed for the specific situation to deliver the desired outcome.

After I gave my interpretation, I asked Alistair if I had it correct. I was happy to hear Alistair state that I had it correct and he said that he really liked my explanation of Ri, which wasn’t quite what he said. He then said he liked what I said about Ri better and is thinking about stealing it. Which makes me happy and will make my lawyer very happy when I put the lawsuit together (kidding!).

Overall, fun day.

Thursday, June 11, 2009

To Do List = Personal Backlog

Wow, I have been very negligent in my blogging in recent weeks. I guess when you have a new baby and a 3 year old running around, it wrecks havoc on your free time. This means that no matter what I do, my to do list keeps growing bigger and bigger.

I've had "update blog" almost every day on my to do list, but like a good product owner, I have been constantly prioritizing and re-prioritizing my to do list. Though "update blog" is a task on my to do list, it seems to keep getting pushed closer to the bottom of the list, after tasks like "buy diapers", "do laundry", and "get some sleep".

When you think about it, this to do list is really a personal backlog. Also, since I am not running personal iterations, it's more like a backlog for an iteration-less process, maybe like Kanban.

And yes, I did say task and not user stories. Zero chance I'm writing full user stories on my personal backlog. Nor do I have owner, or reviewer, acceptance criteria on my backlog (though I'm sure my wife would like this in many of the tasks around the home). Also note that the only status is Done or Not Done.

Hmm, full user stories may be interesting:
Actually, today I put together some notes in regards to an analogy between Agile and the sport of Mixed Martial Arts and so a real user story on my backlog is:

  • As a reader of my blog, I want a well-written blog entry that creates a compelling analogy between Agile and the sport of Mixed Martial Arts, so that I can be entertained for hours based on a single blog post….
    • Acceptance Criteria: Blog is on my blog site
    • Story Points: 8
    • Priority: Medium

    • Due Date: COB 6/15 (I'm taking a 3 day weekend vacation starting tomorrow)

That's it for today. When you next see my blog entry, it may be my mixed martial arts entry, or the blog that I started weeks ago regarding my APLN DC panel discussion and still have not yet finished.