Too much of a good thing?

Jezza Sutton Neurensic Blog

Someone asked me an interesting question at the end of last year, which sounded like “can you have too much of a good thing?”. This person works for a large organization that implements Agile methods in some manner, and their concern is that one of the stakeholders is getting in their face a bit.

Can you have too much business stakeholder involvement?

Most people seem to be fighting to get involvement from the business stakeholder side, not getting too much engagement! I know from personal experience how hard it can be to get busy people on the business side to commit even a short amount of time to working with the team. Can there be an opposite problem?

Well that depends but yes, I think the potential is present and requires some skill to manage. Like everything we do as project managers, most of this Agile stuff us about the people and getting teams interacting. Scrum artifacts and ceremonies give us a framework to help us do that.

Imagine you have a business user who has some project management experience (real or imagined) and this user is on your team. They want to help so much they want to run your sprints and make sure everything is working like clockwork and the deliverables are being delivered. I suspect it is something like this that prompted  my contact to quote “…it is the ones that are breathing down my neck that are bugging me…”

Sometimes this is hard to manage over-enthusiasm but there are perhaps some steps to take. It is a delicate situation to be sure and one that, from look at the Interwebs, is not the most common of challenges. Most people have more problems with teams being interrupted or not getting engagement from subject matter experts or other business people. However, you can see how it can happen with some personalities.

What can this do to your team and your ability to deliver?

Firstly this is distracting you. Your task is to make the team perform at it’s best and working together and this person is taking away your time. It takes something like 20 minutes to get back on track after any sort of interruption so these can really make a mess of your day.

Secondly, this may be causing the whole team to lose focus. If you are working in a Scrum time boxed process it is very tempting for someone to change the priorities to meet their immediate concerns of the moment. While our intent is to move away from long term plans covering months, changing priorities every 5 minutes is not going to allow engineering to focus to completion of a task.

Managing this situation requires a combination of delicacy and firmness. It is important that the people on the combined team are engaged and enthusiastic, and nothing kills enthusiasm like being told you’re sticking your nose in too far. Appreciating what this person is doing for you is really important and the fact they are engaged in your project is fantastic.

It is important though to stress the process. I’m never one for loads of process and I’ve some opinions on how some previous projects I was on died due to the weight of process (ironically, this was an “agile” or “iterative” project).  However, there is a process and it needs to be followed. In particular, if the process is time boxed then there is an appropriate ceremony for ranking the backlog and an appropriate process about what backlog is accepted into a sprint. It is important that the business understands the separation of these two. Business sets priority, engineering defines what of that prioritized content fits into a sprint because the team has agreed upon story points (i.e. “size”).

If the team is open to a process that is not time boxed, then Kanban can perhaps provide a more responsive process. It doesn’t necessarily get things done faster but I am using it currently and it does allow me to change ranking any time I feel it it necessary. I do still tend to hold a ranking meeting on a weekly basis and for the main part our priorities stay fixed for that week. We also tend to remain disciplined about ensuring what has been started gets finished, at least at the task level. If we picked up a ticket to tweak the GUI sorting then we should finish that ticket.

The challenge in such a situation as “over engagement” is corralling the process without killing the enthusiasm. And that, dear reader, is a people skill and a delicate balance between too much and too little process. Project management is so much more than applied process, which is of course why we love it.