“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 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.

Here is what I measure.

As a Trainer I measure my coaching ability by the answering these questions.

1. Are the DOERS (developers, architects, testers, leads) taking responsibility for what they do and do not do and are they extending that expectation to those groups they work with?
2. Is there a simple measure of DONE and NOT DONE and is it constantly being inspected, refined and adapted to better meet the goals of the organization?
3. Do Product Owners, Stakeholders, business types increasingly take ownership of the value decisions?
4. Do the process junkies and the PowerPoint wizards become engeaged in a way that increases the ability of the organization to deliver value early?
5. Do Agile practices expand so that people in Operations, Support, Help Desks, Maintenance have a scrum where their work is on a Taskboard and all their work is recognized for the value it provides?

As a Coach I measure my training skills by answering these questions.

1. Do the team members and the stakeholders understand the terms and the actions that go along with them?
2. Do they look for ways to exploit understanding of Agile in the organization by adapting and inspecting what they do?
3. Does the stakeholder community increase its attendance at reviews, scrums, to listen and transparently evaluate what is being done?
4. Do the people in the different roles respect their work, look for ways to improve and most of all encourage and mind each other?
5. Am I as a Coach/Trainer moved to the rear of the conversation Does the team talk to each other and not to the ScrumMaster?
6. Is the Product Owner called on to do their job?

SO If I have one metric that says I have been ’successful’ it is simply that no matter how hard the traditionalist try to stamp out Agile behavior, Scrums become a way of life.  Is that Scrum Butt -yeah – so what.

In the end, the only Butt in question is the traditionalist mind that won’t change.

oh yeah, check your zipper.

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?

Perhaps it has something to do with what architects hear us say and what they take away with them.  I recently read a great blog Lean & Agile: Are they worth the effort? and made these comments.

It is startling to read such a well read and concise synopsis of what many of my colleagues in the Agile community get wrong in communicating what Agile is.
First Agile is more than just delivering the most valuable parts of what the customer wants.  The bit missing is the important one. – it works as near to perfectly as the team can make it.  Why do I harp (some say nag) on this.  Well, if the most valuable item the product owner has cannot be delivered, say for example a startrek replicator machine capable of making $1,000.00 bills in endless supply.  Then we cannot deliver it.  Sorry, not going to happen.  What else do you want?
So what is Agile, it is a way to deliver the most viable value at any given time and in saying this we begin talking about iterative development where we allow for the rapid delivery of emerging solutions.  You know the ones that are not quite right each time the product people look at them – the ones needing ‘one more thing’.  Agile is great because it delivers what was wanted in a short period of time and then ‘adapts and inspects’ to create the next version of “AH HA’s” the product people come up with.  Great stuff.
Agile also does incremental well.  That is the one that you do when the product is nailed down and you know what the end looks like for the most part.  now we can deeply dive in to what and how we repeatedly create the same product or process.

This does sound like lean but as you so quickly caught on, lean as in manfacturing is not what we do in software.  We do not build the same exact source code and ship it over and over again.  We have that bit down in release.  What the Leanies are talking about is ‘lean principles’ which IMO are basic good engineering practices that aided the allies in winning world war II.  Check out TWI and see what I am talking about.  TWI or Job Instruction Trainng is how to teach unskilled people processes that will permit them to produce highly technical product in a very short time.  If more of the Leanies had time in manufacturing line management they would know this. but that trade and proffession, like phrenology, is a thing of the past.

So what does Agile need to adapt and inspect on?

First and foremost we have not allowed architecture to emerge as a valued member of the Agile team.  There are probably a host of really good rationales for this and I am pretty certain that a therapist would have a field day with all the angst, anger, and other inhibiting behaviors that fostered this feeling and continue to fuel the issues.  Folks it is time to get pragmatic and move on.

There is one reason that I have found that makes this impossible and that is the how today’s Agile Architect defines themselves through their work patterns with each other and with Agile teams.

Agile is a team sport and we treat architects in general and Agile Architects in particular as individual contributors that sit on the periphery of the Agile Team.  Shame on us for being that conventional in our thinking.  Shame on Agile architects for not moving hard enough to show the lack of relevance that attitude has when integrating Agile into large projects and programs.  that word is something we need to use around architecture for a couple of good reasons.  The most important is that it really works well when it is done and it also really changes Agile biases because it rocks the boat into hyper gear.

When you look at the average Support, Maintenance, Architecture, Help Desk, Ops, and DBA groups, you find people that have been in place for years.  When these teams get rocking the same curve shows up but then – around the 20th iteration things start to hit hyper cool drive.  Overtime, weekend and other ‘catch up’ time wasters shrink or are planned weeks ahead of time.  The KanBan board is totally self managed,  Things go up get pulled forward and finished.  New people integrate easily and more and more peer initiated cross training occurs.

Most interesting is that costs go down as Lean principles really have a chance to mature in place and become woven into the fabiric of the organization.

The most frustrating part of QA and test for me is investing huge amounts of time and care into assuring the quality of some item that has no value. I say this not as a QA manager, or Test Manager (I have been both) but as a Developer, Engineer and stockholder. After all the core specification for anything Agile is Value. In Theory of Constraints terms, Agile QA is about what Glodratt’s calls the inspection of parts before working and ensuring it is to specification otherwise you are wasting people’s skills on refining trash.

Today, what are we doing to assure we are working on the most viable item of value we can produce? From where I sit, we seem to think that magically all things we touch must have value otherwise they could not exist in our world. What a load of hooey. Bottom line, if you are working on something that contributes nothing to the value of the product then you are wasting your own time, your company’s resources, and your customer’s faith in your product.

Let’s look at the role of QA can play within the context of the Agile Manifesto and Principles.

1. We need confidence that what we are doing has value and that we can trace that value directly to the Product Vision and the Organization’s goals.
2. We need to make sure that we do as little work as possible to produce the value in the product. This is not saying that we do a slacker’s best. To the contrary it is saying we only work on those things we have a dead certainty as to what it is we need to produce in order to have it accepted as DONE.
3. It means that we have a way to delay to the last reasonable moment those parts of the product that we are not dead certain of.
4. It means that we have a way to identify what the value is before the part enters our plans.
5. Finally it means that we have an early decision and definition of what value the part brings to making the vision a reality.

The role of QA in Agile then is to be the Product Owner’s trusted advisor on assuring the Value of the Product moves in continuity from the vision to the customer’s compliments.

So what is to happen to test? If QA has a new role in Agile, Test has a new life. If the developers are aware of what the product is supposed to do then, in small projects/products test is already a teacher and shows developers how to develop tests that automate well; it is also a mentor to the ScrumMaster and the product owner giving them confidence on the coverage of the product. Now test has the chance to assist the Product Owner in judging the doneness of a delivery. If this in place when larger projects ramp up, Test actually gets to do its job.

As the product, project, scales teams deliver acceptable components along with the automated acceptance tests used to assure the component is DONE. These become part of the regression sanity smoke tests and free up the scarce test professionals to exercise and explore the interfaces and operating parameters of the product.

Can Test now move to iterations, scrums, and fast delivery? Interesting question and the early results are encouraging. More later.

Today, those few nuggets of value have been tweaked, twittered, extrapolated and inflated to the point that almost any tool, software add on, metric that can be conjured is associated to all of the following slides.

• Agile Priniciples
• Agile Manifesto
• Jim Johnson’s 2002 xp presentation
• Anyone of a number of Scrum graphics
• Scott Amblers data

And presto we have a new something or other.

I go back to Jim Highsmith’s comment regarding that there is more written about Agile than is known.

Right On Dude!

I guess that makes the people I work with on the outside, Everything we talk about is based on what we have experienced leading, coaching, and training. We know it works and we know how many errors we made finding this out.

AH, INSIGHT!

Perhaps there is a way to find out how much of the PowerPoint has Power by asking the presenter, how many mistakes it took to stumble across the gem they are offering. Hmm let’s see,  I can read about Mike Cohn’s stumbling into planning poker and points, just like I can listen to Ken Schwaber tell me about all the things he has done that did not work. If you want a good laugh, ask Jeff Sutherland or Ron Jeffries what surprises they have had. Dave Anderson still moans about all the things he would change in his book that he knows are wrong. Sanjiv Augustine too. I could go on and on with the people I know who have told me, written about it, but then I know I would forget someone like Jean Tabaka or Hubert Smits and I wouldn’t want to do that. SO all I can do is tell you what I remember.  Now wouldn’t it be nice if we had some record of all of our screw-ups?

Me? Hey…My most recent learnings are about how QA and Architecture teams impact large projects.  Most important finding is understanding how to get them acting like teams and not support staff.  Second most important finding is getting the rest of the teams to see their value early.  The mistake that led me to these learnings was assuming that Architects, QA and their management wanted them to act like teams after they said they did.  Key lesson learned.  Count the number of steps taken, not the words spoken.  Then again this may be why the straw really broke.

So where is the beef in all these presentations? Maybe we ought start asking.

This post is an excerpt from an on-going conversation at http://tech.groups.yahoo.com/group/agileleadership.

I have been asking for comments and perspectives about leadership, traditional management, Agile Leadership and so on.  The thread is well received and i wanted to bring this element to this community as it begins to address places where all sides seem to converge.

Glen Alleman wrote:

I’ve started speaking of non-agile project management is bad (or poor) project management, since responding to the emerging situation is part of good project management – as defined in PMBOK. Therefore not responding is bad. I’ve started using “conventional” to distinguish the processes used in many locations to great success. Agile and Conventional are certainly different. Non-agile is non-functional and therefore a nonstarter for success.

Ron Jeffries responded:

Would that more people believed that.

From my perspective;

I think Agilists differ from conventionalists in that they put Respect and Leadership over Rank and Management, and make this distinction transparent.

Perhaps one of the key attributes of an Agile Leadership environment is the passing of the leadership position to the person the team trusts most to address the issue. This fluidity, seen in ‘self organization’, pair programming, and most dynamically in planning sessions seems to become the bonding agent of the team.

Now does this translate into organizations. I think the answer is yes, but the result is a new management process that goes to the top of the management and stakeholder organization. We have mentioned “Corps Business” and some of us have delved into OODA, the three block war, and I have seen some organizations make steps toward this.

What I think I am seeing is the trust component of leadership and followership extend into the management of the organization and manifest itself in Management retain Control of the plan and teams of people at the lowest level in the organization take over Command of the situation. The Middle part of the organization exists to serve both those above and those below by clearly defining, the mission statement and the commander’s intent; advising those above on the capabilities and limitations in meeting those statements and intents and removing the impediments facing the teams as well as shepherding the solutions to the needs and requests of the team as they encounter unpredicted, emergent challenges.