Sunday, August 29, 2010

Lean Delivery - Business Benefits and Commitments

A client of mine asked for some help in explaining the business impacts of using lean approaches for delivering IT solutions to his ministry stakeholders. (my client is a director of IT in the public sector)

After a couple of hours of work I put together this illustration. It shows a pattern that I have found myself using on a separate project. The pattern involves using a solution analysis work cell to filter and transform ideas into roughly same sized work packages.( or MMFs or MRFs or whatever)

This solution analysis work cell isn't meant to do thorough analysis, rather it does quick pattern matching between the problem domain and existing IT capabilities and systems, breaking and structuring work as required so that these packages can be routed to the right solution team.

Sunday, August 22, 2010

Supporting Delivery with a three tier Kanban

After a full day session creating a Kanban with my client we ended up with not one, not two, but a 3 tier Kanban. (I warned my clients this was a really complex option, but they are willing to give it a go and throw out a tier if it warranted)

The three tiers consisted of:
1 - MMFs, a release with a common theme, with business value, or some measure of delivery progress

2 - Testing Packages - a cohesive collection of delivery stories that are teased as a unit as part of package testing 

3 - Delivery Stories - classic agile units of work that go through analysis, development and developer testing
As soon as we completed our first standup my mind started turning towards a better structure to manage the flow and multiple level WIP limits that my client wanted.

It was certainly a struggle to come up with a Kanban design that reflects this relatively complex value stream. I hope I have done it justice. I do have a couple of concerns.

1 - complexity, this board may become hard to manage and it's complexity may make it hard to walk, I also hope visibility os not obscured.

2 - it feels like this board is holding a lot of WIP, if necessary I'll start removing buffers and collapsing states between analysis and development if they aren't adding any value.

3 - I'm new to using WIP at different tiers acting as control points for each other, in this board user stories can be blocked by a lack of movement from testing packages and testing packages can get blocked by a lack of progress with MMF related activities. It will be interesting to see how this works.

4 - I'm unsure how defects will affect the board. Both MMFs and testing packages have dedicated slots, if there is a bug do I create a new dedicated slot for a testing package containing a defect, do I move the whole testing package back, or maybe I should just have dedicated lane for defects 

Friday, August 20, 2010

Operating the Agile PMO - Month 1

Last week I posted an initial panorama of an "agile PMO" where I have been working with a team of solution owners and subject matter experts to operate a software application management and analysis function. In plain english, we are using agile and lean methods to set up and manage a delivery program, providing requirements analysis, architecture modeling, infrastructure and resourcing capabilities. Here’s some of the things we’ve managed to accomplish in 4 short weeks.

One of the first things we did was start to analyze the requirements work that had been done to date. We pulled requirements, features, business rules, etc. from these various artifacts and organized them using a story map. The story map covered the majority of an entire wall, using flip charts and sticky notes, we created a hierarchy that started at the top with business goals, and the bottom level being a collection of requirements line items from the various requirements documents. This approach allowed us to add sequencing, structure, and context to individual requirements line items, supporting our ability to do downstream analysis on collections of requirements organized by stories represented in the map.

Fans of Alastair Cockburn’s work will notice that this story map bears a striking resemblance to the use case hierarchy described in his use case books, it is basically identical, but we use the term story map as it has a more "agile" connotation.

What interesting to note is that early on in this process we relied exclusively on these requirements artifacts to help build the map, but as the team is gaining more and more confidence, we are finding that we are building the map from scratch, and then going through the requirements artifacts just to make sure that we didn’t do anything that was inherently in conflict with these requirements.

As we were creating the story map, we annotated stories within the map with issues such as conflicts, questions or obvious errors, as well as things like pre-existing services, specific systems, and the like. Different colored stickies represented different kinds of data, what’s interesting is how visually rich story map has become over time.

once we understood enough of the story map to understand the business problem, we also started doing "minimal system analysis" on individual items within the story map, we wanted to get a order of magnitude understanding of what systems had to speak to each other as a result of implementing a specific user story. We were especially concerned if a system change meant that a piece of work would have to be allocated to a different team. This system allocation analysis also help us understand complexity of the potential story within the map.

Once we felt like we started to get a good handle on what the story map should look like, we defined the overall objectives, scope, and purpose of a number of Minimum Marketable Features. We then "walked the story map" to create workable, user stories for the minimum marketable features that we wanted the delivery team to start implementing. In effect, we went through the bottom layers of the story map, determined if a particular story map should be part of the next Minimum Marketable Feature, broke the story up into a smaller unit of work if necessary, and then estimated it using planning poker (made famous by Michael Cohn).

As a rule, we urged the group not to take the estimation too seriously (which was challenging :-)), what was more important in our minds was the useful conversation, ad hoc modeling and dialogue that was generated as a result of the estimation itself. We actually hope to be moving towards a more kanban style measurement approach in the future where tracking average cycle time will trump estimation, but have found the planning poker approach invaluable as a way of encouraging good dialogue.

At this point we are able to start involving developers, architects, and testers more intimately. We grouped these resources into a "story analysis" work cell responsible for doing "just enough" analysis to ensure that it was ready for delivery. Story analysis included Class Responsibility Cards (check out a great overview by Scott Ambler), Behavior Driven Development style scenarios and acceptance criteria, user interface modeling, and external interfaces for other systems. We also reserve the right to "perform any other modeling" as necessary to help prepare a work ticket as "development ready".

In parallel with doing this analysis, we worked with the team to come up with a preliminary value stream and associated Kanban (invented and made popular by David J. Anderson) to track not only the operation of the agile PMO, but also the work done by the delivery and testing teams.

we included the majority of team members in this process, including developers and testers (as opposed to just their bosses who were involved up to this point). we have also been careful to point out that this is just a preliminary kanban being suggested, and that it would likely have major changes in the next several weeks.

As you can see below, the team elected for a three tier value stream & kanban. While I did stress that many not be that right level of complexity to start off for a Kanban board, I have to say I am working with an incredibly intelligent and sophisticated group, and they were able to articulate a rationale for wanting the three levels. I will go into another post discussing exactly how the kanban and value stream is intended to work, but want to give it some time to actually run before I do so :-).

Kanban is also being used to track the actual work of the agile PMO. We have graduated to (after several weeks) dedicated some lines for questions that need to be answered, explicit modeling activities, analysis with external parties, infrastructure and tooling, and internal design/analysis/planning sessions.

Last I looked into this group, members were individually completing both the enterprise and story analysis function on their own. I look forward to watching this flourish and continue to coach what has so far been a very rewarding and exciting experience.

Monday, August 16, 2010

using the agile modeling method and kanban to run an agile PMO

Myself, along with Alexis Hui have been helping set up an ambitious new business venture for a client with hours. We are synthesizing numerous requirements and design documents into a comprehensive story, breaking the working a minimum marketable features, and doing quick planning poker style estimations.

We have also set up a pulmonary value stream map for delivery, as well as a dedicated value stream map & kanban to manage the work of the "agile PMO".

An associate of mine who is helping us took a great panorama of the PMO war room. I think it shows a great job of how we are leveragingsimple collaborative tools to both model and plan for what promises to be a very exciting initiative.

Thursday, August 5, 2010