So you can't do Scrum

 If you find yourself in a situation where you’d like to adopt or transform from a waterfall to an agile method but there is a big road block in your way, what should you do?  Perhaps an executive has issued a proclamation against agile, contractual issues prevent it, or key stakeholders just do not want to make that change. The question is presuming that you are attracted to Agile but you just can’t get there, so now what?

When I was recently faced with this same question my initial response was well that’s too bad, just keep doing what you have been.  Hybrid agile things are often not a good idea. They just create confusion and sometimes extra non value producing work.   The risk is people cherry pick practices from different methods and use the “introduction” of agile as an excuse not to exercise discipline in how they operate.  See related post on Shu ha ri http://agileadventure.blogspot.com/2013/04/shu-ha-ri-and-self-organizing-teams.html#links The second risk is that a halfhearted adoption of agile has a great possibility of “poisoning the well” for a latter successful adoption.  There is already some significant factor holding back the adoption of agile; those naysayers will point to the weaknesses in the half adoption as reasons why it is not a good idea to begin with. Then it makes a subsequent decision for this team to adopt an agile method like scrum even more problematic.

So I say if you can’t go Agile then don’t go half way.  But this response is probably not going to be satisfying to the person asking the question “now what?”  They may even think deeper about this and say “you mean to say I can’t iteratively and incrementally approach my agile transformation in an agile fashion?”

So here is my advice.  Don’t claim you are practicing Scrum and don’t try to practice Scrum, the leading agile methodology.  What you can do is embrace agile values and continue with your current method.  The Agile manifesto is as much a declaration of values more than anything else.  The “Twelve principals of Agile Software” is another good source of guidance http://www.agilealliance.org/the-alliance/the-agile-manifesto/the-twelve-principles-of-agile-software/    What you can do look for alignment that people are doing what they said they would do, are they learning, is working code being produced.  For example:

·         If you already have a practice of doing weekly status reports you can pretend that you are operating in one week sprints. Most status reports contain a section on what we did last week and what we intend to do next week.  Follow up with folks.  Did they really do what they said they would do last week, have a discussion over the reasons why not and acknowledge the success when it happens.

·          Ask if they’d like to have a brief discussion before they write up their goals for the next weekly status report.  See if you can identify impediments that they will need help with.

·         Ask “when can I see a demo?” Assert that you’d rather see something early and untested if necessary.

·         Walk around and engage people in face to face conversation.  You’ll be surprised at what you learn.

·         You can hold a retrospective without saying “retrospective” ask “what did we learn from doing that?” Create space for the ensuing discussion.

·         For every document produced by your current non agile development process (especially those in excess of 10 pages) ask the author(s) “who is the audience for that document?” I’ve been amazed at the number of people who create documents because the process says they need to but they are unaware of who is supposed to consume that document.

·         When discussing features ask “how many times does that happen?” or “What would happen if the system didn't support that?”

Shu Ha Ri and self organizing teams

Preface. I've been away from this blog for a while as I've been on projects with a high degree of security and afraid of disclosing something inadvertently. But since this article references my son Jason and I don't believe I am disclosing any secrets it is here for all to see.

 I recently ended an engagement with a customer as an Agile Coach. I learned a lot from the experience and I'm gratified by many of the comments I've received from those I worked with on the project. None the less as I've had a chance to reflect on this engagement it brings to mind that we should recognize that there are multiple strategies to follow regarding the process some refer to as Agile Transformation. In many cases managers observe a sea change and decide that they also want an Agile organization. Or they read a report from a leading industry analyst that says in so many years 80% of all projects will be Agile. How one goes about that Agile transformation is critical for determining the outcome of the transformation effort.

Culture and organizational norms are an important factor in the strategy to engage in agile transformation. Years ago a colleague said to me "just tell them what you want them to do and stop asking so many questions." I was initially shocked by such a comment. But now I realize that I was not reading and adjusting to the situation I was in. I was continuing an engagement style that I had fallen in to the habit of that was more appropriate for a team that was at Ha or Ri. (if you are not familiar with the Shu Ha Ri stages of mastery I urge you to check out work by Alister Cockburn at http://alistair.cockburn.us/Shu+Ha+Ri.) These are Japanese words and roughly translated they mean first learn, then detach, and finally transcend.

 I think this dynamic is also at play in certain situations when I work with someone and and they ask for help with a tool or a program. I am always inclined to want to give people a fishing pole thinking it is more valuable than a fish. (Give a man a fishing pole you will feed him of a life time, given him fish and you feed him for a day) But what I miss is that they just want and need to experience an initial success. They don't need all the theory and such. My son will even tell me sometimes "Dad, I just want a fish". This is code for stop explaining and just tell me what I need to be successful one time. I need to learn patience so that their initial success will generate hunger for the fishing pole.Then I can teach.

 The Shu Ha Ri wisdom says for a beginner, some one at Shu ,they should rigorously follow the rituals and ceremonies described by the practice until it has become ingrained and part of their "muscle memory". The thinking is that until they have lived it and personally witnessed the benefits and achieved a deep understanding they are not yet in a position to tailor or depart from the tradition. Unfortunately this notion runs smack into a conflict with the notion of a self organizing team.

People begin their Agile transformation with a short course. They hear about self organizing teams and then after they start practicing scrum they say this business of standing up for the 15 min daily scrum meeting is silly. Lets all sit in the comfy chairs at the nice conference table and have a 30 to 60 minute meeting. We are are going to self organize this meeting to something we are more comfortable with. This begs the question - is the right to self organize something a team earns or is available from the start?

 My personal journey to "be Agile" came through a variety of initiatives that were more evolutionary in their nature. Small incremental inspect and adapt cycles towards becoming more Agile. Until my most recent engagement I assumed that was the appropriate path for every one else.

Now having more experience with highly structured and command and control/para military type organizations more common in government organizations I can see the wisdom of Shu Ha Ri. Assuming there is support from the leadership in the organization an organization with a strong command and control culture is probably better off with more radical and abrupt adoption of Agile practices along the lines of Shu Ha Ri. They don't get to use the self organizing principal as a license to bend and adjust practices till they have delivered 100 units of value or some other metric of real progress and accomplishment. They need to get past Shu before they can self organize.

 Consider an organization that has had some success and wants to begin a transformation to Agile.They had already achieved a certain level of maturity and may already have a software process improvement effort underway of many years a gradual adoption of Agile may make sense. They get to credit for their past success and more rapidly pass through Shu on to Ha and eventually Ri. Because they have a legacy of producing working software I'd say they have more latitude to adapt and self organize.

So I've learned that it is critically important to read the setting and adjust gears, For a new team, especially one grounded in command and control, rigorous application of agile practices and ceremony is important for success. Teams that have a history of producing working software have earned the right to adjust and transcend the traditional practices.