An Adaptive and Evolving Project Execution Processby Bryan Peterson on 11/17/11
It's been quite a while a since my last update in which I described my foray into Agile. I shared my process of being introduced to Agile, how I came to take the leap and try it, as well as my search through different Agile methodologies to find one that fit my high volume, high velocity, short term, non-software development project environment. I am happy to report that we've had great success. Our team has been able to work vastly more efficiently on a larger number of projects. We've become much more scalable enabling us to take on and complete more project work without increasing team members or our work hours. In fact, we've seen a decrease in the amount of time we're putting in and on occasion when we do work late it's more of a choice than necessity. Most notably, we've become much more predictable. Hitting our project delivery dates is critical to our business and slippage can be a major issue. With our new process, we've been able to hit our initial target dates within about 10%-12%. This is an acceptable margin, especially when considering that much of our project slippage was due to things outside of our direct control like client readiness or other delays on the client side. We've also been able to identify areas in which we can make up time to accelerate when necessary and effectively balance a portfolio of a large number of active projects. It's changed the way we think and approach projects.
I've gotten a lot of feedback asking for a description of our process that's is ultimately a hybrid of Agile processes including Scrum, Commitment Based Project Management, Kanban, and a little additional innovation thrown in. Here's a description of what we're doing.
Project planning is based on weekly iterations. Each week, we have a lengthy planning session in which we have a retrospective of the previous week, share lessons learned, call out praise worthy performances and actions, discuss areas for improvement, as well plan the next week's committed deliverables.
All projects are divided into seven phases (Planning & Initiation, Configuration, Design, Technical Integration, Quality Assurance, Delivery, and Launch) that are represented by milestones in the project schedule. Each milestone has an associated set of deliverables for completion of that milestone represented by to-dos. The next upcoming project milestone is that project's horizon. Our projects have a lot of similarity between them making and we're able to have some repeatability with our delivery process. We've also defined the process at a high enough level that it can easily apply to most of our projects and variations can be easily accounted for.
Deliverables from each project's horizon are placed in the backlog noting the client, phase, deliverable, priority, date needed by (milestone) and any comments. Each deliverable is then weighted with an order of magnitude estimate. Estimates are a .5,1,2, or 3, indicating the deliverable counting as half, 1, 2, or 3, deliverables. Estimating is done via blind voting by the entire team and requires consensus. Discrepancies in votes are discussed until each estimate is agreed to.
During our weekly project planning sessions, the team decides which deliverables in the backlog are to be moved into that week's list of commitments. The sum of all of the deliverables' weighted estimates will provide the total number of deliverables committed (ie. a deliverable with a weighting of 2 counts as two deliverables). The team has established a work-in-progress limit that defines the total number of deliverables that can be committed to for that period. The WIP Limit is set such that the team can target 90%-100% completion of deliverables each week. You can think of this as our work-in-progress limit is represented by a certain number of slots to be filled. The weighting gives us a slightly more than rough order of magnitude indicating if a deliverable is taking up one, two, three, or a half slot.
The committed deliverables are then be broken down into sub-deliverables or tasks, if needed. Originally, we used post-it notes placed on our rolling white-board to track the deliverables in that iteration. The owner of the deliverable would simply pull down the post-it note when complete. As the team began to take ownership of the process, they decided to replace the post-it notes with tickets in our ticketing system. The tickets have labels indicating it as a project commitment and associated deliverable. This keeps it separate from the actual work tickets until work on that deliverable begins. These tickets are initially unassigned, thereby creating a queue of tickets representing that week's commitments. As tickets are worked on, they are assigned to the appropriate owner. As deliverables are completed, they are marked as such in the iteration tracking sheet we've created on on an internal wiki page. A deliverable is considered completed when all work has been performed to the established quality criteria.
This left me with an interesting problem. I loved my white-board. I loved having a sort of physical manifestation of our project work that we could reference throughout the day. It served as a reminder of all of the work that we had to do and gave us a sense of accomplishment when we pulled things off the board as we completed them. Now that our work was moving digital, I wouldn't be able to use the white-board in the same way. I definitely didn't want to to try and find a use for it just for the same of having it to gather around during our daily stand-ups and planning meetings. Then it hit me. One of key areas I was looking to address with a transition to Agile was the schedule. As project manager, I was responsible for managing the project schedule. However, I wanted to get the team more involved with creating the schedule. I wanted more of their input on the deliverable dates and for the team to validate and update the schedule as the project progressed. I wanted to get consensus and commitment to our deliverable dates. If the team's committed dates didn't match the dates of the business or the customer, it was my job to work with the team to get them aligned. If expectations needed to be reset with the business stakeholders or customer, I would do that. After all, we were now communicating dates we were realistic committing to and not guesses or dates we "hope we'll hit".
Each project is represented on the white-board with each phase's target dates. The team is able to accurately predict and commit to the due date of the horizon milestone with a high degree of certainty. The remainder dates of the scheduled milestones, though not committed, can be extrapolated, estimated, and communicated to the customer accordingly. This all is also done during our weekly planning meetings.
Each day, the entire team participates in a daily stand up meeting. These meetings include the entire team and generally around 10 minutes and absolutely no longer than 15 minutes. The purpose of these Stand Up meetings will be for each person to answer three questions:
1. WHAT DID I DO YESTERDAY?
2. WHAT WILL I DO TODAY?
3. ARE THERE EARLY WARNINGS FOR MISSED COMMITMENTS?
The team also validate each project's schedule by agreeing that each project horizon is either realistic and something the team can still commit to or that it needs to be adjusted. Early warnings of deliverables that will miss their commitment date or slip beyond the targeted iteration is to be expected. The team is highly encouraged to bring up these early warnings as soon as they are known and no one will be punished for doing so. This is one of the most important tenets of our project process. The people who are doing the work are the ones contributing to the planing and reporting on that work. No one is ever punished for speaking up about potential needed adjustments to the schedule. I encourage people to tell me "We're not going to complete this by that date". What I don't want to hear is "We didn't get this done".
Overall, the team has reacted very well to the new process. There was an adjustment period. We learned to communicate better and more effectively. We eventually found our cadence and are now very effecient, predicatble, and productive because of our adaptive and ever evolving project execution process.