Processing Into Agileby Bryan Peterson on 06/21/11
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.