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 »

Somewhere along the way Agile – and Scrum in particular – decided (or forgot) the fundamental difference between incremental work and iterative work.  For some reason that is not clear to me, the two terms became synonymous antonyms where one was all good and the other all bad and at the same time could be used interchangeably.  Admittedly my recollection of this is skewed from being addicted to the scrumdevelopment group for which I am going to find a 12 step program.
But that is another Blog.
Back to Incremental and/or Iterative. First they are neither synonyms nor are they antonyms but most of all they are not interchangeable.  Incremental work is work that can reliably build upon the last deliverable or the last iteration.  It lives in charted territory.  For that reason it is fertile ground for all the neat things one can do with Lean and CMMI stuff like that.  In addition to these good ideas there are other processes, fads and gimmicks that also purport to make things better smarter cheaper faster easier and brighten your teeth while turning your hair back to the color it was before it fell out.  They may but the jury is still out and the panel may be in need of CPR in order to survive.
Now the strange thing is that iterative is all about what incremental isn’t and that is because iterative work is work that in all likelihood will be tossed out or only snippets of it will move forward.  Iterative work is the land of fail often fail fast and succeed quickly. It tries very hard not to be repetitive because the odds are you don’t have to keep on making the same mistakes over and over.  It is for that reason incremental processes like Lean and CMMI come out looking like those fads and gimmicks and this may be why some people are leading thinkers to accept that iterative is bad.
Sorry, would you mind taking that down the hall and seeing if some there wants to swap a bridge for that idea?  Iterative is the innovation engine.  In ‘the Day’ it was what we called the BIG R for research.  Of course this is back in the dark ages when R&D was valued and people actually worked using things like Scrum and Agile before it was copyrighted and marketed and certified.  Believe it or not people actually used to get paid to make lots of mistakes and hit it right once or twice in their careers.
So what did we know back then that has been lost due to modern management techniques and an economy that suffers from quarterly A.D.D?  First you iterate until you stumble across something that works and then you incrementally improve it until you totally screw it up.  If you work for a really good company someone will have been mucking about iterating on how to do it in a much better way and you will be able to latch onto it and claim you are doing best practices.
I hear something coming in from left field!  Let’s do both at the same time and that way be innovatively efficient!  Now, let’s cut this one off at the pass.  No you cannot do both at the same time because it is task shifting (a no no for you incremental lean types out there) and it is BORING if you are a dyed in the wool iterative worker.  Can you shift between the two types of work?  Sure, that makes sense as long as you work in a place that knows the difference and applies the appropriate metrics to it.  OOPS there are not many metrics in iterative work other than the Edison algorithm (success was measured in finding out how many items made lousy filaments for light bulbs and the answer was 8000 with only 1 failure when bamboo kept on going, and going, and going.)
So if you want to debate this come to the Agile conference and see if this actually makes it as a discussion.  Better yet go make great comments on it at the agile2009 site.  But until then remember that Incremental and Iterative are a fork in the road for Agilist and make sure you know where you are or you could get killed.