A few years ago when I was in management, it was my responsibility to look for ways for teams to be more effective in implementing and completing projects.  While we were following industry best practices as recommended by governing bodies such as the Project Management Institute (PMI) and the Software Engineering Institute (SEI), we still had too many projects that were considered failures or took too long to provide value back to the business.  I quickly discovered Agile software development as a possible solution by reading several books and attending local user groups listening to those that had tried the practices.  While I didn’t understand everything I needed to know about the practices, I was eager to get started and see some of the benefits that have been obtained by other teams that have adopted Agile.

However, we were really struggling with the adoption of these practices. We lacked the experience needed to implement the practices successfully and didn’t know how and where to make improvements.  We also had many people resistant over the changes because they didn’t see the value and long term vision of why these new practices should be adopted. Like many companies I have seen who take this approach, many had decided after some time that Agile cannot work in “our organization” and was only good in “theory and not in practice”. They were ready to call it a failure and go back to what they were comfortable with. However, I know we still had the same problems that have plagued many organizations – projects were taking too long, deliverables didn’t meet end user expectations, and we cut corners on quality to avoid going over budget and missing deadlines dictated by the business.  I wasn’t ready to give up quite yet, but knew something was missing in our approach.

Needing help, I sought some advice from those outside of the organization that had been successful in applying Agile. What I discovered was we were too focused on HOW to apply the practices without understand WHY we were using them. We needed some guidelines to help us understand why we were implementing practices to better understand where we can make improvements and still achieve the anticipated results. As I work with teams and organizations new to Agile, I find that not many have thought about implementing Agile this way.  They figure they just need a process methodology, a tool, and a mandate from upper management that we are going “Agile” and everything should come together. That will put you quickly on the road to failure.

Teams need to understand the overarching goals, values and principles that will guide them in their adoption and constant improvement of valuable Agile practices.  Fortunately, the Agile Manifesto (www.agilemanifesto.org) provides these elements.  Let’s explore the Manifesto in more detail.  The goal is simply stated, “We are uncovering better ways of developing software by doing it and helping others do it.”  On its own, the goal is too vague without having more clarification through values and principles.  Let’s read on, “Through this work we come to value: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan. That is, while there is value in the items on the right, we value the items on the left more.”  Now, we have more of a framework around four critical areas: Communication, Delivery, Collaboration and Learning.

While I had read the Agile Manifesto early on in my learning about Agile, I had not realized that there was another part of the Manifesto that usually was not contained in the books and other resources.  There are twelve principles (on right, with more details at  http://agilemanifesto.org/principles.html) that were also developed to help teams understand the why’s of implementing the various practices that have been developed.  Given that Agile is considered an empirical process for continual learning, those responsible for developing the Agile Manifesto wanted to make sure people had some specific guidelines in how they implement, inspect and adapt the practices in their organization.  While I have seen specific practices change over the years, I find that these principles have endured the test of time and can be applied against any process, policy, activity, artifact, or tool to determine if the expected outcomes will be achieved.

Looking back, I knew we were at a critical point and could have made the (easy) decision to go back to our old ways or create a new methodology that would eventually been a failure.  We would not have been successful in our adoption of Agile had it not been for seeking outside help from a person who was experienced and could help us focus on results as guided by unchanging goals, values and principles. Now, when I train and coach teams that are adopting Agile I start with introducing them to the Agile Manifesto and encourage them to put them up in their cubicles or in their team area.  As they try to adapt Agile to fit their organization, they can use the Manifesto as a test to see if the improvement will get the anticipated results and make necessary changes if the test fails.  If you are unsure where to go next, seek help from an outside coach as I did that can help you get on the right path and gets the results you are looking for.

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.

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.

Well, it’s been a marathon weekend with back to back sessions at the SNEC and Mass Bay PMI Chapter’s professional days. I’ve always enjoyed these sessions and these two were no exceptions. I got to have some intriguing conversations and meet many interesting people. In an effort to not overwhelm people’s in-boxes, I deemed it prudent to post my slides here rather then distribute them in emails. more »

Like many other Agile practitioners, I have seen too many cases where an organization wants to adopt Agile, but believes that all they need is a little training. Of course, the most extreme would be when a group believes they can send one person off to become a Certified ScrumMaster and then they can simply train everyone else. While this intuitively sounds foolish, and many people could begin to articulate the shortcomings of this mental model, I’ve struggled to present a clear and succinct view of what exactly why this model doesn’t work. Although I recently came across a very good model that captures what I tacitly knew already. I hope this is valuable to the rest of you out there trying to make the case for coaching. more »

Thanks to everyone from the Mass Bay PMI Chapter for coming to see me speak about Agile in the Enterprise. It was a great discussion and I thoroughly enjoyed it. I have made my slides available from tonight’s presentation, they can be downloaded here.

Also, several people expressed some interest in local Agile groups so that they could learn more. I would point out three specific ones that have monthly meetings and support vibrant communities of both learners and practitioners:

• Agile Bazaar
• Agile Boston
• Nashua Scrum Club

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.