Gorilla Book Review- The Elements of Scrum

 

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

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

The Responsible Authority Gorilla

The project meeting was moving forward very well. We were tracking on everything and it looked like we'd actually have the release out on time, and with everything we wanted in it. We had just gotten to the issues with the flux capacitor redesign work and I asked Paul, the engineer, when he would be able to give an updated report on completion.

Paul shifted in his seat, stealing a glance at Jake but said nothing. Jake, the development manager,  leaned forward and spoke, "I'm taking Paul off this project, I need him to rebuild the prototype simulator. It's running 10% slow and I don't like that."

I did my best to keep my mouth from gaping open. Without the flux capacitor redesigns, this maintenance release would be all but pointless. Nodding my head I said, "all right, then let's look at the next item on the agenda…"

After the meeting I slipped back to my cube, looking forward to ensconcing myself behind the safety of my monitor. The fury black form reclined on my desk told me I wasn't going to get that opportunity.

"May as well cancel that maintenance release, huh?" Hogarth said, casually peeling a banana.

I shrugged, "Not my call, I just track the projects. I don't have the authority to change resources." I shoved aside Hogarth's feet and flopped into my chair. "Jake thinks work on the simulator is more important, Paul works for him."

"I didn't think the simulator was even gonna be used until next year."

Resisting the urge to complain about Hogarth's banana breath I gave another shrug. "It's not, but I have no authority to change things."

"So what? That doesn't mean you don't have a responsibility!"

The Authority vs. Responsibility Gorilla. I think we are all familiar with the lack of authority gorilla . I've yet to meet a project manager who never had to run a project in which he had little or no real authority.  But how many of us think about, the responsibility gorilla?

Authority- Dictionary.com defines authority as

The power to determine, adjudicate, or otherwise settle issues or disputes; jurisdiction; the right to control, command, or determine.

"The Power"

I get all tingly when I read that. Reminds me of the 1980's cartoon, He-Man, and his magical transformation (work safe video) from medieval geek to super hero. There is a small problem with this. At least in Silicon Valley high tech power is practically a fundamental myth. Mark Horstman, of Manager Tools, maintains there are three kinds of workplace power. Role Power, Expertise Power and Relationship Power. Role power is the power a boss has, the power to hire and fire, to make decisions that will affect everything in his organization.

Role power in the 21st century is a myth. Anyone who tries to operate exclusively on role power will ultimately fail. Without a healthy measure of expertise and, especially, relationship power that manager is headed for a short career.

Still the concept of authority does exist and all to often a project manager has limited or no authority on their projects. So what do we do? Do we throw up our hands in despair and give up?

Like bloody hell we don't.

We are project management professionals.

What does this mean? Great question! A web search for the definition of "project manger" returns back thousands of answers. Some of these answers are contradictory to one another, but there is one theme that pops up over and over.

"The person responsible for the project"

Responsible. The word makes me feel all grown up and mature, but it is the key to this concept. In fact, let's take the grown up analogy a little further. When Tommy gets suspended from school, for throwing spit wads, his reaction is "But the other guys were doing it!" And if you grew up in the United States you are probably familiar with the stereotypical parental answer, "And if all the other boys jumped off a cliff, would you?"

PMI members reading this should be familiar with the PMI Code of Ethics and Professional Conduct. This code is mandatory for all PMPs and I personally think is part of what can set apart a PMP from other structured project management certifications. If you look with in the code you will see two key points.

1.1 Vision and Purpose

As practitioners of project management, we are committed to doing what is right and honorable. We set high standards for ourselves and we aspire to meet these standards in all aspects of our lives

2.1 Description of Responsibility

Responsibility is our duty to take ownership for the decisions we make or fail to make, the actions we take or fail to take, and the consequences that result.

There it is again, responsibility. And the big kicker in all that "and the consequences that result." If we don't take responsibility then we have to be prepared for the consequences.

This is where the professional part comes in. As professionals we are under an obligation to be responsible.

Quick and Dirty Example:

In the United States, citizens have the right to vote. It is not a requirement but a civic right. And with this has become an often repeated concept. "If you don't like how the country is being run, then vote. If you don't vote, then be quit complaining."

A real world example:

One of my project management jobs was in a global support organization. The job had two key components; ensure the support organization was ready for each software release, and feedback into future projects support's experiences from supporting previous releases. This later responsibility was a constant challenge. We ran into roadblocks, barriers and just plain confusion. Some projects didn't have a way to roll in lessons learned, others didn't want any outside input, and so on. It made for many a long and stressful day.

So what did the support planning group do? We decided to be the most professional and helpful group humanly possible. We made sure our house was in order. We made our processes transparent, we published our templates, we communicated constantly in all directions and we adopted one of the most powerful tools in communication.

We stopped saying "no" and we started "yes, and". It's a trick I first learned in improvisational theater and one that made perfect sense when my boss suggested it. We no longer said "No, you can't ship this it's not stable" and instead said "Yes, you can ship and here is what we expect the call volume will be and how much those calls will cost."

These two changes, openness and "Yes, and" made a dramatic change. In a few short months we had addressed more critical support issues than we had in years of prior work. And the more fascinating thing we saw, was how other groups started to change their own processes and procedures. It's a bit thrilling when you see another department using a document that is clearly based on a template you designed.

We didn't have real authority. We couldn't change the products being built, we didn't have the power of the purse that sales can wield so well. But we did know we were responsible for support being able to do its job and we took that responsibility to heart, being the best and most professional we could.

Conclusion:

No matter what our authority level, project managers can never surrender their responsibility. It is our job to help a project from point A to point B. We may be the CEO anointed leader, fully empowered to hire and fire at will, or we may have little more authority than updating the Gantt chart. In either case though, we have the power of influence, the power of experience and the responsibility to, at the very least, be the most professional and helpful person we can be.

We are the glue.

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

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

Like what you read? Then please tell a friend, tweet it, put it up on your wall, or send out smoke signals.

Effectiveness is the new Gorilla

- Or, saving time does not save work.

[Before we dive into another, great Gorilla, I'd like to ask a favor. If you find these blogs informative, please post a comment. If you find them really valuable, please tell your friends, tweet the link, mention me on your Facebook. The only way I know if my advice is helpful, is if I hear from you. - Thank you - ]

My head hurt. The stack of work before me could have doubled as a small skyscraper. No matter how hard I worked, I'd easily be pulling twelve hour days for the next two weeks. I had to find a way to be more efficient. I needed a way to speed things up, wipe a bunch of this work off my plate as fast as possible.

My eyes fell on the project training and adoption plan. It was the largest component of the communication plan for the project. It was a two hour, interactive training program that would ensure every single person involved in the project would be on the exact same page. I'd finally finished the slide deck. I'd just gotten the last sign off from the project stakeholders, that the training accurately covered all their needs and issues. I was now staring at the global calendar system in utter dismay. With people spread all across the globe (we have a coder in Antarctica, seriously?), it was going to take at least three weeks to roll out all the training. Then I'd have to compile all the questions into an FAQ, send that out and circle back with all the key stakeholders again. It was a nightmare, I'd be spending so much time on this, when would I manage the actual project?

Suddenly I had a triumphant idea. It was brilliant, it was easy and it was efficient! I'd cut three weeks off the planning phase in ten minutes! With glee I opened my email client. I found the email list I needed,  Division_Head_Honcho_All_Employees, I'd send the deck out to everyone with instructions to review it and send any questions they had to me. And to save time on hunting approvals down, I'd write the email so that if they didn't respond, approval was automatically assumed.

Pure GENIUS!

<SMACK!> The banana careened off my skull and into my monitor, knocking my poor flat screen over like a high tech cow tipping.

Spinning around I shouted, "HOGARTH! What the hell was that for!"

Hogarth sauntered across the room, stopping to pick up the banana, and began peeling it. He took a large bite from the end, before waving the banana in front of my nose. "Let me ask you this. Suppose you've got one of those cute little Smart cars. You know the ones just a bit bigger than a carry on suitcase, get 43 miles to the gallon."

I nod knowing anything else would potentially result in another banana to the head.

Hogarth continued, "That is one efficient car, no question about that. But if I leave the parking brake on, or let all the air out of my tires, then no amount of gas efficiency will make that car effective."

Ah yes, the Efficiency is not Effectiveness Gorilla.

Frying eggs for my next four breakfasts, all at once, might be efficient but it surely isn't effective. And I really won't be looking forward to cold, fried eggs for the next three days.

Dictionary.com defines Efficient as:

Performing or functioning in the best possible manner with the least waste of time and effort; having and using requisite knowledge, skill, and industry; competent; capable: a reliable, efficient secretary.

It defines Effective as:

Adequate to accomplish a purpose; producing the intended or expected result: effective teaching methods; effective steps toward peace.

On the surface, they seem very similar. However efficiency focuses on the "least waste of time", while effectiveness is about "producing the intended or expected result". It doesn't matter if you complete the three hour test in 30 minutes, if you only get ten percent of the questions right. You have been time efficient, but you did not get the desired result, to pass the test.

A Practical Example:

In a previous job I was responsible for managing the program to ensure a multi-hundred person team was ready for the release of a new product suite. The team had no control over what the product suite would be, but did have to make major changes to how it did business, what tools it created/used and how its people were trained, in order to be ready for this product suite release.

The program team for this project was over thirty people spread out over more than a half dozen global locations. Team members ranged from individual technical or process contributors to heads of entire teams that would have to support the new product suite. Of these team members, none was  above a senior manager role and the project sponsor was only a director. It was a challenge just to communicate with the team and the act of bringing them all into alignment and working to the same cause was daunting. At a fundamental level, the entire organization was going to have to change better than 40% of how they conducted their daily work.

Early in the project work I identified that the team was going to need proper decision making empowerment and end to end support. This required communication and buy in with well over a hundred individuals, ranging from the senior exec, of the division, down to individual subject matter experts. In an era of multi-thousand person 'corporate initiative' emails, it would have been very easy to blast out an email outlining the whole process, with a fancy hundred slide power point presentation to cover every contingency. I could have done this in less than a week and have not just those key one hundred people, but the entire division fully briefed on the project and what they had to do.

Very time efficient, and very ineffectual. Instead I spent a month focused on project initiation communication. I wrote individual emails, met one on one with people and created 'commitment contracts' from the VP on down to the SMEs. Everyone knew what their role in the project was, who they were accountable to, who was accountable to them and how communication would flow.

When the product suite finally shipped, the division was more prepared then they had been for any other release in company history. The war room set up to handle post release issues lasted only a week and was almost entirely focused on issues that cropped up from other divisions not being prepared. Quality metrics for the division, which had always gone done right after a major release , didn't just hold steady but actually improved. The division knew more about this release than any previous release. Instead of spending the first three months learning, they were ramped up from day one.

At the end of the project, four weeks of work saved countless hours, dollars and people stress. At the project start, it didn't seem to be a very efficient use of time but it was very Effective.

Being Effective:

Anoop Grover, a Silicon Valley IT project management expert, spoke at a recent PMI event on comparing Waterfall vs. Agile methodologies. At the event he said to the effect "I don't care what method you use, what I care about is the outcome. Did I get what was intended." He went on to balance this by stressing that any project must communicate clearly and often up and down the chain. At the same event, Jeff McKenna, Scrum luminary, shared a story that essentially boiled down to "Under this new model, you promise me ten features and always deliver at least nine. I also know that if you don't deliver a feature it will be feature 10. I can plan to this and know what to expect." If your senior management knows what to expect, then they have more trust, more trust makes for a much more effective organization.

When tackling an issue, ask your self what the desired outcome is. Ask yourself if the way you've been doing things is efficient or effective. Take the time to understand what your stakeholders and team want, expect and need.

You'll save time, and bottles and bottles of antacid.

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

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

The Stealth Gorilla

Or- How to enact change control under resistance.

The office was deserted. Only a few lights burned like pools of florescent haze.Using the light cast off of my monitor to see by, I typed furiously at my keyboard. My masterpiece was nearly complete. I lovingly stroked the cover of a book lying just outside the illumination cast by the monitor. "Soon, soon my precious we shall have them following process. We shall have the one true way." Sliding the book into the light, I gazed at the cover. The MoPRoK, the Management of Projects Repository of Knowledge* would make all things right. Tomorrow we would start fresh, we would wipe the slate clean and start following the plan from A to Z. Finally we would have process and all would be good!

I was about to release a maniacal cackle of glee when my thoughts were shattered by a flash of steel and the dull thunk an object striking something. Looking down I saw a shimmering metal star vibrating in the cover of my beloved MoPRoK. Spinning about in my chair I caught site of Hogarth. At least I was fairly certain it was Hogarth, I couldn't be certain with the absurd black outfit he was wearing. But it was hard to mistake those mischievous eyes peaking out from the cloth over his face.

"Hogarth, what the hell are you doing?"

Striking the most absurd pose I've ever seen on a gorilla, and that is no mean feat, Hogarth hissed "I am Neeeeenjhaa!" He made a series of moves that I could only construe to be his interpretation of martial arts moves. I must stress "interpretation" when I say this. Gorillas were not designed to be Bruce Lee.

"What on earth are you talking about?" I asked.

Sliding towards me, Hogarth began speaking. His lips were moving in rapid succession as he did so in an obvious, but poor, attempt to mimic bad comics mimicking bad martial arts movies, "I am the process that slips through the dark. I am the template that appears unbidden. I am the change that happens when no one is looking. I am, Stealth Process!"

I rolled my eyes with a groan. "You can't be serious? I am not going to don a set of black pajamas and sneak through the office."

Hogarth pulled a bright yellow banana from a hidden pocket and perched on my desk. "Oh I definitely don't recommend the black outfit, people already see you as the harbinger of creative death."

"What? Now listen here, I'm just following industry standard process. There are hundreds of thousands of MPs using the MoPRoK. There is a process and it works."

Hogarth spoke around a mouthful of fruit, "Uh huh, and if you were setting things up from scratch, then that might just work. But you're not and it won't. This team is about as open to change as Fort Knox. You're trying to change a raging river with nothing more than a kayak paddle. It ain't gonna happen."

Sigh… And once again the ever practical Hogarth spoke true words of wisdom. The Stealth Gorilla was here to show me the errors of my ways. So now we take a practical look at how to bring about change in an organization that is resistant to change for any number of reasons.

Process can be good. Process can be great. Process can be wonderful. It can create predictability, accountability, reliability. It can assure proper communication. It can help define just what is "done". It can do everything but walk the dog (well maybe it can). But no process works in a vacuum.  And when your team is highly resistant to change it won't matter what process you roll out, it will meet resistance.

You can't just wholly drop a new process into any organization. And when you have a change resistant organization, then the challenges increase ten fold.

Enter the Stealth Gorilla.

It's a fairly simple process, which ties into one of my Gorilla Project Management  maxims. "First step is to get it done, then figure out who owns it."

Several companies back I had the pleasure of interfacing with the Sales organization. I processed special exceptions to what was supported in our products. We'd originally had no process around this at all. This was good (sales always got the exceptions they asked for) and bad on many levels. Sales was never really sure if they had buy in on the exception. Support felt they got dumped with all the weird stuff and Engineering found itself fixing bugs on things they never intended to support. So we needed a process, but getting the Sales team to adopt any kind of process was akin to getting the UN to agree on the definition of Hurly Burly.

The first was to start documenting everything. The only process we had was Sales sending an email requesting (and expecting) approval of the exception. So I started there, documenting everything they asked for. Picking up the phone and calling the sales guys to ask questions and make sure all the information was captured. I went back through the backlog of old requests and updated those as well. All this was posted in a common location, so everyone knew what was out there. Now the company had a common understanding of what had been promised to customers. I kept doing this for several months, slowly refining a submission template.

Then I started sending the template back to sales with questions, "Do I have this right?" I particularly worked with the major thought leaders in sales, showing them the value of complete data by ensuring request that had all the data were fast tracked through approval. Eventually I started getting pre-filled out templates. After another few months, we flipped things around and Sales had to fill out the formal request form to even have an exception looked at. From there we slowly ramped up process on the approval side. I'd work with the sales rep to understand the business impact, we'd compare that to the cost of supporting the change and so on. Eventually, we would make it to a point of making fully qualified cost benefit analysis on the exceptions.

"But that's so much work, I don't want to work that hard."

No one ever said project management was easy. If we wanted an easy job, we would never have taken on a role that often has mountains of responsibility and a kids shovel of authority. Yes, it is hard work I will not deny that. But it is effective work and effective is what matters. In my example, we created predictability, common understanding, a formal approval process (we even started turning down many sales requests) and in the end we took the process from roughly eight to ten weeks, to, on average, twenty days. With a little investment in time and effort, we created a process that worked for everyone and made the company more effective.

If we'd just slammed down a process and mandated Sales go through it from day one, I have little doubt they would have just stopped asking and figured out a way around the system. Instead we made them a part of the process and they ended up owning the process just as much as everyone else involved.

When you run into resistance, take a page from mother nature and practice a little erosion. Work slowly and make it easy to start. Then, like a good video game, add more and more complexity until you have a complete process everyone is bought into.

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

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

*The MoPRoK is an entirely made up name intended to represent any number of "bibles" for how to do project management. There is nothing wrong with bodies of knowledge and I support them fully. It is all in how you implement them.