Stop Talking, Start Drawing! A Quick and Dirty Value Stream Example.

March 25, 2010 2 Comments

Recently I was helping a team out in a sprint planning session. All development is very waterfall (that’s a topic for another post), and it follows a very well defined, albeit inefficient, process.

We were talking about how to “streamline” the process to deliver this particular product, which was nothing more than an electronic representation of a printed document.

We talked and talked. We were “talking” about the process. I decided to draw the process we were talking about so the entire team could visualize it. It is a very quick and dirty value stream map, and can be considered incomplete, but sufficient for the needs of the team at this point in time.

Below is a re-drawing of the first stab minus the “details” 🙂

Delivery Process

I then asked the team if there were any opportunities to improve. The collective answer was “no, the process is already streamlined“.

Okay, sweet. But, I’ve never seen a process that can’t be improved. Ever. And I’m old.

Then I asked how “long” we stopped at each step in the process, i.e. how long each step took. Below is the same drawing plus the weighting.

Delivery Process With Weights

Delivery Process With Weights

Notice any thing interesting? Anything stand out? Well, I’m sure you caught it. The “unit test” box is 40 hours, while everything else is 8 or less. Hrmmm….I wonder? Could we maybe do something there?

Well, we explored it a bit, and found that how we’ve been doing things is throwing them over the wall so the consumers of the documentation can eyeball and test this stuff. Guess what they did if they found something wrong? They spent time creating a document to tell the developers what to change. Then, back around it went.

So, an option the team came up with to reduce the time spent in the unit testing “state”, was that when unit testing began, they would have the developers sit by the folks who actually tested the documents, then they would “tell” them what to change…then change it…then send it back to test. No emailing and creating painful documents describing what’s wrong. Just good old fashioned face to face conversation. The team is confident that they can significantly reduce the 40 hours of unit testing.

Will this work perfectly? No. There will be more opportunities for improvement…as always. But, you know what? We would have never explored this option of we would not have visualized the process by drawing it.

Oh, guess how long this took us? About 20 minutes. Yup…20 minutes. That’s it. How long did we talk in circles before we drew? Hrmmm…about 1/2 an hour, and it got us nowhere.

So, as soon as you start talking and talking and talking and talking and getting nowhere. Get off your butt, and start drawing.

Advertisement

Filed under Process, Teams

Scrum Needs More Than Just Chickens and Pigs

March 21, 2010 2 Comments

If you’re reading this, I assume you already know the “chicken and pig” roles in Scrum.  If not, go here to check it out.

Okay, pigs have “skin in the game”, and chickens…well…don’t. Since some people hate the chicken and pig metaphor, I’ve also referred to it is “committed” (pigs) and “interested” (chickens) (I didn’t come up with this, but I don’t remember who did).

The chickens are not allowed to talk in the daily Scrum meetings. They are only allowed to provide feedback in the Sprint Review (and of course at any time to the Product Owner, Scrum Master, or as requested by the Team).

I think there are two kinds of chickens. There is the kind that provide no valuable input. They historically have done nothing other than cause distractions. Whatever it is your building may have an indirect impact on their lives at best. These people are typically in some kind of management, or senior role.

The second kind of chicken are those folks we typically refer to as “SMEs” (Subject Matter Experts). We may or may not be building a solution for them. However, we rely on their expertise to enable us to deliver value. These kinds of chickens are usually are involved in legacy application development or re-platforming efforts. You probably won’t experience this group if you are doing new development. These types of chickens are needed when the Scrum team just does not have enough of the institutional knowledge needed to consistently deliver value.

Both of these types of chickens have one thing in common. They do not have “skin in the game”. If the project fails or succeeds, there typically will be little (or no) consequence for them. What they do NOT have in common is this; the involvement (or lack thereof) of the second kind of chicken can either bring a team to success, or to a miserable failure.

Teams will typically lump both types of chickens together and treat them the same way. It’s really insulting if you think about it. If I was *critical* to the success of a project but am labeled a “chicken”, and if I identify a risk, I shouldn’t have to wait to speak until spoken to (which is implied with chickens), or until the Sprint Review.

What do we call this third group? They really aren’t chickens as defined in the Scrum context. However, they aren’t pigs either since they aren’t the Product Owner, Scrum Master, or Team (those who do the actual work). We will fail without them.

Filed under Process, Roles, Scrum, Teams Tagged with ,

Face It, Your Memory Stinks

March 14, 2010 1 Comment

Seriously, it really does. You can’t remember everything. No matter how good you are at “Simon“, your memory just isn’t good enough.

Okay, so I’m stating the obvious. If we all know we can’t remember everything, why is it then that in soooo many meetings, nobody writes down what was decided, discovered, or uncovered? Sure, there are some folks that are writing “something” down during meetings. But, those are typically their own personal notes, the stuff that applies to THEM and not the team-at-large. They could be doodles, or possibly an attempt to look like they are attentive to what’s going on, when in fact, they are actually zoned out (I’m guilty of that). Who’s recording the important knowledge for the benefit of the team and organization?

I was observing a planning session a while ago. The team asked a business SME to come in and answer some questions regarding complex business scenarios. It was a rich, active discussion. People were learning new things left an right. It was beautiful. This dialogue lasted about 20 minutes or so. Guess how many people wrote this incredibly critical information down? NONE. That’s right, not one person wrote anything down. Sadly, I’m starting to realize that this is a common occurrence.

This is why we have the same meetings over and over again. How many times have you been in a meeting and you think, “Huh? We’re having this meeting AGAIN!?!?”. There is a very simple solution. WRITE IT DOWN, send it out, and store that precious information in a central location that’s easy to get to (can you say “wiki”?).

Whose responsibility is it to make sure something is documented during these meetings? It’s everyone’s, including yours. If you see that information is just disappearing into thin air, don’t hesitate…ask “okay, so who wants to take notes?” If you get no volunteers, then announce that you will do it…and then take care of it.

Filed under Process, Roles, Teams

When Should Waterfall be Used Instead of Agile?

March 9, 2010 1 Comment

I just read a thread on the Scrum Development yahoo user group about when it would be appropriate to use agile and when waterfall would be better.

This brought to mind all the conversations I’ve had over the years regarding “when to use agile”. There are many folks in organizations that believe that waterfall is best suited for some projects.

So, I’ve been searching for those “types” of projects.

Now, let’s be clear. I am using the term “waterfall” in the strictest sense which means that:

  • Requirements have to be complete and signed off before technical design begins.
  • Technical design has to be complete before development begins.
  • All coding has to be complete for testing begins.

If we “kind of” follow this, then it is chaos.  The question we have to ask is … is it even possible to meet the strict requirements of waterfall?  My answer is NO for software projects, or any projects with a large amount of unknowns or required creativity and flexibility.

Can you ever successfully elicit and document a complete set of requirements at the most granular level?  This is what waterfall requires after all. If there is even a remote chance that a) the customer isn’t sure what they want, b) the customer may change their mind on what they want, or c) there is even a small amount of complexity, then it is very, very high risk and just not very smart to use waterfall. You just can’t…stop kidding yourself.

So, is there ever a reason why you would want to use waterfall? Sure! Here they are:

  • The culture is not ready to work cross-functionally.
    • Any agile methodology requires a cross-functional team. If the culture cannot sustain cross-functional work then you are forced into communication by documentation. Yeah, good luck with that. You should think about coming up with a strategy to make people hunger for cross-functional collaboration.
    • Not everyone “wants” to work in a cross-functional team environment. They need to either be coached up or coached out.
  • Management makes you use waterfall.
  • You can confidently define everything up front, there is little or no chance there will be changes, and there are no unknowns.

Let’s not pretend anymore that waterfall is actually appropriate for any complex software project with humans working on it.  With complexity come unknowns, and with unknowns, the amount of bureaucracy necessary to handle “change management” is ludicrous.  I have yet to experience any software development project that did not have at least some kind of complexity.  If you say “agile doesn’t work for all software projects”, then you have a misunderstanding of what agile truly is.

Filed under Agile Tagged with ,