I'm going to be making a change of sorts. Up until now, I've been focusing mainly on writing about project and program management. Lately, I begun shifting more toward writing about digital marketing and all things related: email marketing, social media, blogging, customer engagement, content marketing, etc. While I've been working as a project manager, over the last few years I've been managing projects within the digital marketing space. As such, I've begun consulting, advising, and focusing my efforts on working with marketers on a variety of aspects of digital marketing.
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.
I am crossing over into Agile. Well, at least we're going to try it. Anyone who has read my previous blog posts, articles or has heard me speak will know that I largely come from the "traditional project management" school of thought or PMBOK. It's the way I was trained and the way I managed my projects. Most of the projects I had worked on as a team member were also managed that way. I am still very much a big proponent of traditional project management. However, after taking on a new project management position a little over six months ago, I've been open to the possibility that the traditional approach hasn't been working for me as the most effective approach in my current environment.
I wasn't always sold on Agile. At best, it seemed like something that worked well for software development but that it had limited application outside of that. At worst, it seemed like just another fad that people would drone on and on about and then fade away at some point. Something that Agile has never been lacking is a strong crop of passionate evangelists. They almost seem cult-like at times. Many Agile practitioners I've met/spoken with often seemed to give out that "holier than thou" vibe. From my experience, there seemed to be two types of Agile practitioners; those who actually followed a true Agile process and those who called themselves Agile as an excuse to be lazy and not have to adhere to any set schedule or quality standards. I've had my experiences with both. Yet, here I am crossing the chasm to be one of them (the former, not the latter).
The project environment I'm in consists of small teams (2-3 people) working on short term projects (average 6-12 week duration) that are largely customer facing software implementations. Quality and timing go hand-in-hand as my 1A and 1B constraints and I typically have between 10-15 projects active at any given time. My focus is on delivering the highest quality possible in the shortest amount of time possible with a set number of team members and relatively fixed project scopes. When I began to have challenges with capacity, efficiency, and timing, I began to take a look at my overall approach. Perhaps there might be a better way to approach this. Perhaps there is even a way to take on even more work without working harder. Could I somehow reduce my stress and at the same time increase my predictability and delivery of projects? I decided to take another good look at Agile.
I started in the most obvious place, Scrum. I really liked Scrum and everything that it entailed. I liked the ceremonies of the daily stand ups, scrum meetings, sprint planning and retrospectives. I loved the idea of the backlog and burn down charts. I loved the iterative nature of breaking work into time periods that are filled with all of the things that you can accomplish in that period. I loved the collaborative approach with self-organizing teams. I especially liked the flexibility of creating a framework in which to operate that allows for adjustments and improvements to process and enables the team to always be focused on end goal.
However, I couldn't quite connect all of the dots with Scrum. It was, after all, developed for software development and I couldn't quite get my head around the extrapolation of its application in my specific environment. We weren't developing software. We didn't create and deliver statements of work. We worked on a multitude of simultaneous projects that were customer facing, had similar and repeatable scopes, relied on a predictable delivery date, and were exposed to the changing priorities and commitments of customers. I couldn't quite get all of the pieces of Scrum to fit in a way that would address my issues of stress reduction and delivery increase.
I would not be deterred. My search then led me to a webinar presented by Journyx, Ensemble Management Consulting, and Solera Associates in which I was introduced to a form of Agile called Commitment Based Project Management (CBPM). It was developed at Intel in the 1990's and was not designed for software development. It uses simple tools and simple rules and enables you to put together a schedule that everyone believes in so that they can give real data about the project. The team commits to specific deliverables for a time frame (horizon) so that it is clear who delivers what to whom and by when and to what quality standard. Anyone can speak up about early warnings for dates that might be missed and no one is punished for that. CBPM incorporates the Agile values of individuals and iterations, customer collaboration, and easily responding to change. It all made sense to me. I thought I was ready to take the plunge and present this to the team.
What I brought to the team was a hybrid approach that combined CBPM with elements of Scrum. We plan in weekly sprints. We have daily stand-ups and weekly retrospectives. Our backlog contains the deliverables we have across all projects within that horizon period. We then map out the deliverables that we will commit to for that sprint. Instead of stories, we have deliverables. We don't assign point values to work and we don't track via a burn-down. A deliverable is either done or not. Though the team seemed cautious and not completely convinced, they were willing to give it a try.
So off we go into the unknown. I say unknown because none of us knows for certain how/if it will work and produce the results that we're after. We do know that it will be "our" process. We’ll continue to test assumptions, adapt the process to what works, and practice the continuous improvement of Kaizen. Our goal (or hope) is that we'll increase efficiency better tracking of our work and more insight into our capacity. We expect we'll even out our workload by only taking on what we can accomplish and proactively adjust the schedule and manage customer expectations accordingly. We expect we'll be more scalable with the ability to take on more work with equal effort, more predictable as we'll know what we're able to do and when, and more measurable as we'll track our effectiveness and capacity. We're going into our first mapping session. We'll see how it goes.