Knowledge vs Understanding

Knowledge vs Understanding

I have some knowledge of gravity. I see it in action every time I drop my phone. I however have very little understanding of how or why it works. With gravity that’s OK. It’s going to work regardless of my understanding of it. With Scrum however this can causes some major problems.

Everyone has heard of horror stories where Agile was implemented as just a lack of documentation and everyone working together without a plan, doing their best. Undoubtedly these projects fail, hopefully before too much money is spent. Anyone found subsequent mentioning Agile is driven through the streets having been tarred and feathered. This would push any organisations back into the steady hands of traditional development practices. This is however fairly easy to rectify. Define what Agile should be and how frameworks and processes be they Scrum, Kanban, Lean help ensure that there is some form of control and shape to proceedings.

More problematic to my mind is when someone has implemented the ceremonies of Scrum for example but has little to no understanding of why they are doing them. Often someone will have taken both the Scrum Master and Product Owner role as traditionally they would have been in this form of command and control setup. Usually both the person taking command and the team are more comfortable with this due to a lack of self organisation and empowerment. Stand-ups will have become progress tracking meetings. The backlog an unrefined wishlist of everything ever thought of, this will tend to have no indication of value or size. Sprint planning an opportunity to tell the team what they’re going to do in order to meet the project managers plan. Retrospectives a finger pointing or tool blaming session. No sprints end with a potentially ship-able product.

This kind of situation is infinitely more difficult to rectify. Firstly it can appear to the outside world that this is working. Software is getting developed, it must be because it’s being demonstrated. In fact the business is really happy as now at least they’re see something on a regular basis. The software can’t be released but then again neither could it when they were doing waterfall. There is a busy feel to the team as they’re constantly attending meetings that fit with the process. The PM knows exactly what’s going on, mainly because they’re controlling the project with an iron fist. Change is handled with a smile, although the deadline is just extended to allow for this. Hang the budgets, people want software. What’s more the team are happy, they can say they’re doing Agile and they’ve not had to take on any further ownership. They get told what work to do and if they don’t deliver it with-in the iteration it just rolls into next. Happy days. They may grumble about attending pointless meetings and they’d be right too but all in all they’ll be a happy bunch. What they won’t be happy with is when someone points out that they’re missing the point. How can they be when they stand up for 15 minutes everyday?

The challenge here becomes undoing bad habits. The PM isn’t want to let go of control, they want to ensure their plan is achieved. The team isn’t going to want to take ownership and commit to getting things done in an iteration, that’s a lot of additional responsibility. Also those pointless meetings may temporarily get longer as that backlog is going to need a lot cleaning up. The business will be fairly happy as they’re not really having to get that involved, the PM does it for them.

So what to do? Well, according to forum posts, there is no one clear answer to this. It really depends on personalities and what is causing the most pain. One thing I would advise it taking it very slowly and carefully. Coach don’t preach, pull don’t push. If at all possible coach the team towards identifying the dysfunction themselves. Understand all of the issues and tackle them one at a time for any project that is in flight. Work with the person who initially engaged you as they must have realised things were not as they could be. If you can, ensure that new projects have a strong product owner. The criticality of getting the right person into this role and performing is often overlooked. Ensure that there is transparency, this will reduce the panic that a lack of command and control sometimes brings. Get releases flowing out of the door. Keep at it. Once the business see’s the principles being followed and start to reap the benefits people won’t look back.

Leave a Reply

Your email address will not be published. Required fields are marked *