"It's all rather simple." I said confidently. "It's a process to maximize our transparency so that we can deliver the maximum effectiveness of end purpose value to our constituents while ensuring the highest possible predictability in deliverable milestones ."
Hogarth cocked his head to the side, "I'm not following. I thought this was supposed to be easy?"
I tossed my hands in the air energetically. "It is! That's the beauty of it. Why the framework for one implementation can be summed up in ten minutes."
"Really, so what's the value?" Hogarth asked.
"Total optimization!" I beamed. "Using a collaborative team structure you generate value in an iterative cycle that completely optimizes your process and maximizes customer return."
Hogarth looked at me for a long moment. Finally he reached up to scratch his chin. "Huh… I'm still not sure I'm following. How is this different from waterfall?"
I jumped up "Totally different! It will change the world!"
Hogarth shrugged, "How?"
I let out an exasperated sigh, "Have you been listening to anything I've said? Haven't you read anything about this?"
He nodded, "Yep and I'm still not understanding what's in it for me." He opened up his arms, "If you're going to sell me on a new way of doing things, you have to tell me what's in it for me and you need to use small words."
"What's in it for you? Why that's…."
Well damn, the gorilla was right again.
What the Heck is Agile?
A blindingly simple question that is a lot harder to answer than one might think. Trust me readers, I will get to the answer, just bear with me a moment as I expound.
I'm an experienced agilist, I speak about agile often, and I write about agile regularly. And the other day I found myself trying to explain agile to a program manager who had zero knowledge of it.
Wow… It's not that easy.
First problem, where to start? I took part in the May 11th #PMChat twitter chat, which had a topic of "An Intro to Agile." It was a great Tweetchat, with a lot of valuable information. Only it would have been better called "An Intro to Scrum." That's great, it was a good topic and judging by feedback, very informative. Only Scrum isn't all that is agile. When discussing agile, do you start at the nuts and bolts, or do you start at the overarching philosophy?
Or maybe… You start with the user.
User Stories: Skipping ahead to an advanced lessons, we find that User Stories are different from requirements in that they are focused on the benefit given to the user. So maybe we should be using the same concept to explain agile. Today is version 0.1 (zero dot one [zed dot one for British folks]) of my agile primer.
Let's look at our users and what agile can do for them:
Company President- Do you want predictability? Do you want happy customers? Do you want happy shareholders?
Agile is a company initiative that creates more predictability in releases and allows the company to quickly adapt to the customer's needs. Through happy customers your company has happy shareholders.
Product Manager- Do you want to be able to change your mind? Did your customer change their mind? Do you want what really matters, when you need it?
Agile is a flexible product design process that allows you to adjust the product to meet changing customer priorities. What ships is what the customer really needs (and will buy).
Manager- Do you really want to be looking over your team's shoulder every day? Do you want to help your people grow, not just make the next code drop?
Agile gives your team the ability to what they do best, create. It gives you the ability to do what you are best at, helping your team grow.
Project Manager- Are you tired of chasing down everyone with the age old "What's your status?" Are you tired of living in the DMZ between product management and engineering?
Agile is founded on transparent communication and puts deep focus on collaborative solutions that have the whole team working towards a common goal.
Developer- Would you like development model that puts the power in your hands? Do you want to decide how to build something? Do you want management to listen to you when you say it will really take three weeks?
Agile lets you be directly involved in helping to define how something will get built and even what gets built. The company puts its trust in you to make decisions and listens to you when you say how long something will take. Schedules are based on what can be built not some artificial line in the sand.
Great, so what exactly is Agile?
Ah yes, once we get past the benefit we still have to figure out just what agile is.
An early attempt I had at a one line summary is: "a customer focused, iterative process that is executed through a collaborative effort of the team and company."
Yeah, I know, with that kind of double speak I should be in politics.
- Listening to the customer throughout the entire development process, not just at the beginning.
- Focusing on the team. A better team makes a better product. Trust in the team.
- Building with GPS. You're constantly making sure you're on course.
- Learning from mistakes, not just writing them down at the end of the project.
- and -
- Not new. The term is new, the ideas reach back decades. We owe the Agile Signatories for helping bundle the concepts into a single word.
- Not a methodology. It's a set of principles and values. Below these are frameworks like Lean, Kanban, Scrum and XP.
At its barest essence, that is what agile is. It's not some secret, make it all perfect, sauce. It's hard work and incredibly rewarding. It's moving from shareholder value to customer value. Go read the Agile Manifesto. It's not about process, it's about results.
Right, that and four dollars will buy you a cup of coffee. What do we do with this? Good question. Agile itself isn't a solution. Agile is a mindset, a way of thinking, of interacting. You still need a framework to work within. The are four common agile frameworks, Scrum, Kanban, XP and Lean.
In a nutshell:
Scrum- Is characterized by its iteration cycle. At the start of a sprint (1-4 weeks), the team commits to working on a certain amount of the Product Backlog (Everything we want built). They meet each day to review progress and impediments. At the end of the sprint (iteration) they demonstrate working results (no PowerPoint). Then the team reflects on how the team did and what can be done to get better.
Scrum can be very good for new development, where uncertainty is high, change is constant and the customer is involved.
Kanban- Kanban has evolved from Just in Time manufacturing concepts. Its primary characterization is the WIP, or Work in Progress, that limits what can be pulled from the Queue (What needs to be done). It does not work in iterations, instead working in available workload. By limiting work in progress, you limit waste and generate greater focus by reducing multi-tasking. It's other driving factor is it starts with where you are now, and works to get you to a better process. Where most frameworks are replacements for existing methodology, Kanban focuses on continuous, incremental improvement from where you started.
Kanban can be very good in maintenance, where each item is often unique.
XP- Extreme Programing is probably best known for the concept of pair programming. XP is known for pushing the limits of traditional practices (hence "Extreme"). It also uses short iteration cycles, typically, one week max, as well as demos and retrospectives. It is also heavily leverages code reviews, unit testing and automation. Typically more so than Scrum. The average person will see little external difference between XP and Scrum.
XP is very common with start ups and for projects that extremely dynamic or have few starting requirements. You are rapidly prototyping to a final product.
Lean- This practice is best characterized by the elimination of waste. Anything that does not create value for the end customer is considered wasteful and a target for elimination. It's a "do more with less" framework that at works primarily thanks to strong principles that oversee the structure. Toyota's Total Production System is the most common example of Lean.
Note: Some will argue that Lean isn't agile. Not being an adherent to any one framework I see Lean as sharing many of the same principles and thus put it under the loose umbrella of agile. It's easier than calling them all "customer focused, iterative development practices that focus on the team."
Lean is most common in manufacturing, where the product is relatively fixed and the improvements are focused on how to produce the product better.
Oh, Gorilla, yes. There are stacks of books and gigabytes of blogs on agile. I can't even begin to scratch the surface with all my blogs. Let me leave you with some additional resources and one last thought.
Elements of Scrum- Great primer book on the Scrum methodology. I reviewed it last year. The authors also just released a 50 page super primer. Only $0.99 on Kindle.
Mountain Goat Software- Mike Cohn is one of the leading educators of agile. His web site is full of information.
Agile Leadership Network- Find a local chapter. Meet people who also believe in changing the world.
Wikipedia- Seriously, the articles on Agile are very extensive and a great way to get started.
One last thought: All the above is a fairly basic and fact based review. I'll want to leave you with why I use agile. We've spent several decades with companies focused on shareholder value. I think the time is coming to swing back to focusing on customer value. We've also spent the last several decades focused on getting more out of our teams. I think it is time to start giving more to our teams.
I think agile is the key to these changes. I think the values and principles of agile and lean will change the world for the better.
And I want to help.
The Gorilla Talker
Want me to talk to your gorilla? Send me an email, firstname.lastname@example.org
You can follow me on twitter, @JBC_PMP
Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.