7 ways to mess up your Agile implementation (continued)

Part 2

Since everybody is talking about the success of Agile, I’m thinking that the failure is just a different facade of success that is worth tackling. This is a continuation of a previous article published last month, this time also giving some arguments to support my position.

1. Appointing the manager as also the product owner of the team

The product owner is responsible with maximizing the customer value of the product to be delivered. The profile is that of a big-picture thinker, experimental, flexible, product-driver / customer-obsessed person.

One of the key-differentiators of Agile way of working is that the responsibility of delivery falls with the team. Once they understand best the customer need from the product owner, they should be allowed to self-organize to ensure the best delivery.

And here is the problem with having product owner as your boss:

1. Easy to mix-up responsibility / accountability of the delivery. Most likely, the product-owner, as being the manager as well, will feel that he / she needs to take charge, assume, etc. So much for team responsibility, self-organizing, etc.
2. Let’s say the first point is not an issue. What if at demo, the client is consistently dissatisfied with the delivery so it seems that the product owner is not actually doing a great job in understanding the customer? Ideally the team should be able to challenge the product owner and even request changing it because it impairs their success? Can they actually do that to their own boss who decides on their paychecks?

2. Using scrum master as a glorified secretary of the team

The scrum master is a servant leader of the team, is able to remove impediments for them, is constantly ensuring that team dynamics are good.

Only a small part of his / her duties is the actual organisation of ceremonies, however this is the easiest and most obvious part to implement. Without the previous mentioned functions, you only end up with a demotivated person acting as a secretary, setting meetings, dragging people to participate, trying to gain importance as per the title. And team dynamics is left somewhere in a drawer, they might manage or not.

What if scrum master would not be appointed, but elected by the team? And this role would not be a job title, but simply a role that can be short or longer term, as the team decides?

3. Using daily stand-ups as department meetings to discuss anything for 1 hour

Daily stand-ups are status meetings to understand the progress in the sprint and if there are any impediments in delivery. This should be done with respect of everyone’s time and needs to be effective so that everybody goes back to work quickly. It is not an occasion to show off or justify working time, but an opportunity to signal early if issues have raised that can threaten what the team has promised to deliver.

4. Skipping the retrospective session, because hey, we all know each other, we don’t have time for this

This is an easy one. Retrospective if about understanding what works and what doesn’t in the team. It is the place where measures of performance are discussed, but also the place where team deals with their own interactions and conflicts. The timing of this meeting between the client demo and next planning, makes it a perfect occasion for learning and adjusting for the next sprint. Skipping this ceremony allows for frustrations to build up, for mistakes to become chronic pains and for success to be a happy and surprising encounter.

5. Implementing Agile without the client

The client is central to Agile way of working and the very reason for which it was invented. Incorporating client feedback early and continuously makes companies successful and competitive. Working on projects in sprints, but not receiving customer input is simply turning fashionable a waterfall project.

6. Not measuring, because our business is too complicated

Measuring takes time, it is bureaucratic and boring. You really need to like drawing up charts, comparing data, number crunching, etc. But this is key to any progress – how will you know that you are better today vs. yesterday if you do not measure yourself? Not measuring, but having just a gut feeling about your success might be equivalent to falling in love and everything looking all sparky, when nothing has changed.

7. We are chaotic, hence we are Agile – who needs documentation?

Agile projects all have documentation just enough, just in time and just because. The fact that hundreds of pages of documentation are not written before starting the project does not mean that the approvals are not in place at the release time, nor that there is no audit trail. In Agile documentation is simply evolving at the same time with the project, not taking unnecessary details.

So this is it from my side, curious to see what your experience is.