Month: October 2015

BOOK REVIEW- Scrum: The Art of Doing Twice the Work in Half the Time

Scrum-Art of Doing HalfDAN’S SCORE: Stars 5.2
Scrum: The Art of Doing Twice the Work in Half the Time
by Jeff Sutherland

This book was recommended to the graduating CSM class of April 2015 by Jim Smith, our instructor. I went out and immediately picked up an audio copy so I could listen to it during my long car rides. I am so glad I did. This book is top notch and has made the rounds with the scrum masters in my company.

Sutherland is the creator of scrum and an original signer of the Agile Manifesto (we’re not worthy!). One thing I really like about this book is that Sutherland is a great story teller. The book is full of stories such as the FBI’s Sentinel Project, the master aviation strategist John Boyd, and Sutherland’s own experiences as a fighter pilot in Vietnam. He weaves these stories into how the concepts of scrum was created as well as the best practices for Scrum and being Agile in general.

This man gave you Scrum. Know the face!

This man gave you Scrum. Know the face!

The book has a ton of stuff: the scrum framework, roles, best practices (for teams and business), and the psychology of people to name a few. A couple of my favorite sections was his counsel on the pitfalls of multi-tasking and working people overtime and the importance of finding joy in your work to maximize success. Its all good stuff! Go pick it up!

Sutherland has become my go-to guy for learning the scrum framework. I often take a look at his videos to better understand concepts. I’m certain this won’t be my last post on him.


T-Shaped People

Traditionally, companies hire two different types of people.

First, there is the hyphen-shaped person:


Hyphen-shaped knows about lot of things. For example, this hyphen knows Agile, Medical, QA, Coding, and Servers.


Because he knows about a lot of different things, he can converse freely about these topics with others. He might even be able to do some basic work in these areas.


But Hyphen’s understanding of these topics are not very deep, just like him.


If he needs to do something that requires a lot of skill, he’s in trouble!

The other type of person companies hire are I-shaped people.


Notice how deep he is in his field!


His depth of expertise allows him to perform work that requires a lot of skill.


But when dealing with other employees outside his area of expertise, he is confused and frustrated. He can’t speak their language and doesn’t understand their point of view. It’s so different than his own.


In Agile, we value what’s called a T-shaped person.


T-shaped is highly skilled in his area of expertise so is a value to the company.


But he has a breadth of knowledge in other fields so can converse with others. He understands their point of view even if he doesn’t have their depth of knowledge.


Imagine a company full of T-shaped people. Collaboration, communication, trust, and respect would thrive as much is accomplished.


But what about us who aren’t T-shaped? Is there any place for us?


Just because you are I-shaped or hyphen-shaped, doesn’t mean you have to stay that way. It’s time to get out there and learn about your colleague’s fields. Talk to other employees from other departments. Study their area of expertise. Learn all you can!


Before you know it, you will find yourself becoming T-shaped!

Single Piece Flow

Single Piece Flow is something I wish someone would have told me about when I first started scrum. For me, this is at the heart of the agile mentality. When I first learned it, it kept me up all night thinking about it.

Single Piece Flow is part of the Toyota Production System (TPS), which is where we get Lean. And Lean is Agile’s daddy. Best to know your roots!.

Single Piece Flow is a manufacturing concept. Traditionally, in manufacturing, companies produce items in what’s called a batch-queue. In the example below, we have a monitor producing company. First, the upper part of the monitor is created. In this example, they produce 10 in a batch. When the upper part sections are completed, the batch goes to the next department and the base of the monitor is added. When the bases are completed in that batch, the now assembled monitors go to QA and are tested in another batch.

Single Piece Flow2

Lets pretend that it takes each department 1 hour to finish each batch. So, for the first department, it will take 10 hours to complete all 10 monitors. The second department will take another 10. QA will take another 10. So, to complete all monitors from assembly to QA, it will take 30 hours to complete. The easiest way to do this is just count each monitor or QA going left to right in each row.

Follow me so far?

So, lets ask ourselves a few questions (just count left to right on each row to get the answer).

Questions 1

Lets throw in a hypothetical. Let’s say the first department created a defect in one of the monitors (indicated with the X through the screen).

Single Piece Flow defect

Now lets ask a couple of more questions.

Questions 2

That’s the traditional batch-queue mentality. Now, lets look at Single Piece Flow. Single Piece Flow approaches completing one item at a time. In other words, the first department makes one top portion of the monitor, the second makes the bottom, then QA tests it. Boom. One monitor done. Lets now ask ourselves the same questions again. NOTE: in Single Piece Flow, once a department finishes its portion of the monitor, it goes right to the next monitor. So, when the second department is attaching the base of the first monitor, the first department is already working on the next monitor. Kapish?

Here’s the chart again to help you out. (hint, count by columns instead of by rows).

Single Piece Flow defect

Questions 3

Pretty incredible isn’t it?

For me, single-piece flow demonstrates the power of agile. Its focused, its flexible, its faster, and it decreases waste.

Now imagine if instead of hours we were using days? Weeks? And all that time equates into dollars. Amazing. Be sure to pass this around. It could rock some exec’s world.


Smorgasborg Scrum

buffets_640Ah, delicious scrum! Just hearing how scrum will get the company twice the work done in half the time is enough to get the most malnourished exec salivating.

And there is so much to choose from! Hustle up me a plate of Daily Stand ups! Throw me in some of that release planning and retrospectives! That’s good eatin!

That velocity stuff?–eh, that’s weird. I’ll pass on that. Same with those Velocity Charts. Yuck.

And so it goes. The company piles it up high. Before you know it, they got themselves a nice place of scrum.

And then they get themselves a nice case of scrum indigestion.

See, in Scrum, you just can’t pick and chose items like a buffet. It doesn’t work that way. I can understand the mentality. There are still plenty of things in scrum that don’t make much sense to me (Cumulative Flow chart? Forget it!). Our tendency is to just ignore it or just hope it sorts itself out in the wash.

The problem is, going buffet style with your scrum initiative is only going to frustrate your attempts to implement it.

The folks who came up with the scrum framework were purty smart people. The framework is well balanced and are interdependent on each other.

Let me give you a real life example.

Yep, that's Fibonacci of the Fibonacci point fame. Funny hate, huh?

Yep, that’s Fibonacci of the Fibonacci point fame. He has a funny hat. Actually, I’m not even sure that’s a hat. What is that? Good Lord. Is that a dew rag?!?

I had a company who insisted we have Fibonacci points for all our user stories (and well they should!). However, not much attention was paid to velocity charts (“What? Its not consistent? Oh well. Better luck next time.”). Additionally, our sprints could fluctuate anywhere between 1 to 2 to 3 to 5 weeks long! Talk about scrum indigestion! We had plenty of it. No wonder the execs thought this scrum/agile business wasn’t all it was cracked up to be.

The architects of scrum didn’t come up with the scrum framework for kicks and giggles. The different parts are meant to work in tandem with each other. If you don’t let them do it, all you have is just a big mess.

Dan’s tip: Have some faith in the entire scrum framework! Sure, at first it might not make a whole heck of a lot of sense, but as you do it (correctly!), you will start having those “aha” moments and come to realize those people who came up with scrum must have known what they were doing after all.