Are you failing with Agile, Here is a checklist to help you fail?

I had a very interesting coffee discussion yesterday with a senior product engineer at a very large cloud computing team. It was centered around the fact that in Scrum when we put the pressure of velocity and show the demo, teams start shipping crap to customers.

Many teams working in Scrum and Agile techniques take Agile as a way to do fast paced development. When you look at the net output after a few years, the product is a bunch of messed up code that is worth throwing out.

The agile manifesto is centered around – Working Software over comprehensive documentation –

I wish this was instead written as  – Delighting customer over comprehensive documentation. Writing a well done product takes a significant amount of discipline from a product team. The teams that focus on output of showing something fast end up in rotten software over time.

Here is a checklist that will tell you if you are going to failing with your product. These are in no priority order

1) More Velocity Syndrome – Your customer or management is focused on more velocity every sprint. Soon coaches are trying to optimize for waste removal , fast paced demos and a each day feels like a 100 meter race.

2) Agile or Scrum Become more important that the product itself .  Think  of any place that has ever succeded by putting focus on the techniques. No agile technique will help you if your organization cannot focus on less things and get them done in a systematic way

When you are doing agile well, you should not heard the word agile or Scrum in a organization.

3) Agile coaches rule the roost: There is a new wave of  people who were not there 10 years ago . These are called Agile coaches. Many are self proclaimed gurus with no actual complex product creating background. Choose your coaches wisely and don’t listen to them managers. Good teams choose coaches well. If your coach comes in and starts telling you do that everything you do is wrong, show them the way. Ask them to stay for a release cycle and show you how to do it all the way.

4) Managers addicted to keeping people busy: Many managers are busy trying to keep people busy . Writing a good product requires focus, patience and a bit of love. If the manager is always trying to keep team members busy where is the time to innovate. When you hear someone saying i want 80 percent utilization, start looking for a new job. They clearly don’t know what they are doing.

 5) Product Backlog fiasco – Your backlog looks like a so messed that you feel like throwing up. A good backlog should be around 50 to 100 items and should be visual. The team should have a clear idea of what they are building.

6) Estimation Accuracy Epidemic ( Often called as Fibonacci Fever) – You will see teams trying to size work as 2 points, 3 points, 50 points. Management disagrees saying they want more accuracy of estimation.

Software is a empirical system the only way you know your product is right is when someone uses it. Follow a simple rule ship a few items to production every month or as needed.

7) The myth of the self organizing team – Putting five people together does not make anyone a team. A team needs a clear purpose, goal and a good coach to win. Some kinds of work may not need a team.

8) Bugs rate is going north – IF  you do Agile well you should see 0 defects. To do this you need to do a few simple things 

  1. Work in pairs in small teams
  2. Test your product well and don’t check-in code that does not have unit test
  3. When you find a bug, write a test first, check it in, and then fix it. This way you never have to see the same bug again.
  4. Keep Design simple but not Stupid. Many agile teams have gone to the extreme with Kiss principle. KISS – Keep it simple stupid does not mean – Do stupid things in code”.  Agile does not mean no design. Agile means you take the time to do necessary design.
  5. Always demo work only when completely done.Done means done . There is no half done fully done.

9) You feel like moving from Scrum to Kanban or vice versa. Note that the process is not the problem, people are. When you switch to scrum, if you dont follow the values of Scrum, Openness, honesty, transparency you will fail. No questions asked.

10) Feedback and failure  is not appreciated here.  – If you are worried about giving feeback to any one in the group or  your manager for lack of fear of losing job or being humiliated, you are already in the wrong kind of team. if your organization i not appreciating failure or feedback, they do not appreciate you.

Of all the things the difference in great product companies is the ability to listen to customer and employee feedack

Do let me know if you check at least more than five in the list above yes. If you checked none of these items above you are working for a fake organization.

Have a great time building awesome products. Focus less on Agile focus more on your customer experience.