February 4, 2012

BigVisible Blog

The ScrumMaster ’3 step’ Dance.

The other day, someone asked.  “So how do I do this servant leader role ? How do I develop self-organized teams,  not use command and control, and still have the capability to meet organizational expectations?” It’s not the first time, in fact it may be the most persistent question asked over the past ten years.  I don’t have a silver bullet answer, but I can share with you what I found worked for me and I share with the people who come to my classes.  I call it the ScrumMaster ’3 Step’ Dance.  It’s not hard to do, the difficulty is in finding a rhythm that suits you.

Step 1. Lead from the front using the leader part of servant leader. Use this when the team is lost, going off the rails or about to run back into the burning barn of traditional project management.  As soon as the team gets their bearings, starts being honest with themselves, or chooses not to get burned again, move immediately one step back and to the side.

Step 2. Coach from the side. Be there on the sideline giving support, offering suggestions and providing guidance. Shift to Socratic method.  Once the team gets their confidence back, take another step back, moving behind the team.

Step 3.  Mentor from the rear.  look for patterns, learn how the team(s) are moving ahead through their challenges so you can lead them when they ask for help.  Remember you are now a firemen always ready to go when the team rings the bell.  When you get to the fire you’ll know which steps to take.

Scrum Purists, Posers, and Pragmatists

Scrumsters in the Scrum community are breaking into three major groups. Which camp are you in?

Purists are all about what Ken said 10+ years ago. They represent the once radical movement that launched Scrum. Problem is that even Ken doesn’t practice what he advocated in “the day”. Take a look at this list of early terminology.

[Read more...]

Why a ScrumMaster is like a Quarterback

The other night as I was taking my evening break from the Agile World, I was confronted by 2 aliens who were very upset with our regard for sports in general, the Human Race overall, and for some reason me in particular.  In fact they were so irritated they didn’t try to put a probe in me.  I was crushed.
[Read more...]

Sending your code to the Car Wash

I really like hanging out with Test folks. Their clarity and willingness to face what is happening is refreshing, invigorating and also a complete downer.
Sunday at Agile 2010 was the aa-ftt workshop and some of the most important thought leaders you don’t know were going at hammer and tong.
A couple of hours into “Al” (an Alias because I can’t get a hold of him to ask permission to quote) said “Developers treat test as the car wash, they drive their code up and expect us to clean off the bugs on the windscreen”. My mind went into hyper drive and the great comedy “Car Wash” would not leave me alone.

“Al” was right on the money.  In a traditional or even many agile-lite environments stories are planned, tasks created and – at the very end of the sprint (if you are lucky) the test task is there.  Yup.  Here comes the latest in cool code.

It is like you build a car got it ready to roll and took it to the car wash.  When it comes out the other end you are really upset because it is full of water, soap, and all the pizza bones, old soda bottles, and that missing fooz ball are floating around in the  passenger compartment.  Jeez those clowns at the car wash should have been more careful.  Didn’t they see the windows were mocks, the roof was a shell, I mean all that was need was to clean the three little bugs off the windscreen and fine tune the horn.

In a more mature agile shop there would have been an acceptance requirement that the code had to be able to go through the car wash.  But even that level of sophistication will fail because it lacks the clarity of why it has to go through and most of all what it should look like after it is done.  three fourths of this car came out the other end, the wheels, rims, and interior were lost, and the team was incensed they could get the credit for the work that past. – all because the clowns at the car wash won’t take a broader view of the acceptance criteria – I mean come on dude, Most of it got through.

Then there is the business attitude toward the car wash employees.  The dudes with the rags get labeled surly, arrogant, and picky as the dickens when it comes to NOT doing somethings.  Business wants a good job for as little as they can pay for.  Look is it too much to ask for a clean car, vacuumed mats, windows that shine, as well as the removal of the unknown projectiles lodged in the mini-grill of the sub woofers stored in the trunk?  No I am not going to pay all that money for a detailing job so the car looks as good as new.  I just want to have it look that way for no additional cost.  And while you are at it, balance the engine, tune the suspension, lube it and put in the best oil and filter you can.

So thanks big Al.  We are all going to start moving to the tune.

There is more to Done than we know about.

Since the Agile Community is looking to manufacturing for so much wisdom these days, let’s look at what Done means when spoken by a manufacturing professional.  First there is Done at a workcenter, meaning what I built there meets a predefined acceptance criteria that apply to one some or all of the parts made there.  In manufacturing, no part can be consider part of WIP unless it has met the acceptance criteria of the last workcenter it passed through. This is because manufacturing has a couple more definitions of Done that are more comparable to what we think of. Done can also refer to one of two very carefully specific definitions of done, both of benefit the on-line computer shoppers of the world.

First there is MEI which means Manufacturing End Item and represents all the components needed to make the final assembly of what you the customer order. Second there is the CEI or customer end item which is what you buy. These two terms are core to the shopping on the web. When you select the stuff you want on your, iPhones,  personalized bathrooms, or your next auto all work because of MEI and CEI.  The choices you have for building your computer, like disks, and memory, different optical drives not to mention the skins you can wrap them in all reflect MEI’s or Manufacturing End Items. They can be combined because of an extensive Quality integration effort that assures all the bits do fit and will work properly. When they are stuck together they fill your order which defines DONE for your Customer End Item or CEI. So having multiple definitions of DONE can actually add value, as long as you pay attention to the quality needed to integrate all the parts at the end.

Don’t worry, manufacturing has kept up with the times as more and more manufacturing has taken to Modular Manufacturing. In fact in this global economy entire manufacturing systems are designed to be modular so that not only the parts are broken into smaller and smaller levels of DONE but so are the manufacturing steps. For those interested see “A hybrid methodology for synthesis of Petri net models for manufacturing systems”(http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=143353). So in a very real sense the high tech geek world we live in is about three generations behind the guys on the factory floor because most of what they are doing to determine discrete points of Done is to base it on measurable value Pretty cool huh?  Oh yeah they have been using some form of a task board and dependent demand planning  in a pull mode (AKA Kanban) for about 500 years.

Now to make this happen each step has its own QA, QC and Test criteria, patterns and harnesses. This means that if someone down stream figures a way to get folks to want people a choice in the type of metal used in their iPhone 8 antenna, the manufacturing step that makes the antenna will be ready to provision the web page where people choose the metal for the antenna – and the time to market will be the speed at which you can key in the changes to the web page.

So how close are we – software – are becoming the choke point in this whole innovation stream? We could be, if we insist on  sticking with what we are comfortable and wait to the end of the cycle to get the work tested and then have problems logged; wait until the next meeting to get needed changes through some form of CCB; wait for an optimally utilized Product Owner to have time to approve the work, and then have to wait in line while an understaffed and over committed QA group hand crafts test cases 12 timezones away to start this cycle all over again.

If however we develop defined criteria for each step of the process and, like the modular manufacturing world, base our breakdown on what is valuable to the ‘on-line’ shopper mindset.  Who knows what could happen?  Perhaps discussion that don’t get into what done is.

Scrum is a Silver WHAT and you want to put it WHERE?

I really enjoy leading public CSM classes. The intensity and focus the participants bring is a blast of pure, cool, oxygen that invigorates me.

For example, the most recent class was very intense with the team asking me some really hard and crucial questions.  Then they dropped the bomb. “Hey Mike, you act like Scrum is a Silver Bullet.” Arghhh! I HATE THAT. I don’t know how many times people get that impression and how many times I have repeated the litany, “Scrum doesn’t solve anything it shows you what is happening in your organization”.  Well not this time. What jumped from my lips was “Scrum is Not a silver bullet, Scrum is a silver mirror!”.

The next day, one of the class members reported out that my ‘catch phrase’ had really worked.

Huh? The class was right behind me in asking for an explanation.

It seems he left the class last night and went back to work (we are such a bunch of OCD wonks) where is boss was talking about Scrum not being the Silver bullet he, the boss, had expected. Our teammate then popped the phrase “Scrum is Not a silver bullet, it is a silver mirror!”. This stopped the boss in his tracks as he realized that Scrum was just that, a high definition reflection of all the things that were actually going on. And if memory serves the attendee went on to say the conversation went from Scrum not meeting expectations to what was coming off the mirror.

The class, being a great one, started kicking this around. One of the comments emerged from someone saying “Talk to the hand” and became “talk to the silver mirror in my hand”.

Maybe a good ScrumMaster is a person who can have people talk to the mirror in their hand.

Focus Stories – Is Your Story Big Enough for the work you are doing?

Odd Question, isn’t it.  We spend all this time focusing on getting the story to be the right size, chiseling away on the ones that are too big to fit in a release, and so on.  Then we turn around and fight the good fight when Scrum and Agile scales up and we are faced with keeping multiple teams working in peace, harmony and synchronicity.  It is this last problem that I keep on dealing with, particularly when trying to introduce Agile QA.  I got so frustrated that I took Jim Highsmith’s advice about “more being written about Agile than is known”, stopped reading Agile and read other things – like the Harry Potter series and 20th century history.  It is here I re-read the words that on May 25, 1961, changed a generation’s life. President John F. Kennedy said in his, “Special Message to the Congress on Urgent National Needs,” before a joint session of Congress.

I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth.”

It struck me it was ‘the’ perfect story. It has a role, action that had to be taken, and a goal.  But most of all it had a very tangible, clear, and explicitly well defined definition of DONE – “returning him safely to the earth.” What a story!  What an Epic! What a way to get a nation – a world – to focus.   But it wasn’t a user story – it had this timeboxing clause,”before this decade is out,” that started the clock ticking.

I refer to it as a Focus Story. It serves as the transforming agent changing a poetic visiony user story into a ‘Mission Statement” and a Commander’s Intent”. With it in place, at the top of Product Vision, enough guide rails are in place to make reasonable initial roadmaps, release plans, prioritization criteria, and definitions of done.  But most of all we have a means to understand core values criteria “safely to the earth”.

We also have triggers to inform us when we are losing focus –  Meetings get longer, Done isn’t understood. Pieces don’t fit and the conventional mindset you have been struggling to win over sighs and goes back to its safe place of waiting for the fad to die.  When these show up it is time to revisit the focus story and build a bigger focus or wrap up what you are doing.  Otherwise you risk having “O”rings show up on your Columbia launch.  Nobody wants to be part of that type of bad day.