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.

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.

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