Ain’t nobody got time for that.

Damned if you do, and damned if you don’t.

Sometimes, I feel caught in that conundrum. Especially when it comes to things like planning meetings, or retrospectives. If we stop to plan better, we lose development time, but we should make up that time by doing the work properly the first time. If we stop to figure out what we did well and what we did not so well, then we lose development time, but we should be making ourselves more efficient by reflecting and improving.

Specifically in an agency environment, where the pressure to deliver MORE ALWAYS MORE AND EVEN MORE NOW AND WHY CAN’T WE JUST SQUEEZE THIS IN TODAY, it can be difficult to prioritize those things. We live or die by happy clients and billable hours.

Sure, we plan. But do we sit down and do nothing but plan and do deep thinking exercises over what really is needed? Not consistently.

It’s a matter of priorities, really. If we don’t feel the meetings are important enough, then they slide by.

So what’s in the way of prioritizing these events?

Constant adjustment of client expectations.
…which can lead to unhappy clients.
The loss of billable hours, potentially.
The lack of staff buy-in, that these things are valuable.
The lack of a process champion to convince the staff to just try it for a while.

It’s all about how much risk we’re willing to take on. Is it more risky to slow down delivery for these clients, understanding the theory that development becomes more effective over time, ultimately (one hopes) leading to happier clients? Or is it more risky to devote as little time as possible to planning and reviewing, only enough for a general understanding, while keeping billable hours and deliveries as frequent and comprehensive as possible?

Can you convince an unseasoned client to value quality over volume? How many meetings will a client tolerate on their invoice before they start to balk at what most clients think is just useless overhead? On a 4 month project, how much client education can you legitimately expect to accomplish?

I suppose there’s only one way to find out!

Efficiency and Effectiveness

I went and got myself a certification this week – I am now a Certified Scrum Master, thank you very much.

Overall, the class was interesting. The teacher was engaging and the format was interactive. I enjoyed having time to dive into “true” scrum practices, see them at work, and better understand the reasoning behind the process.

A common complaint about scrum is the volume of meetings – the sprint planning, the daily scrum, the backlog grooming, the review, the retrospective. That’s 5 mandated meetings per sprint!

The teacher made an interesting comment, however, that scrum is an effective solution, but it might not always be the most efficient solution. This, I believe, is very true, at least from the day to day perspective. As a project, using scrum might indeed be more efficient, but as an individual contributor on a daily basis, scrum can seem like a lot of overhead.

Indeed, in some agency environments, and in very small teams, scrum may be too much process – there are many situations where a leaner solution like kanban would be more appropriate.

As a systems engineer, I am typically hyper-focused on efficiency – but that should never come at the price of effectiveness. What may be most efficient on a daily basis might not be most effective in the long run.

Things to consider.