A Gorilla Primer: What the heck is Agile?

"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.

Agile is:

• 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.

Okay, and?...

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.

Anything else?

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.

Joel Bancroft-Connors

The Gorilla Talker

Want me to talk to your gorilla? Send me an email, jbancroftconnors@gmail.com

You can follow me on twitter, @JBC_PMP  

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

The Gorilla Product Owner: It takes a village

Note: For new Gorilla Blogs, head over to The Gorilla Coach

"Bob," Jake's tone was almost plaintive. "You're killing me here. I thought we had this all sorted out. Didn't we just spend three days doing ideation work?"

Bob looked pained, he wasn't happy and it showed. "We did and I thought we were sorted as well." He gave a shrug, "Sales got wind of the requirements and threw a royal fit that we weren't addressing performance on the OutDate hardware."

"They do realize it's a fifteen year old platform?"

Bob nodded, "And they insist it's a must have to support 'key' customers."

Jake grumbled, "fine, that explains that. What about this other stuff?"

Bob winced, "My boss isn't happy with the strategy, he wants to alter course."

I glanced over the new proposal. I made a note to talk to Bob about the concept of the word 'alter.' This plan was nearly a 180 from the previous one.

Jake threw his hands up in the air, "I give up. Every time I think we're settled and I can start planning, the entire model changes again. Who the hell is in charge of the business plan?"

I could see Bob stiffen at that one. He didn't respond, even though I could see he was rankled by the comment. I think he didn't respond because he knew he really wasn't in charge, even if his job description said that he was in charge. He had tried to put together a business plan and now, every time he turned around, someone was sticking a hand in and changing it.

"Sounds like you need to start the project before you start the project?"

"What is it this time, Hogarth," I asked with no small amount of dread. Turning to face him I continued, "I've got Bob fully engaged with development, they've been meeting regularly. I've got an honest to goodness PO led product backlog for the first time ever." I waved at the business plan on the screen, "and it's all been tossed out the window. What's the point? We are halfway through development and this is a huge shift in direction."

Hogarth nodded, "Which is why you need a project before the project."

I blinked, "Wait, what? That's Big Design Up Front! We're agile here!"

Hogarth gave me a huge, ivory filled yawn. "We covered this already, remember? Garbage in, Garbage out?"

I pointed a finger at Hogarth, "look here, I did that. Bob went through the whole process. We even brought in Jake and his team to look at some of the requirements. Our backlog was built on real requirements this time!"

Hogarth nodded, "And who else helped?"

"Huh?"

Hogarth gave a long stretched before fixing me with his dark gaze again. "You wouldn't design the features without the agile development team, why design the business plan without an agile business team."

Blink, blink. Well dang…

A Product Owner is Not an Island

Experienced agilists will of course be saying "duh" right about now. Product owners are supposed to work with the team and collaborate towards a final product. This is good and effective, and the PO can still be an island if they do this. He just has seven other cast-aways, from his three hour cruise, on the island with him.

Beyond even the question of "how do you prioritize the business value of the backlog," are questions like "what's the business model," "what's the product concept," and "where does the product owner get his requirements from in the first place?"

The product owner is not an island. He doesn't sit in some ivory tower and imagine great ideas, which he then transports to the development team in a puff of smoke smelling faintly of brimstone. Our product owner, still called a product manager by many companies, instead is sometimes reduced to nearly the level of a scribe collecting all the inputs from other parties and trying to justify how to have the product be "fast", "ultra-secure" and "cheep." The product owner must work and take inputs from a wide variety of sources in an often dizzying array of inputs and conflicting priorities. When every organization is clamoring for their little slice of the feature pie, you can end up with a product that looks more like Frankenstein's monster than Brad Pitt.

That's just the way it is, you can't expect that to change.

It can if you make a village.

In Garbage In, Gorilla Out I propose a new model for the early stage of a product. In what most lifecylces would call the Concept and Planning Phases I propose an iterative, agile driven, style that takes you from product ideation (vision) all the way to a well ordered backlog that the agile development teams can plan their iterations from. While I don't speak to this in the GiGo blog, in essence, what I am espousing is an agile project where the finished product is a product or release backlog. So if GiGo is an agile project, where is the team?

In GiGo I briefly touch on the idea of the GiGo project team. It is not just the product owner that moves through the GiGo project. With her on the journey are representatives from her key stakeholders. This is not a fixed team and will vary from company to company. Ideally it won't be more than seven, plus or minus two people which may require some team members to then go off and work with an SME team of their own. For example a representative from Technical Support might have their own Support GiGo team where they review and bring back final "product" to the primary GiGo team.

Who should be on the team? Other than the product owner, again it depends. Below is a list of common team members based on the most common roles to contribute to traditional requirements documents.

Product Sponsor	Customer  (or voice of the customer)
Related product managers	Technical Support
Technical Architect*	Marketing
Agile coach or Facilitator	Sales

While the product owner is the final decision maker, she is not the only person to have input into the creation process. When the PO works with a village, they prevent the customer, sponsor and team from getting PO'd at them.

Do you have your village?

Joel Bancroft-Connors

The Gorilla Talker

Want me to talk to your gorilla? Send me an email, jbancroftconnors@gmail.com

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

Agile, a Gorilla four letter word

"No, no, no, no. You're doing it all wrong. For the love of Peet, it's an easy process to follow."

Eric shrugged. "Yeah and we found that it wasn't working with our schedule cycle so we tweaked it."

I rolled my eyes, "Look, the system works, we just have to trust the system." I glanced down at my watch. "Look, I have to prep for my next meeting. Can you close the door when you leave."

Eric blinked, shrugged and walked out of my office. As the door shut I leaned back in my chair with a deep sigh.  It was taking so much work to make the team more efficient. If only they'd just see this was the way to an easier path. Well, at least I'd gotten management to cough up money for training. The entire project had nearly fell face first into the chasm because the CFO had heard productivity increase and rushed us straight towards agile, ignoring all my "people need training" reminders. Our first pilot was nearly our last when nobody had a clue what they were doing.

I rubbed my temples. I'd had to work fast on that one, pulling together a cost benefit analysis to prove that spending money on training would gain us more improvement than going back to the old development model. Leaning back in my chair I stared at the ceiling. Now if I could just get the teams to stop playing around and do things right.

"Why not left?"

I really need to change the lock on that door.

"You don't have a lock on the door, how can you change it?"

I really need to put in a lock, and then change it. "What do you want, Hogarth?"

"Why does everyone want to do things 'right'? Couldn't we try doing it left for once."

I was about to tell Hogarth that he was making no sense, but then I thought better. Whenever I did, he always made me look like an idiot by then making complete sense. Sigh… "I want to do it the right way, because that's the way it's supposed to be done."

Hogarth sauntered across the room to where a large philodendron sat. Pulling a leaf from the plant, he took a large bite before turning back to me with a sour look on his face. "You know, I much prefer the fichus." I just gave him a baleful stare. Tucking the half eaten leaf back into the pot he settled down against the wall. "The way it's supposed to be done," he repeated.

I just nodded.

"Question, isn't this release going like gangbusters? Don't you expect to ship in half the time and with a much higher quality?"

I nodded, a note of pride slipping into my voice. "Yes."

"Then why are you worried about being right? It's working, isn't that the most important thing?"

"But they're not following the process!" I snapped in frustration. "If they just followed the process, it would be so much better."

Hogarth scratched the back of his thread as he asked, "Remind me again, the first principle of agile is what?"

I peered at Hogarth in confusion. "Really?" He just gave me a "humor me" shrug and stared at me. Sigh, "all right. The first principle of agile is 'Individuals and interactions over process and tools."

"Uh huh… And how are you doing with that?"

Blink, blink… Sigh. I really hate it when he's does that.

Has Agile become a four letter word?

Worse than that, is it a three letter word? Is agile in danger of becoming the next Management Fad? Nothing is worse than being placed in a bucket with such Fads as "Business Process Reengineering." You know, the Fad that said if we make the process better, even a bad team will improve?

Shudder…  We don't want that, do we?

Well guess what? It's happening. I think this tweet sums it up all to well:

Is it me or are there a lot of people drinking the #agile #scrum kool aid? How bout just focus on being effective? #agile #scrum #pmchat - @tonybruce77

This worry isn't anything new. Nearly as long as the Agile Manifesto has been around there have been people calling it a Fad. On top of the typical Fad drivers, there are disturbing trends inside of the agile community that are just as harmful.

Here are a three viewpoints.

1. Poor adoption of agile has driven us into the chasm: Back in Feb, 2011, Agile Focus posted a blog on agile falling in the second chasm. It argues that "there is a vast army of supposedly Agile teams and companies that have adopted the look and the lingo while totally missing the point."

I tackled this Gorilla back in "Indiana Gorilla and the lost artifacts of agile." It is certainly an issue, and one that is not unique to agile. If you have $100,000 racecar, but the driver can't drive a stick, then he might declare the car useless. This point argues that it might just be that you need to train the driver. The inverse also applies. Many companies have "tried" agile, only to mark it as useless because of poor implementation. If you don't read the manual, you to can end up bumbling around like the Greatest American Hero.

My Soapbox: Agile isn't a get rich, quick scheme. You can't toss in a few standups and call it good. It's a cultural shift. A set of beliefs and ethics that require a company to change more than just how it tests. You don't do this overnight and you don't do it without training. To get better, you have to invest in getting better.

2. That's not agile! You're doing it wrong!: Mike, over at Leading   Answers, created the Periodic Table of Agile Adoption.  While Mike posits that, like the real elements, there is no good or bad Agile adoption I'd point out that you really don't want to get Cesium anywhere near water. And like real elements, there are elements of the agile community that are a little explosive when they perceive you as "watering down" pure agile.  On the Agile Periodic Table, there are some fairly vocal and forceful Ze1s out there and enough Zealots and Fundamentalist pounding on the "That isn't the way to do it" drum that we are seeing a growing backlash to agile. Not because agile has issues (it does, but that's not for today), but because these passionate agilists are being perceived as shoving it down people's throats. Like the fur protestors with their cans of red paint, they go to extremes to make their point. The extremist just might be driving people away.

My Soapbox: I personally come down somewhere in the Te6 or Re6 transformational/revolutionary blending area of the chart. Agile is one of many tools in my toolbelt and I'll use what works best to help the team, company and myself be successful. Given that I tend to get really upset with those at the Ze1 end of the spectrum. Why? Because one of the first tenants of agile is…

"Inspect and Adapt"

If you don't change and adjust as you go, then how can you call yourself agile?

3. Agile isn't New!: The Agile Manifesto was signed in 2001. In the last ten years, the term agile has exploded across the world and become one of the rising trends that every business is keeping an eye on. Only the concept of agile isn't ten years old, only the word agile is ten years old. The concepts of agile are a lot older. The first Scrum team dates back to the early nineties. Customer focused development concepts were a major fad in the 1980's. Lean (which some will fervently  argue isn't agile, but we won't go there today) goes all the way back to Toyota's post WWII reconstruction. And some have given good arguments for the roots of "agile" being in the Hawthorne Study of the 1920's.

My Soapbox: Agile is a buzz word. In many ways agile is the PMI of its day (Yes, I just went there). Formal Project Management dates back to the 1950's, but it wasn't until the late 1990's that it really began to gain traction. Organizations like PMI (1984) and methodologies like Prince (1989) and Prince2 (1996) brought a measure of formality to a decades old profession.

But the biggest thing PMI (Prince2 in the UK/Europe) did was to give everyone a common language. It took what people had been doing for years, and gave everyone the same words to use for it. Earned Value means the same thing to me, as a project manager in Dubai. It does because of PMI, Prince2 and others who helped to create a language around project management.

The Agile Software Development Manifesto did the same thing for what most of us now think of as agile. Agile is the word we've all agreed on to use. Don't let the word get in the way of long standing and good principles.

So is agile in danger of becoming a Fad?

Yes- And that's a good thing:

The underlying principles of agile focus on the customer and the team. These are good foundations to have and the popularity of agile has given attention to these foundational principles.

Yes- And that's a bad thing:

The near fanatical drive that some agilists have, combined with the "get rich, quick" attitude of many companies, who try and implement on the quick, are leading us down a road that could cause a perfectly good set of values to be cast onto the rocks of management faddom, to languish next to jazzercise, Tai bo and the grapefruit diet.

So what would you call it?:

Margaret Motamed, host of the BayScrum Meetup recently described what she is doing as "Collaborative Management." A lot of use would insist she's agile and those Z1s would probably say she was just gaming the system. I think she might be on to something.

Right now I don't know what I would call it. If I say "agile" you all know what I mean. If I call it "Flexible" then you're not going to know exactly what I mean.

If I had to describe it in a single sentence:

"I believe in a customer focused, iterative process that is executed through a collaborative effort of the team and company."

And I have one simple measurement to if I'm being successful.

"Are we doing better this week, than we were last week? If we are, then we win."

Joel Bancroft-Connors

The Gorilla Talker

Want me to talk to your gorilla? Send me an email, jbancroftconnors@gmail.com

You can follow me on twitter, @JBC_PMP 

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

Don't play Planning Poker with the Gorilla

Note: For new Gorilla Blogs, head over to The Gorilla Coach

"10 Days" Eric said.

I sighed. "Eric, you're supposed to use the planning cards and put down a value."

As he flipped through his stack of cards I could see him counting to himself. "Okay, fine. I think this is an 89 point task"

Sigh… "Eric, you just counted out ten cards and put that card down."

"Yeah, so?"

I leaned forward and tried to use my calmest voice. "Eric, we're not trying to figure out how many days right now, we're trying to do an abstract estimate on the relative size of each story in the whole project. "

He waved his hand, "What's the point? If we're painting a house and you ask me to estimate how long it will take to paint the garage door I can put down a 2 or just tell you two hours. You're asking me to use an abstract number when I already know how long it will take."

I sat back in my chair perplexed. The problem was that I could see his point. We were tackling each task one at a time and no matter what I did, I couldn't break the team out of thinking about how many days something would take. And I knew this was a slippery slope that led back to padding, swags and a whole slew of inefficient planning practices.   

A long meeting later I dragged myself into my office. Only to find both my chair and the guest chair occupied. One of the occupants I expected to be there, a post meeting debrief on this last meeting was much to much for my personal gorilla to miss. Seeing the black swan flipping playing cards onto my desk was quite another thing.

Flip, flip, flip "144!" Hogarth said, triumphantly.  Looking at the black feathered swan he grinned. "Hah, that beats your 21."

"Hogarth!?" You'd think I would get tired of yelling his name. Or maybe I would just get used to his ever present level of restrained chaos. You'd think... "What are you doing with my Planning Poker decks?"

"Oh, hey there," Hogarth turned his cheerful smile my way. "Wanda and I were just playing war."

Tossing her last card, a 2, down Wanda slid off the chair. "I have to get back to the server room anyway, one of the HVAC's is about to short out because a gopher climbed on the roof and ate through the power cable."

Trying not to think of electrocuted gophers and overheating servers, I ignored the departing black swan and turned my attention back on Hogarth. "Why are you playing war with my Fibonacci cards?"

"Oh, that. Well I figured you might want them and then we just kind of got bored waiting for you to be done not estimating the release."

I blinked at him. "Hogarth, I know you were eavesdropping on the meeting. You know perfectly well the team thinks planning poker is useless." I tossed myself into the vacated guest chair with a sigh. "And I'm not sure I don't disagree with them."

"Since when have you believed there's only been one way to use a tool?"

Blink, blink… Why did he always have to be right?

Story Point Estimating

This is one of the foundational principles of Scrum software development (and Agile  in general). Done well, story estimating can create an incredible level of predictability and transparency. A high performing team can look at a set of requirements and provide a high confidence assessment of when they will done.

But this isn't about the value or use of estimating. There is plenty written on this and I'm not here to rehash it. I believe in estimating, just as I believe in the principles of agile and good management.

What I'm hear to say is I think Planning Poker  is the wrong way….

What? Come on, I'd be a lousy gorilla talker if I wasn't willing to tackle tough subjects head on. I do absolutely think story point estimating is the right thing. I just think planning poker is not the best way to do it. 

Naturally this begs the question of "why?" I have two reason for my concerns on the use of planning  poker:

1. Each user story (feature, tasks, item) is evaluated on its own. When you do planning poker you are just looking at how long it will take to paint the garage door. You are hard pressed to look at it in relation to putting a new latch on the back gate. I think the mind is hard pressed not to assign a physical value to the estimate. "I think this will take two hours, that's about a 3."
2. At the end of the day, the planning poker process occurs in an individuals head.  Yes, there is a discussion among the team, but only after each person has drawn a line in the sand. Once the human mind draws a line, it finds it hard to move that line. We've invested ourselves in that line.

So what the heck do you do?

Well if you've been following my recent agile related blogs, you'll know I'm a very big fan of something called the "Team Estimation Game" developed by Steve Bockman. I personally like to call it "Team Planning Solitaire." The style of the game reminds me of classic Klondike solitaire and the interaction of the team makes it anything but a solo activity (what can I say, I like irony). I will also note that while I learned this from Steve Bockman and Agile Learning Labs , I have seen some similar exercises in the last few months. Whether they are parallel development or evolutions of Bockman's game, I don't know.

I detailed how this game worked in "How much is that Gorilla in the window." At the highest level, the

Process starts with the story cards in a pile. Each person takes a turn laying out a new card or moving an existing card on the table. At the end, you have a line of cards in rank order. Only then do you break out the planning poker cards. Your estimates end up being based on the relation to the other stories, not to how long one story will take.

Why is the Team Estimating Game so good?

1. Stories are estimated in relation to one another and not in a vacuum. "Is painting the garage door more or less effort than replacing the latch on the back gate? All right, is painting more or less effort than rehanging the front door."
2. It's a team activity. Nothing happens in anyone's head. It is all out on the table and very straight forward. You aren't sitting there arguing that the Database re-architecture will take a week or two weeks. You are just trying to decide if it is more or less effort that localizing the user interface to Japanese.

At the end of the day I think Team Estimating is much more effective than planning poker. Leave the poker cards for a nice game of Klondike or Texas Hold 'Em.

Who's ante is it?

Joel Bancroft-Connors

The Gorilla Talker

Want me to talk to your gorilla? mailto:jbancroftconnors@gmail.com

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

The Gorilla Coach: A book review of Coaching Agile Teams, by Lyssa Adkins

Coachin Agile Teams

Note: For new Gorilla Blogs, head over to The Gorilla Coach
 

"You've got to do something! We can't keep going like this, the entire project is going to collapse in on itself."

Eric certainly had a way of getting my attention. I had instant visions of red project dashboards and burn down charts flat lining like a patient in the ER. Eric was one of the canaries on the project. There are always those certain team members that reflect the state of the project or are the first to see a major issue. Like the miner's canary of old, they are the first to notice or raise the issues and a smart manager learns to pay attention. These are not to be mistaken for the Chicken Littles, who can give a hypochondriac a run for their money. When a canary sings, you listen to their song.

I held up my hands and spoke in a calm tone. "Okay, Eric, calm down and tell me what the problem is. I'm sure we can get this addressed."

Eric took a deep breath and paused for a moment, as if suddenly unsure he wanted to continue. I gave him my best supporting smile and waited.  Finally finding his voice he said, "It's Greg, he smells."

I blinked. "Smells?"

Eric nodded, perhaps a bit too energetically. "No one wants to pair program with him. Heck no one wants to be within six feet of him. It's like a mouse crawled into his shirt and died. Given the last time he changed his shirt it could well have."

I sat back in my chair, a frown threatening to crease my brow. "This can't be happening to me," I thought. My next thought was to look across the table again. If Brenda were sitting there, this would have been another "The sky is falling" moments and I could have dealt with that like all the other times the sky didn't really fall. Only this was Eric, the most reliable barometer of the teams health available. It meant that either Eric had gone off the deep end or the problem was very real.

So now what? This wasn't a slipped schedule, we didn't have a shortage of test machines,  it wasn't even the completely useless requirements or product manager owner was foisting on us. No, I was being asked to deal with someone's smell."

They didn't cover this in project management training…

"What would coach do?"

I turned to cast a baleful look at Hogarth.

"This isn't a football game."

My gorilla gave a little nod. "Good thing too, cause you stink at football."

"Hogarth you are not helping me solve this problem."

He nodded again, a brilliant white smile splitting his face. "Nope, I'm not and you shouldn't be either. Solving Eric's problem isn't going to help him solve it in the future, now is it?"

Dang… he was right.

BOOK REVIEW: COACHING AGILE TEAMS, By Lyssa Adkins

Summary:

This book had been recommended to me many times, by many people. It forms one of the core study books for PMI's new agile certification and you'd be hard pressed to find a conversation on agile coaching that doesn't reference this book or the author.

Like me, Lyssa Adkins is a recovering command and control project manager and this is one of the things that makes this book resonate for me. While many agile authors have always been on the revolutionary/evolutionary end of the innovation scale, Lyssa had worked in the trenches of traditional projects and speaks to all audiences. Whether you are an eccentric software coder, turned agile visionary, or a former art major, turned project manager, turned aspiring agile coach, this book will speak to you. Very importantly, it speaks right to project managers "in transition." Based on the traditional roles that project managers have filled, the scrum master role often ends up being a place project managers end up gravitating to as they journey into agile (or are shoved feet first by events, company, etc.) so this book is a great asset to them.

With 302 practical pages of content, there is a lot to absorb. It is not an evening's light reading. Some of the concepts and mental challenges they raised had me setting the book down so I could process. All in all, it took me several weeks to read the book as there was so much to absorb and my mind wasn't ready for it all at once.  But there was no way I was not going to finish this book.

The book is broadly laid out into three sections and the first hint you have on what it takes to be a good coach is that two of the three sections have to do with you.

• It Starts With You: Starting with the obvious "will I be a good coach?" question, this section lays down the ground work to open yourself up to what is needed for you to be a good coach. Along the way it teaches you a lot about yourself.

• Helping the Team Get More for Themselves: This section covers six aspects of being an agile coach, from the high level mentor concepts to the details of how a coach can help resolve conflict in a team.
• Getting More for Yourself: One of the things I truly appreciate about agile, is its stance on failure. Lyssa's book is no different and this section tackles head on the mistakes you will make and that it is okay to make them as long as you learn from them. It touches on the journey and knowing when you finally get there (Hint- you never do).

The Good:

Approachable Style: Lyssa writes this book in a conversational tone and weaves in direct experience throughout the book. You constantly have a strong sense that she is speaking from her own hands-on experience and her light style makes absorbing the deep content a lot easier.

Failure is okay: She knows that the journey to being a coach is going to have its bumps and bruises and she makes that okay. Instead of feeling like you are facing an insurmountable journey to be an agile coach, she reassures you that the potholes are just part of the journey. The most wonderful experiences are not found in the well manicured aisles of a department store, they are found out in the wilds of the world.

Lots of practical tips: The book isn't just theory and platitudes. She provides solid tips, actions and exercises. She also provides tailoring to help you deal with all aspects of an agile organization, not just the agile development team.

The Not So:

No punches pulled: This could arguably be in the good things, you just need to be aware about it. Lyssa doesn't pull punches and she's not going to white wash this. If you are not ready to let go of your control freak nature, this book will be hard to read. You'll put it down more than once and walk away. You will also learn really fast if you really want to be an agile coach. It is not a job for everyone. I still want to be one, but this book certainly tested my mettle.

Broad base may not appeal: If you are a hardcore scrum master, who is totally focused in on the artifacts of scrum and only scrum, you may find this book to broad for your tastes. Lyssa comes off fairly agile agnostic. This book is about helping any team, in an agile way, and this may not be pure scrum enough for some. Again, this could be argued as a good thing. I would hazard a guess that is part of why it ended up on the PMI reading list.

The Bookshelf Index: (Where does this book when I am done reading it?)

In my computer bag: This book speaks so much to what I want to be and how I want to engage with teams that it has not left my computer bag since I started reading it. It has quickly become a well worn copy and I will continue to refer to it regularly for some time to come.

Joel Bancroft-Connors

The Gorilla Talker

Want me to talk to your gorilla? mailto:jbancroftconnors@gmail.com

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

How much for that Gorilla in the window? - Assigning value to requirements

 

Hogarth shoveled another handful of popcorn into his mouth (Yes, gorillas like popcorn - read the right sidebar, go figure). He was sitting at the end of the table, size huge feet propped up on the table and looked as if he were thoroughly enjoying himself.

Which couldn't be said for me. I turned back to the discussion at the table, wishing a crack in the earth would open and swallow me up.

"Every one of them is a P Zero feature." said Tully, the junior product manager. Though I swear I could see Bob's lips moving as Tully spoke.

We were in the Icarus project's concept phase exit meeting.  Product management had just presented their list of requirements for Icarus. The entire list was up on the projector screen, two columns wide and in ten point font. I had surreptitiously taken a photo with my phone and was zooming in just so I could read the list.

"But which one is the highest priority?" Jake asked. This meeting was where engineering saw the requirements for the first time and started looking at what could be done. Feeling like I was in a tennis match, I let my eyes swing back toward the two product managers.

"All 100 features are must ship, they are the same priority."

I was starting to feel like I was witnessing the start of a train wreck and there wasn't a damn thing I could do about it.

"Look, even if we could do all these features in the release, which we can't, you still would need to prioritize them so you can flesh out the top of the backlog. None of these are good enough to start developing on." Jake was keeping his voice surprisingly calm.

Bob had apparently gotten tired of the ventriloquist act and spoke up. "Are you saying you're only going to estimate the top items?"

Jake sighed, shaking his head. "No, we can give you a relativistic estimate on everything, with this data. But none of these features is defined enough for the team to start work. I've got no idea what to start on in the first sprint." He laid his hands on the table, "Look, if you can't prioritize them then you have to do full user stories on all of them and I'll just pick which one to do first. That's fine by me."

"But we can't do that, it would take weeks to flesh out all these features, and besides the requirements might change."

Jake shrugged. "Then we need to find a way to rank order them. I can do effort estimates on all of them and just start on the easiest ones first."

Oh boy, Jake was playing hardball now. Bob leaned over his laptop with a pained expression. "The easy stuff isn't what the customer wants right now."

Jake leaned back. "Well at least we're getting somewhere."

At this rate, this was going to be a long meeting and it wasn't going to solve anything. Against my better judgment, I turned to cast an imploring look at Hogarth. Wiping his popcorn encrusted mouth with the back of a furry arm, he reached into the popcorn bucket and pulled out a deck of Fibonacci cards.

"It works for story points…" He offered.   

What do we do first?

Today we talk about one of the fundamental problems with product requirements. Last week's "Garbage In, Gorilla Out" focused just on the need for good requirements. This is important, vitally so. A well executed project, built on bad requirements is a bad product (Can you say HP Web Tablet? I knew you could)

The problem is, then what?

If I have one hundred perfectly defined features what do I do with them now? I can hand them off to the development team so that they can give me a level of effort (Story Points in Agile). That's great, but now I have one hundred perfect features with story points. I still don't know which one to do first.

Business value: What is the value of this benefit to the customer and/or  the business? This can also be asked in reverse, "what will it cost us to not implement this?" (Kanban tends to look at it from this view point). If you don't know what the value of the feature/user story then you don't know if it is more or less important than the next feature. You then end up in the model some old style engineering managers love. "Just give me the list of what you want, I'll figure out what I have time to build."

Technically perfect and customer flawed.

Apple has constantly focused on the value. Products they delivered did exactly what you wanted them to do (sometimes even doing things you didn't know you wanted, but now can't imagine how you would ever live without). Being a PC guy, this has sometimes been a hard pill to swallow. I've seen the exact opposite with PC products. "Do I really need 7mm instead of a 9.5mm hard drive? What I would really like is it if it included Bluetooth so I didn't have to have a separate set of headphones just for my computer." PCs have been really great at offering up new features that had no real infrastructure to use right away while lagging on basic,s like user interface.

Great, I'm sold already, how?

Ah and there in lies the rub. How do you figure out business value? Raise your hand if you've seen a product management forecast you believed in. Yeah, thought so. So if we have trouble figuring out how much we'll sell of the whole product, then how do we decide the value of a single feature/user story? Some companies have put together very elaborate procedures for this that practically call for a Ph.D. in math. Reportedly Intel has eighteen value "levers" used to evaluate not just projects but features in a project. Yikes.

Reaching into the agile pool isn't a lot of help either. While a whole blog of its own, the core issue with the most common estimating technique, Planning poker, is that it focuses on one feature at a time. And the problem with that is the human mind. Say I'm playing planning poker on a home improvement project. The user story is "As the home owner I want a blue exterior because it will make my house blend in with the skyline." Okay, painting the house. No matter how hard I try I'm going to be thinking about how many hours I'm going to need. When I flip over the 13 I've just mentally associated three days with 13. So of course a one day project is a 5, right?

When you evaluate each feature on its own, it is very hard for the human mind to not associate time with it.

So don't…

Steve Bockman developed an estimating process called "The Team Estimating Game." He and Agile Learning Labs have been using the game for years, teaching teams and companies this new way of estimating story points. Last year, Agile Learning Lab's maven Laura Powers realized that it could be used for assigning Business Value.

And?...

And with permission of Agile Learning Labs, I'm sharing their excellent game. After attending a Product Owner Training, I wrote down what I learned and have been using it ever since.

The Exercise: Take the defined user stories. These can be at any level of detail, but obviously it is better if they have some basic story decomposition done and they are clearly understood by the product owner and other business stakeholders. It is best to start with no more than twenty stories. After completing the game with these stories, future stories are then played against this initial set of stories. This makes subsequent evaluation go quicker and allows for estimating the value of hundreds of stories.

Phase 1: The first step is to estimate their value relative to each other:

1. Place Story Cards in pile on table.

2. First player places top card on playing surface.

3. The second player places the top card on playing surface relative to first card. They decide if the card is worth more business value or less than the original story.

4. The third player then has several choices. They can either:

* Play top card from pile, placing it on the field where they think it fits (moving other stories to fit between stories as needed), or

* Move a card on the playing surface from one location to another, or

* Pass

Note: When placing or moving a card the person conducting the action typically gives a short explanation. So long as it does not derail the conversation, team discussion is encouraged. The Agile Coach/Facilitator monitors this and if a conversation starts to deep end they ask “So whose turn is it now.”

5. Repeat Step 4 until

a) no more cards remain in pile, and

b) no player wishes to move a card

At the end of the first phase of the game you have a single, linear line of user story cards. The cards to the left are deemed the least valuable and the cards to the right are the most. No overlap of cards occurs at this time.

Phase 2:  Having ranked each story to create a single ordered list, it is now time to assign a value rating. 

Start with a standard deck Fibonacci numbers. Typically up to 144 is more than sufficient. Add to this the (-) card, to represent stories that have no business value. Note: Business value may not represent the only value in a project. You may have regulatory concerns, infrastructure concerns, etc. Whenever possible try to assign a business value to the story. This usually requires looking at the operational This may require asking the “what do we lose if this is not here?” Zero business value should be truly something that will not be missed in anyway if it is not in the product (“No one really wants a wood stove in their car”).

1. Place the (-) card to the left of the left most story. Anything that moves left of this card will be considered of no business value.

2. Place the “1” Card over the left most story. This story now represents your baseline that all other stories are measured against.

3. Hand the deck to the first player. The player takes the “2” card from the deck and then looks at the stories to the right of the “1” card. They place the card at the story they think is twice as valuable as the first story.

4. The third player, then has several choices. They can either:

* Place the “3” card to the right of the “2” card where they think a story is either three times more valuable than the first story or is one and a half times more valuable than the story with the “2” over it.

* Move the “2” card left or right to where they think the user story is equal to twice the value of story one.

* Pass

Note: Fibonacci Cards are placed on the table in order. You do not place the “21” card until the “13” card has been placed.

Note: Any stories between Fibonacci cards are assumed to belong to the Fibonacci number to its left. So if there are three stories between the “5” and the “8” then it is assumed those three cards are considered a value of “5.”

5. Repeat Step 4  until
1. All stories have an assigned value (not all Fibonacci cards must be played), and
2. All players pass on adjusting any of the Fibonacci cards.

Concluding: At this point any “orphan” cards, those between Fibonacci cards, are then moved into columns below the Fibonacci Number to their left. You are now left with a number of columns of cards (there is no right number).

The exercise is done. Capture the value for each story in the appropriate manner.

Important Note: The Coach/Facilitator should watch for ranking based on cost. This exercise should be conducted with the “infinite budget” concept. “Don’t worry about how hard it is to build right now, just worry about how valuable it will be.”

Important Note: If you are planning to have these stories estimated for cost (time to develop), it is recommended that the business value not be shared with the team doing the cost estimating. This prevents the cost estimating being skewed by the Business Value.