Mini-Waterfall Smells – How agile are you Really?

More and more companies are adopting agile development practices (or are trying to).  Instead of delivering software once a year, more companies are now able to deliver every quarter.  More projects are working from a product backlog instead of massive requirements documents.  An increased number of developers are practicing TDD.   However, achieving true agility on a project requires much more then delivering software 4 times a year. 

Just how agile are you really?  It seems that a lot of organizations that call themselves “agile” are really just doing mini-waterfall iterations instead.  Here are my top 10 smells that your team is in a mini-waterfall rut instead of true agile development. (these are not in any particular order)

  1. Your development team has a code freeze several days before the end of the sprint so you can get your testing cycle done. 
  2. Your QA team is testing the previous sprint while the developers are working on the current one. 
  3. None of your tests are automated.
  4. You can’t pull the next story off the backlog to work on because the requirements for it have not been through the sign-off process yet.
  5. Your product backlog is not ranked by priority.
  6. Your user stories do not have any business value assigned to them.
  7. You are only tracking development tasks in your iteration and on your burndown.
  8. Stories are considered “done” when development is done coding them.
  9. You have a full sprint dedicated to bug fixing every few iterations.
  10. Your QA team is a separate team that gets scheduled builds once or twice a week.

“Shout-out” Shoebox – Boosting Team Morale

I mentioned this idea at the agile conference and have had several emails about it over the last week asking for the details of how this works.  So, I thought it would just be easiest to post it here.

Celebrating accomplishments is something I am pretty passionate about on teams.  On a recent project, we implemented the “Shout-out” Shoebox.  I took an old shoebox and decorated it.  Then, I just cut a slit in the top of lid so people could put there shout-outs in the box.  The box is open to the entire team during the course of the sprint.  Anytime a team member wants to give a “shout-out” to another team member, they can write it on a card and put it in the box.  They can range from someone helping you with a difficult task, someone going above and beyond the call of duty, etc.  If you have distributed team members, encourage them to email their shout-outs to your Scrum Master who can then put them in the box as well.

I would then recommend that at the end of your demo, someone from the team gets up and reads all of the cards out of the box.  This is even better if you have “chickens” or other stakeholders at your demo. That way, folks on your team are getting public recognition for their work in front of a larger audience.   You can also include small give-aways for folks, too.

This is a no-cost, very quick and easy thing to implement that can help bring teams together and boost morale. 

Why is Self-organizing so hard?

I was talking with a former co-worker last night who is working on a team that is struggling to adopt Scrum.  It appears that one of their biggest road-blocks is the teams’ inability to self-organize.  As soon as the sprint planning meeting is over, the team kinda waits around for someone to tell them what to do.  I have observed this same behavior on other teams as well.  Everyone you talk to that works in a command-and-control environment generally complains about it.  However, when they are given the opportunity to work on a self-organizing team, they immediately wait around for someone to tell them what to do.  I started thinking about this a lot last night trying to figure out why this happens on so many new Scrum teams.  I’m sure there are several different reasons for this…here are the top ones I came up with:

  1. Self-organizing means you are accountable for your actions.  When someone is telling you what to do, you can always blame them when it doesn’t work out as planned.  However, if you are self-organizing, that means you are now accountable for your actions.  That can be a very uncomfortable place to be for many people.  The rewards are high but so are the risks.
  2. A lot of teams have been burned too many times before.  A classic example of this is on a team I used to work with.  The development teams used to take a lot of ownership in deciding what to build and how to build it.  As the company grew, more staff was put in place to drive the direction of the products.  The development organization continued to function as always but suddenly started getting scolded for making bad decisions.  So, they backed off and went in a “sit and wait” mentality.  They were too scared to make any decisions for fear of being scolded.  They had to wait for the product team to tell them exactly what to build.  So, when this organization started implementing Scrum, the team was scared to make any decisions until the product team gave them exact details on what to do. 
  3. I think some people just flat out like being told what to do and others like telling people what to do.  It goes against their nature to work in a collaborative, self-organizing team.  If you have a team of people that like being told what to do and a leader that likes telling them what to do, I think you are going to have a hard time getting these teams to operate well in an agile environment.  I would suggest breaking up these teams and mixing them up with other people to help break up that mentality.

“Tests” to Determine how Agile you are

I just finished reading “Making Agility Stick:  What’s Working, What’s Not” from the Cutter Consortium(http://www.cutter.com/offers/makingagilitystick.html).  It starts with an article called “On the Stickiness of Agility in Software Development” by Laurie Williams.  There were 3 “tests” from Scott Ambler to determine if a company is truly agile or not:

  1.  Do you have an automated test suite, and are you running your tests?
  2. Can I talk to your stakeholders today?
  3. Do you have working software?

I think these are 3 fantastic questions.  This reminded me of the “Scrum test” from Jeff Sutherland’s talk at the Agile 2007 conference where he had the following three questions (I am paraphrasing them):

  1.  Are you running iterations < 6 weeks?
  2. Is your application tested and working at the end of each iteration?
  3. Does your iteration start without the specs fully fleshed out?

I think Jeff’s 3 questions are a good gauge of how well you are following the Scrum framework but I like Ambler’s questions even better.  You can answer Sutherland’s question 2 with a yes but still be running a mini-waterfall by developing for  2 weeks and testing for 2 weeks.  Same with his 3rd question.  I know of organizations that have 4 weeks iterations that go like this:  week 1 detailed design, week 2 and 3 code, week 4 test.  That isn’t very agile 🙂  However, it would be very hard to answer Ambler’s 1st question if you were operating in a mini-waterfall environment.  If you have an automated test suite that you are running, then you shouldn’t need a testing phase at the end of your iterations.  I think both of these sets of “tests” are good but there more we could ask.

This got me thinking about what 3 questions I would ask to determine how agile a team truly is.  I’m sure I will change my mind 10 times in the next 10 days but for now, here is what I would ask:

  1. Are your developers still writing code during the last few days of your iteration?
  2. Are you writing your acceptance tests before you start coding?  Are those tests automated at the end of the iteration?
  3. Can you show me your product backlog that is prioritized by business value?

I am interested in hearing what the top 3 questions would be for anyone else!

Agile 2007 conference review

I spent all of last week in DC at the Agile2007 conference.  All in all, it was a great week and I learned a lot.  There is definitely some room for improvement next year in terms of the schedule, hotel layout, and organization.  However, for the most part, the speakers I listened to were excellent and there was a lot of great content.  My top 3 big takeaways were:

  1. Jean Tabaka’s talk called I Hate Monday’s talked about how meetings can be run better.  This alone made the entire week worthwhile.  This presentation was full of great tips and techniques to run more productive meetings.  I sure hope she writes another book soon!
  2. Good Product Owners are hard to find.  Several companies are facing the same challenges around Product Ownership.  This is such a critical role to the success of an agile project and yet so many companies are not investing properly in the product owner role.
  3. Traditional test teams are VERY reluctant to change to agile.  Sad but true.