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?”