Category Archives: Scrum

Sprint Planning start well, end better. 

Posted on by
Reply

Photo Credit: Pixabay- WOKANDAPIX

“Plans are worthless, but planning is everything.”

Dwight D. Eisenhower

Has any of this happened to your Scrum Team? 

  • The team regularly takes on more work than they can complete in a Sprint.
  • Work is removed from the Sprint because it could not be completed.
  • The quality of the final work is low, with many issues found after the Sprint.
  • Stories grow in size during the Sprint as more work is discovered.
  • Arguments erupt on the right approach to getting work done.
  • Sprints looked successful, only to have the stakeholders say it doesn’t meet business needs.

These challenges and more can be traced back to poor Sprint Planning. 

The Basics of Sprint Planning

Sprint Planning marks the start of each Sprint. It sets the overall tone for Sprint. Good Sprint Planning leads to a good Sprint. A Sprint that doesn’t generate value is creating waste. 

Let’s start with a quick primer on the five Ws of Sprint Planning:

What? (Definition)A planning event to create the Sprint Backlog, which answers the questions: “Why are we doing the Sprint?”, “What work will be done?” and “How will the work be done?”. 
Why? (Purpose)To create alignment on the purpose and work needed to deliver on the Sprint Goal. 
When?Sprint Planning is the first event inside the container event of the Sprint. The Sprint starts when Sprint Planning begins. 
Who?The Product OwnerThe DevelopersThe Scrum MasterStakeholders and SMEs as needed
How long?Two hours per week of Sprint

Now we’ll unpack some of these to understand better and learn how not doing them could impact your Sprint…

Unpacking Sprint Planning

Why do we do Sprint Planning? 

We do Sprint Planning to create alignment and purpose around the Why, What, and How of Sprint Planning. 

  • Why is it valuable? (Creating the Sprint Goal.)
  • What can be done in the Sprint? (Populating the Sprint Backlog.)
  • How will the chosen work get done? (Breaking down the work)

If we don’t answer all three questions, we don’t have true transparency of the work and how it connects to the whole. 

The most common places I see Sprint Planning, and by extension the Sprint, fail is with the Why and the How parts of Sprint Planning. 

There is no Why: No Sprint Goal.

The Scrum Guide defines the Sprint Goal as “the single objective for the Sprint.” To this definition, I add it is “a concrete stepping stone towards the Product Goal.” 

If your Sprint Goal does not connect to your Product Goal, then you are not “maximizing the value of the product resulting from the work of the Scrum Team.” Without value, you can’t be profitable. Without profitability, you can’t be a sustainable business. 

Defining a Sprint Goal at the beginning of Sprint Planning is critical. Defining the goal upfront allows all the work pulled into the Sprint to support the Sprint Goal, enabling the output and outcome of the Sprint to contribute towards the Product Goal. 

There is no How: The work is not understood.

One of the reasons for Sprint Planning is to create alignment between the Product Owner and Developers. Alignment is not just between the Product Owner and the Developers. It is also between the Developers. Does the database expert know how the business logic person will implement their work? Is everyone clear on how the end product will be tested? How will we demonstrate this? If the team is not asking these questions in Sprint Planning, you are headed for rocky waters.

Who attends?

Many Agile teams treat the Events like secret Star Chamber meetings requiring a password to enter. Scrum works on the fundamental pillar of Transparency. Without transparency, everything else in Scrum will suffer and eventually fail. 

With Sprint Planning, transparency is essential as it is the last chance to refine and understand the team’s work in the Sprint. Inviting the business stakeholder to provide greater context, or the Architect, to work through some design questions can be the difference between a Sprint Review where everyone says, “That was awesome!” and one where you hear, “That’s not what I wanted” or “You realize that’s not security compliant and you need to redo it?”

How long?

The Scrum Guide says: 

“Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.”

Eight hours? That’s an entire day! Are you serious?

Let’s do a little math here. A one-month Sprint is, on average, 20 days or 160 hours. Eight hours is just five percent of the total time of the Sprint. Five percent!

Now let’s look at a typical waterfall project. Twenty years ago, the projects I managed were typically 12 months long. The first three months of that project were back and forth between product management and development on precisely what would be built with no code being written (for this release) for at least two months. Plus, the product managers had previously written requirements documents for at least two months.

Twelve months, with two months spent in “planning.” That’s 16 percent of the release spent on planning. And let’s be honest, that’s probably on the low side by a generous margin.

So, yes, two hours per week of Sprint is not only reasonable, it’s responsible. We’ve already looked at the two common failure patterns above. Lack of sufficient time is not only our third failure pattern, it also causes the first two. 

And let’s remember; the Scrum Guide says “a maximum of.” If the team finishes before the timebox, no one will complain and demand you all stay until the timebox ends. Schedule the time so you have it. Nothing is worse than having a two-hour meeting and finding out you needed two hours and fifteen minutes. 

In the next section, I’ll show you my agenda for a two-week Sprint.  

Agenda for an Effective Sprint Planning Event

The following is a recommended agenda flow for a two-week Sprint and has a four-hour schedule. 

PhaseActivityTimebox
Set the StageWelcome attendees and set expectations~5 min
WhyThe Product Owner describes a possible Sprint Goal and then discusses it with the Scrum Team~10-20 min
WhatFinal Refinement and Estimation occur on Product Backlog Items (aka stories) that the Product Owner desires for the Sprint~15-45 Min
WhatThe team reviews their availability and past performance to determine their potential capacity for the Sprint~10-15 Min
WhatPopulate the Sprint Backlog with the Product Backlog Items that will meet the Sprint Goal~15-30 Min
HowThe Developers plan how they will complete the items in the Sprint Backlog~2 hrs
CloseTake a final confidence vote, thank the team, and end~5 min

1. Set the Stage: In their book Agile Retrospectives, Esther Derby and Diana Larsen say, “Setting the stage helps people focus on the work at hand. It reiterates the goal for the time the team has together in the retrospective.” The above is good advice for all the Scrum Events, and I start Sprint Planning by thanking everyone for their time and reminding them of the purpose of Sprint Planning.   

2. Establish a Sprint Goal: We’ve already discussed how failure to create a Sprint Goal or even creating a Sprint Goal after deciding what to do is one of the top reasons Sprints fail. If Sprint Planning sets the tone for the Sprint, the Sprint Goal sets the tone for the planning. 

The Product Owner should come prepared with a recommended Sprint Goal. This Sprint Goal can result from the Sprint Review the day before or based on other strategic work. To be effective, the Sprint Goal connects directly to the Product Goal. The team then discusses, refines, or changes the Sprint Goal. 

3. Final Refinement and Estimation: You should already be doing regular Backlog Refinement to keep your Product Backlog topped off with regular work. That said, Sprint Planning is the “last responsible moment” to do refinement. Check out the Scrum Alliance article linked above for more on Refinement. 

Generally, I see three kinds of refinement happening during Sprint Planning. From most common to least, they are: 

  • Reestimation of work
  • Updated Acceptance Criteria
  • New, usually urgent, work

Reestimation can happen at any point up to when the team starts working on the item. Say that the last refinement session was the Thursday before. Since then, Sunil has been rummaging around the data layer and has discovered several new connections to other processes. Sunil returns to the team and says, “I think we underestimated the complexity.” The estimate for the item could change right there in Sprint Planning. 

Acceptance criteria are how the Product Owner can shape the value of the work. The PO may want the new login page to be 25% faster than the last one. Martha has been looking left, right, and sideways at the code, and she doesn’t think the team can squeeze more than 15% out of the current system. The PO then decides if getting the new login page now is more important than getting it to load faster. The PO wisely decides now is better and agrees to change the AC to a 10% improvement. 

And finally, remember that the Product Backlog is dynamic and emergent. New items can shoot to the top of the backlog overnight. The Product Owner may bring a brand new item to the team and ask them, “Can we refine this and include it in this Sprint?” While this should be uncommon, it should also be possible.

4. Determine Sprint Capacity: How much work can the team do on average? Will anything impact the team’s ability to work this Sprint? A great example is what to do when a major holiday falls in the Sprint. Instead of the team shortening the Sprint, they consider how this will impact them. If the entire office shuts down for a week, then the team’s capacity is 50% of what their velocity says they can do.

5. Populate the Sprint Backlog: Once you have a capacity guide for the Sprint, the team can fill the Sprint Backlog with work that supports the Sprint Goal. There are many ways to do this. Just remember that the Developers pull work into the Sprint. The Product Owner decides if the work to do has value and contributes to the Sprint Goal; the Developers decide how much work they can do in a given Sprint. 

6. The Developers plan how they will complete the items in the Sprint Backlog: This is the most frequently forgotten — and therefore problematic — part of Sprint Planning.

 Here’s how I explain this to  students:

 “When Sprint Planning starts, you are coding! Not all coding is hands-on keyboard typing. There is whiteboarding, design conversations, coordination, and more.”

If the developers need to look at the code to determine how they will build something, then look at the code. Scrum Masters, this is one of the places you are most needed. Ask questions, and seek clarity. Does the team understand what they will do, or are they planning to “just figure it out as we go?” That’s not Agile; that’s just lazy. 

The How phase is the most time-consuming part of Sprint Planning. Done well, it prevents rework and conflicts (people, process, and product). It allows for a greater chance the team will deliver a usable increment of value (AKA done work the customer cares about) at the end of the Sprint. 

Here are some things Developers should be doing in Sprint Planning:

  • Break work down “into smaller, more precise items.”
    • AKA create individual tasks that represent the technical work needed to complete the Product Backlog Item. (UI work, DB work, code review, create automation tests, etc.)
  • Whiteboarding the design
  • Sketch the user interface
  • Review existing code
  • Anything required to plan how to complete the work

Breaking work into tasks is vitally important and should never be pushed out with a “we’ll figure it out later.” Tasking allows for: 

  • Remembering the work: Five days from now, will you remember what you discussed in the Sprint Planning meeting? And if you didn’t even talk about it at Sprint Planning, do you remember when you did talk about it? 
  • Alignment: How will the UI work fit into the Business Logic work?
  • Track Progress: If you break work into tasks of no more than four hours, your burn-down charts will reflect progress toward the Sprint Goal more accurately. 
  • Create stronger teams: When the team breaks work into bite-size pieces, it often allows someone with less skill to pick it up and complete it. This benefits the team in creating more cross-functional members and benefits the individual who gets to improve their mastery. 

The Product Owner during the How

What does the Product Owner do during the How part of Sprint Planning? Unfortunately, the typical pattern is “See you all later; let me know how it goes.” 

“The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.” 

– The Scrum Guide.

The work is still all about value. If the Product Owner isn’t present, important questions might go unanswered, acceptance criteria can’t be tweaked, and problems not detected until too late.  

The PO should be present and available. Their presence will ensure a continued alignment to value. 

7. Close: Closing can be an under-appreciated part of good Sprint Planning. In Agile Retrospectives, the authors say, “End the retrospective decisively: don’t let people (and their energy) dribble away.” 

Remember the maximum timebox. If the team is still going strong at three hours and fifty minutes, the Scrum Master can ask the team what’s needed to wrap up. Maybe they didn’t get all the work planned out. What will they do about that? Do they need to de-commit some work before the Sprint starts? 

One of the things to do here is to collect a confidence vote. Now that the Developers have planned the work, how confident are they that they can complete it all in the Sprint?

Using the Fist to Five consensus framework is an excellent way to check on confidence.

Working with multiple teams

What happens when a Product Owner is supporting multiple teams? This is not immediately a bad thing. The Scrum Guide even has a suggestion:

“If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.” 

The critical point here is that to be effective, the Product Owner must only have one Product Goal at a time. The next question will be, “How many teams can one Product Owner support?”. 

My answer is 2

There are other answers and arguments, and we’re stepping into scaling conversations now. My experience is that a Product Owner becomes exponentially less effective beyond two teams. Once you move to four teams, you need to insert a scaling practice to have someone focused on the longer term while Product Owners continue to be sleeves rolled up and engaged with no more than two teams. 

In practice, the way I’ve coached Product Owners supporting two teams is as follows: 

  • Shared Backlog Refinement
    • Not everyone has to be in refinement sessions. Ensure you have representation from both teams and that all skills needed to complete are represented.  
  • Shared Why and What Sprint Planning
    • This allows alignment, horse trading of work, managing dependency, and more. 
  • Individual How
    • Do these at the same time with the PO floating between both teams. 
  • Individual Daily Scrums
    • Stagger them so the PO can go to both
    • A representative from each team should go to the other Daily Scrum
  • Individual Retrospectives
    • The PO rotates attendance every Sprint
    • Every quarter or so, do a combined retro on overall ways of working. 

A good Sprint Planning Event creates Value and Quality

The concept of “Starting on the right foot” is not just a trite saying. If you want to improve the quality of your work, improve the quality of your Sprint Planning.

Gorillas can be Agile with any project

Posted on by
1

Some days I was so thankful for the fact I worked in a three story building. It made the urge to toss myself off it, to end the misery, so much less. Unless If I  was really lucky I’d just end up hurting myself and that would just add to the miserable condition I was in.
Hogarth was right… Oh how I hated to think those three words. It was becoming such a common occurrence that I was considering adding to the law’s of nature. The sun comes up in the east, politicians are lying when their lips are moving and Hogarth is always right. This time it had to do with my implementation of Agile. Agile may be the silver bullet of development but I hadn’t had the first idea how to properly implement it.
So I’d swallowed the pill and went out and figured out just what Agile was. Leaning back in my chair I took in the remains of that discovery. Highsmith was leaning on Adkins and the two were threatening to push Cockburn off the desk. Larsen and Cohn were glaring at me from under the coffee cup perched on them. The books stared back at me mutely, mocking my pain and despair. Tilting my head back to stare at the ceiling I moaned. “Kill me now…”
“What and miss all the fun?”
I kept my eyes closed and used every ounce of my will to imagine away the voice that had spoken.
“Not gonna work,” Hogarth replied. “Your subconscious really likes me, so you’re stuck with me.”
Pulling my gaze from the acoustical tile I fixed Hogarth with a baleful gaze. “Remind me to schedule myself for a lobotomy.”
Hogarth was perched on the large window ledge. His black fur shimmering in the afternoon sunlight and his face was split with a contended grin. “Now why on earth would you want to give up all this?” His huge paw swept in an all encompassing arc that took in my cube and then the rest of the office beyond.
“Because there is no way on earth I’m going to get the company to adopt Scrum for real!” I poked at the stack of books. “It’s a far cry between some structural artifacts and the real meaning of Agile and the company is about as unagile as you can get.”
Hogarth nodded, “Well yeah, I think we covered the whole artifacts part already” He snaked an arm out the open window and broke off a branch from the tree outside. Snacking on the branch he said, “You’ve recognized the real problem so what’s the issue?”
“There is no way on earth I’ll ever get this company to go agile.”
“Agile or Scrum?” Hogarth asked.
“What’s the difference?” I shot back.
“A single sapling a forest does not make…”
Scrum is an Agile Framework – Scrum is not the only way to practice Agile.
When these kind of comments are thrown out, the typical response is something like “Well of course, there’s Kanban, Lean, or XP.”  And those folks are right, these are other frameworks or methodologies  of Agile. And at the same time I think we end up missing the bigger picture. To understand this, we need to look into the roots of Agile.
Agile has two foundational roots. The most obvious is the gathering of software luminaries that created the Agile Manifesto. Agile wasn’t some earth shaking new concept. What it was, was the joint thinking of seventeen software developers who had been practicing various lightweight development methods and how what was the common, foundational values of these methods.  At its heart Agile was a new language to explain long standing best practices, values and principles. If you think about it, in a light weight Agile way, it is the Agile PMBoK. (Remember that the PMBoK is also not a methodology, but a set of standard terminology and guidelines for project management.)
The other foundational root goes back to the precursors of Lean manufacturing, to the Toyota Way. Like the Agile Manifesto, it was not until 2001 that Toyota published the “Way.” But in Toyota’s case it was not for lack of use. Toyota revolutionized automotive manufacturing with their unique style and for decades US companies tried to match it. It’s not as if Toyota was a walled garden. They cheerfully gave tours of their plants to any and all comers. Why? Because they knew the artifacts of their process were not the key. The key was their six underlying principles, such as “Respect for People,” and “Add value to your organization by developing your people and partners.”
So what’s your point?
Ah yes, this is not a history lesson and I am trying  to make a point.
Today I read a great blog that sums up my point nicely. Ben Horowitz wrote about Lead Bullets, on TechCrunch. The kernel of this is to not go looking for the silver bullet solution, instead use the bullets you have and shoot better.
I’ve heard stunning success stories in the use of Agile Methodologies (Scrum, XP, Lean, etc.) In nearly all of these instances, the support and engagement was across the board high. It was the right time, the right people, the right need and so on. The Perfect Project Storm. In these cases the silver bullet was the only bullet and it was a dead shot.
And I’ve seen people try and use the Agile silver bullet and have the organization smother them alive. I like to remind people that silver bullets only work against werewolves. If you are facing a ghost, you’re kind of out of luck. When faced with an organization that is highly resistant, highly process driven, highly dysfunctional, etc. trying to dive into the deep end of the Agile pool tends to only end up in the Agile project and team being drowned.
I’m even more depressed now, wasn’t there a point?
Yes! The point is Agile isn’t just an umbrella over methodologies,  like Scrum and Lean. Agile is a set of guiding principles that can be used ANYWHERE. Where is it wrong to have good teamwork? When is it wrong to make sure the customer is getting what they want? If the process plan says to roll the parts cart around the outside of the building twice, before entering, is it wrong to ask “Why?”
Enter the Agile Manager. You don’t have to be using Scrum to be Agile. You can use the principles of Agile anywhere . You can make any team better, if you try.
In short, don’t let bad methodology get in the way of good management.
Focus on the team and the project will improve. That’s Agile.
Joel Bancroft-Connors
The Gorilla Project Manager
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP

Indiana Gorilla and the Artifacts of Agile

Posted on by
Reply

“Okay and Eric, you were working on the shopping cart ordering story, right?”
Eric nodded, but remained silent.
“And tomorrow you should be done and moving on to the Wish List story, right?”
He nodded again, still silent. He was a good engineer, never spoke unless he really had something to say.
“Any impediments?”
Eric looked around the table at the other seated engineers. None of them met his gaze, intent on their own computers. Then he shrugged and turned back to me. “No.”
“Ah, excellent!” I gave a thumbs up sign to the assembled team. “Great stand up, guys, I’ll see you all again tomorrow.”
I happily began entering data into my uber status report spreadsheet and didn’t notice the engineers talking quietly amongst themselves as they filed out.
I was cheerfully humming away five minutes later, when Hogarth wandered in. I looked up and pointed at my uber sheet projecting on the wall screen. “Man, this Scrum stuff is great! I love the daily standups. Just great to have everyone giving daily reports on their status. Can you imagine? A year ago I had to hound them for their slide decks every week and I almost never got a full report.”
Hogarth cast a glance at the screen, before he flopped down near the window. Reaching out the window he pulled a branch from the tree outside. After a careful examination of the branch, he used it to point at the screen. “Pretty picture, but you know its completely wrong, right?”
“What!?” I turned to stare at him. “What on earth are you talking about? The project is going great! Look at that burndown! I just cross referenced it with my detailed MS Project file and we are at least a week ahead of schedule. We’re doing AWESOME!”
Hogarth shook his head. “Nope, all an illusion. Take Eric for example, he’s got a massive database integration issue that’s going to end up making all of his stories crash and burn. He’s stumped on how to solve the problem and it is going to cascade into a total failure of the storefront in about two sprints.”
I blinked. “What on earth are you talking about? Eric just walked out of here and he didn’t say word one about any issues.”
Hogarth nodded, pealing a long strip of bark from the tree branch. “Course he didn’t, no point saying anything if you’re not going to listen to him.”
“What?” I said incredulously. “We just had our stand up! I was sitting right here! I didn’t set up all these Agile meetings just to have things be the same as before!”
“Just because you have the magical artifact, doesn’t mean you have a clue how to use it.”
“What?” I hated it when Hogarth spoke in riddles.
Hogarth rolled his eyes. “You remember in the original Indiana Jones, the Germans had the Ark of the Covenant?”
I stared at Hogarth, “I don’t have time for movie quizzes, Hogarth.” He gave me a “humor me” look and I sighed in surrender. “Yes, I remember. It ended pretty badly for them.”
Hogarth nodded. “Ayup, they had the artifact. But they didn’t know how to use it. If you put a MacDonald’s fry cook in the Iron Chef kitchen, he’s not magically going to become a great chef. The tools don’t make the chef, the chef does.”
I stared at him for a long minute.
“Ah, crap…”
Agile Artifacts vs. Agile Values: Holding Daily Standups, planning work in two week iterations, and tracking progress on a burn down chart are all excellent tools for the Agile team. They are not  Agile. Agile is a set of values and principles. It’s more about the how of team and not the what of the product.
You can’t take a handful of engineers, start having them meet once a day, and declare yourself Agile. Like Hogarth’s examples from above, having a tool (A Daily Standup is a Tool/Artifact) and knowing how to use it are two entirely different things. And the more advanced that tool, the more knowledge you need to use it.
Back in college I got a part time job at a little coffee shop/deli (Back before Starbucks took over the world). The owner was a quiet Turkish man who wouldn’t let me touch the espresso machine until after I’d learned not only the history of coffee but the why’s of exactly how the machine worked (this was an old manual style machine, no automatic buttons or anything). I must have frothed gallons of milk before he let me pour a single ounce into a customer’s cup. He told me, “To make good coffee, one must first understand coffee.”
Success in Agile requires a look beyond the tangible of meetings, code drops, requirements documents and into the heart of how the organization runs. The values and principles are as much, if not more about the team and not the product trying to be made. Make a better team and you make a better product.
Throw around a bunch of Agile Artifacts, like a five year old using a Ginsu Steak knife set, and you just replace one bad process with another.
Joel Bancroft-Connors
The Gorilla Project Manager
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP

Armchair gorilla

Posted on by
4

– Or walk a mile in the gorilla’s shoes

This blog inspired by Tobias Meyer’s recent blog “Scrum is not Project Management”
Normally I don’t let Hogarth follow me home. There are limits and that’s just one of them. The thought of an 800 pound gorilla on my couch is a terrifying one. And then there is what he does to the refrigerator. Did I mention gorilla hair on the white carpet? But it was the Superbowl and I had a moment of weakness.
“Come on! You call that a pass? My mother can throw better than that.” I angrily waved at the TV while speaking through a mouthful of Dorritos. “Can you believe this guy, Hogarth? That play had blitz written all over it. I swear even a deaf bat could have seen it.”
Hogarth looked at the dried banana chip poised to be popped into his mouth, then looked at me, then looked back to the chip. Sighing he lowered the chip and gave me a reproachful look.
“How much football have you played?” He asked.
I looked aghast, “Me? Last time I played footbal, it was with flags and I was still too young to vote.”
Hogarth gave a sage nod. “I see. I bet you didn’t even stay in a Holiday In Express last night.”
It was my turn to sigh. “Okay, okay, I get the point. Not only am I not there, but I’m not a quarterback, have never been a quarterback and don’t have the first clue how to be a real quarterback.” I shook my head, “I’m sitting here trying to second guess the expert. Talk about stupid.”
Hogarth nodded again. And then he spoke, his words breaking the 4th wall and my own train of thought. “So why are you trying so hard to prove Tobias wrong?”
I turned to stare at Hogarth my mouth agape. No sound came forth despite the repeated opening and closing of my bass like mouth.
Why indeed?
I make my living doing a job that typically has the job title of “Project Manager” or “Program Manager.” Given that, it may be understandable to you that my emotional reaction to Tobias’ blog was to disagree.  I certainly did this initially. The first few comments I thought about leaving to his blog were much less reasoned than what I ended up posting.
And then, much like my revelation in “A Project Manager’s Poker Hand,” I came to a realization that I was trying to impose my own value on someone else. Worse yet, my value was based purely on emotional reaction, where as the opinion espoused by Tobias was based on subject matter expertise.
Yes, I have Scrum training, I’ve studied Scrum and I’ve even incorporated some Scrum concepts into product development efforts I’ve been involved in. But I am most certainly not a Scrum expert. I’ve never worked on a classic Scrum team and I can’t speak from first hand experience.
Tobias on the other hand has. He is a recognized expert on Scrum teams and Scrum development. Without my own “traditional” Scrum experiences, I have to put faith and trust on Tobias speaking from that expertise.  I don’t know enough about a straight Scrum project to know if a “traditional” project manager would bring any value. I certainly hope to learn and understand more as I delve into the Agile philosophy, but for now I have to take Tobias at his word. Just as the Product Owner must trust the teams estimates, I should trust Tobias’ expertise.
So as the saying goes, “Don’t judge another, until you’ve walked a mile in their shoes.”
All right, so Scrum is not Project Management.
What is project management then?
It was something of a wake up call to read some of the very acerbic comments posted both in Tobias’ blog and Ken Schwaber’s blog that inspired Tobias’ blog (Yes I’m a response to a response). That people think project management is an evil tool of “corporate” or an “idea whose time has passed,” was not something to cross my mind. Even Ken’s own words had me blinking in confusion.
“We have found that the role of the project manager is counterproductive in complex, creative work. The project manager’s thinking, as represented by the project plan, constrains the creativity and intelligence of everyone else on the project to that of the plan, rather than engaging everyone’s intelligence to best solve the problems.”
“Wow, that’s not the project management I know” was my initial thought. I certainly have never felt I was stifling creativity or constraining anyone’s intelligence. I was an art major in college and write science fiction as a hobby, not exactly what I would think of as an oppressive personality. Yet, the comments posted certainly had me wondering. I had to check myself in the mirror and make sure I wasn’t wearing a black mask and breathing funny. <Darth Vader voice> You underestimate the power of project management.</voice>
So before I accepted my role in the dark side of corporate america, I decided to look for other definitions.
PMI’s PMBoK defines project management as:
“Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.”
And they define a project as:
“A project is a temporary endeavor undertaken to create a unique product, service or result. ”
Okay, so not the most evocative words ever written. And I can already see issues with the definition of a project and the normal evolution of software. When version 1.0 ships, the team has usually already begun on version 1.1. Is the project the software as a whole or just v1.0. What is “done”?
Wikipedia, font of all knowledge, real, imagined and inaccurate, defines project management as:
“Project management is the discipline of planning, organizing, securing and managing resources to bring about the successful completion of specific project goals and objectives.”
And Wiki defines a project as:
“A project in business and science is a collaborative enterprise, frequently involving research or design, that is carefully planned to achieve a particular aim.”
Okay, so neither source’s definition is going to make a kid say “Daddy, I want to be a project manager when I grow up.” And honestly, neither source really describes what it is I do in my day to day job.
Certainly I spend time organizing and planning. I’ve both helped develop goals and objectives for a project and served as a gatekeeper to ask if we’d met them. Goodness knows I have built a lot of knowledge, practiced a lot of skills and developed a big old toolbox of techniques. But I don’t think that defines what I do in my job or why my boss keeps paying me to do that job.
I know some folks think of project management as the “Owner” of a project. I’ve known project managers who “owned” the project. They were the almighty power and controlled the budget, the people, the project and final deliverables. This does still happen, but at least in the high tech firms I’ve worked for, this is less and less common. The guy in charge of building a bridge is a project manager and also the head engineer, this guy is the “owner.” A guy managing a software team doing an IT integration project is not the “owner”. The team all report to functional managers and the guy managing is more like the cat herder (We won’t go into the myth today).
So what is being a PM mean to me?
Well not to sound like a broken record, but I would stat by reaching back to my “The gorilla with too many hats” and “Project Managers are SMES” blogs to start answering this question.
“If you have four engineers working on the project…, adding a fifth one is already starting to hit that wall of diminishing return. If you add a program manager, you can get more productivity from those four engineers, than you would from adding a fifth engineer and expecting one or more of those engineers to also manage the customer relationships, deadlines, certifications, interface with marketing, etc.”
“A Project Manager’s SME knowledge is in getting a project from inception to launch with in the bounds of the project’s constraints and while keeping the team from flying apart like wine glass shattering when it hits the floor.”
I’ve been doing dedicated project/program management for a decade now. In that time I’ve never had any illusions of being “in charge” of a project. Long before I heard the first utterance of “Agile” or “Scrum” I was practicing servant-leadership.
I am the broom:  Pam Stanton as well as a good friend and fellow project manager, Carl Jones have both used an example that I think speaks to what a 21st century project manager is. They compare our job to that of the game of curling. The curler and the stone are the product/project team and the product being built. The Curler’s (team’s) goal is to get the stone (product) to the center of target area (release date, objectives, value needed, etc.). The Curler is the main person. Without him you don’t have a game. But he is not alone.  The sweepers use brooms to alter the state of the ice in front of the stone.
A good project manager is like a curling sweeper. He gets in front of the product and makes sure there are no impediments (Test equipment was ordered, team has a place to work, external vendor is managed to deliver its dependencies, etc.), but also makes sure those things that have to be done (certifications, compliance, sponsor updates, etc.) get done.
Over the years I’ve developed my own personal philosophy/methodology to being what I am as a professional:
  1. People, not projects
  2. It’s all about communication
  3. Process is a tool, not a roadblock
  4. There is no one, right way
I don’t know if I’m a traditional project manager or program manager. I know I’m not a traditional scrum master and there isn’t even a standard definition of an agile project manager. But at the end of the day I don’t think any of that matters. Because what I know I am is:
Effective
Joel Bancroft-Connors
The Gorilla Project Manager
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP

Gorilla Book Review- The Elements of Scrum

Posted on by
1

 

There is something eternally satisfying in closing the back cover of a hard copy book. Especially when the book was such an enjoyable read.
In this age of reading books on Kindle, iPad, printer paper or listening via serial podcast or audio book format, reading a good old fashioned book still has so much emotional content tied up in it. Perhaps the millennial generation will/does feel different, but for we of the Pong generation I think the physical book will always remain a comfortable thing. I love reading on my mobile device and there are some books I truly prefer that way. But not Elements of Scrum.
I had just laid the book down, flipping through the final index pages with an all too satisfied grin of completion. Staring at the blank screen of OneNote I was trying to mentally compose just what I would say about my experiences reading the book.
And like any unasked for distraction, Hogarth wandered by just as I was preparing to type.
“Whuz thad?” he said. At least I assume he did, the spray of partially eaten donuts made it hard to tell.
I looked down at the book, “Elements of Scrum, I just finished reading it.”
Smiling brightly, Hogarth grabbed the book up. “Ooh, the periodic table, I love the periodic table!”
I sighed, “No, Hogarth, not chemistry elements. It’s a book on the fundamentals of the Scrum Methodology.”
“Oh, so elements like Scrumium, Standupum, TDDine, and Taskon?”
“Go away, Hogarth…”
The Elements of Scrum, by Chris Sims and Hilary Louise Johnson
I’ve had the pleasure of seeing Chris Sims in action. Chris is the founder/head coach for Agile Learning Labs. A self professed former, aspiring rock star and software coder, Chris’ real talent lie in his ability to engage a room. His coaching style is very dynamic and engaging. Anyone looking to sit at the back of the room and soak up some knowledge, should not attend one of Chris’ trainings. If you want to roll up your sleeves and walk away with hands on practical knowledge, Chris is your man.
My biggest question, when I picked up EoS, was if Chris could take that in person coaching style and translate it to the printed word. I had my doubts. Chris is a hands on trainer, I don’t think I’ve seen him use more than a half dozen PowerPoint slides, ever.He’s a phone first, email days later, kind of guy and I wondered if he’d be able to distill down his thoughts to a cohesive print product. Chris, however, is a smart coach and in collaborating with Hilary I think he found the person who could focus his in person stories and translate them to the printed medium.
EoS is a great mix of approachable writing, great anecdotes and simple pictures, both the ones drawn into the book and the pictures the words easily formed in my head. The nearly 200 pages flew by quickly while giving me some excellent new perspectives on the use of Scrum. For readability I found it outstanding.
Elements is not a complete “how to” book of Scrum, that’s not the goal of the book. It’s laid out a lot like one of Chris’ trainings, and will give any reader a strong foundation in the basics of Scrum. Even though I’ve taken scrum master certification and have been an active agilest for some time now, I still came away from this book with a deeper knowledge of Scrum’s core fundamentals. That says a lot for a $30 book, that it can still teach you some new ideas after taking a two day training class.
The final positive point I can give it is where it will live, now that I’ve read it. EoS will find a place on my ready reference shelf in my office cube. When I need to check something on Scrum, it’s only an arms length away and finding information in it is google easy.
Well worth the cover price.
Thank you and talk to you next time when I’ll share with you my “Pot Hole Project Management” philosophy.
Joel BC
Veteran, the Project Manager wars
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP