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.

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 20^th 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.

I posted this several years ago but can’t seem to access the original blog. So here is a re posting.

I have been meaning to share this for a while.

Holding team meetings where the team members are not in the same place is not fun, and it becomes less fun the more distributed the team becomes. The following rules of thumb came about when I had to run teams of consultants where no one was in the same place and the places they were ranged from their office to their home or car, or airport lounge, or even their bed when they were in on the other side of the world.
The first thing we noticed is that a little more structure and role definition was required so that people could better self herd themselves

Roles
a. ScrumMaster run the scrum, keep time. Must have good phone that does not add noise to the line

b. Scribe take down key points (usually this person was the one in the office or someplace where there was a horizontal writing space and enough quiet to concentrate)

c. TeamMember person who kept their phone on mute unless given the ‘stick to talk’

The second difference is the structure needed a protocol to insure everyone could participate. This led to the following team driven agreements on the Scrum. The most important of which is the timebox with a Max time of 15 minutes to complete the following:

Rules

1. No speaker phones. These are great for everyone sitting together but terrible to listen to.
2. All actions are time boxed
3. First activity is for each team member to answer the questions three with no interruptions (15 secs max per task)
4. Team members keep their questions, comments, and what-have-you on stickies
5. ScrumMaster reports out all actions on blocks, and any new information
6. At the end of the questions 3 the ScrumMaster polls each person for any questions Team members tear up any duplicate stickies
7. Open Microphone – general discussion on each thread – 1 minute max for each comment
8. Synch questions – questions designed to clarify any stray points – 30 sec
9. Take aways and off line – people who want to dive on a point set up a time to set it up and do it, no calendar trolling allowed on line.
10. Scribe time – scribe gets to set the noodles in a row and send out email
11. ScrumMaster Sums up. Sum up includes acknowledging blocks, key linkups, and next meeting time.
12. ScrumMaster asks “What did I miss?” and team memebers fill in holes and then concurs with summary.
13. ScrumMaster then announces “SCRUM Over, Open Microphone for as long as people want it.”

Things to improve this

Team writes up their questions three and sends to Scribe before meeting. Scribe then cuts and pastes into a single email and sends to team during meeting. Teammember still reports them on line.

Many thanks to the people who attended this presentation. Their comments and observations were very good and helpful. Getting this type of feedback is great!. You can download a copy from this location.  The impact of Agile Architect Teams in Scaling Enterprise Efforts

There is a lot going around about success in Scrum these days.  Talks on ScrumButt,(or ScrumBut); long threads about how long it takes; presentations on what is involved.  Yet I wonder how these folks can talk this way.  In my humble opinion to declare that you are successful at being Agile or doing Scrum is to admit that you don’t grasp the essence of Agility.
Maybe I am wrong, after all I put my pants on just like everyone else and just like them I periodically forget to zip up.  Could be one of us has that problem.
So to be transparent, What I have been teaching, coaching, leading, and doing the past 10 years is getting people to stop thinking about this as a goal to attain and to start accepting that it is a way of getting things done, better each time.
Is this a copout in that I never have to say my teams FAILED?  Nope.  It means that if you did good today, you were better than you were yesterday and now you have to do something else to be successful tomorrow. Lots of days you don’t get there but you do learn what doesn’t work. So if I understand the ScrumButters’ metrics, most of what I do is fail, but then again I have tomorrow to change things and get better than I was.

Here is what I measure. more »

You shouldn’t be surprised by this.  Agile is in need of Architecture but you have to seriously question how we are going about adapting and inspecting the role of the Agile Architect in meeting that need.  Funny thing is that it may be due to the fact that mainstream Agile thinking is wrapped around Agile as a small team of hardy souls bringing joy to the masses and angst to ‘the man’.

When you live where we do, working with huge organizations spending enormous sums of money so that hundreds and even thousands of people can build, support, train, maintain, and even (gasp) plan how to handle the information needs of millions of people as they; trade at a local, regional, national, and international level concurrently; seek, provide, research, pay for healthcare;  protect/defend their person, family, home, community, nation, world from threats of others or their own environmental actions; and even download upload whatever they find entertaining in this world; when you live on this side of hill, architecture is at the core of being Agile.  And for the most part, we suck at making it great.  Why is that? more »

As an Agilist, I have watched Agile move from small teams of developers to larger and more encompassing activities in the organization the following fact began to emerge.  Agile is not for development, not ‘real’ Agile that is. Most of the projects I have seen are over in 6 to 8 months or between 12 and 16 iterations.  Most teams don’t start to to really hit their stride until around the 6th to 8th iteration.  The team members trust themselves and each other, the IDE they are using is smooth, CI is usually in place and the team is pretty self sufficient.  ScrumMasters are sitting around looking for work and the PO is moving along. more »