Say No

Tell me if this seems scene is familiar;

Your team is constantly cranking away on new features and undertaking brand new projects as well as doing copious amounts of support for current software which is in the company. Things come up in your business, as they do in every company, so the need to pivot quickly is seen as a positive and your team do it on a regular occurrence.

Due to business pressures and changing requirements, the team are context switching all the time to take on the next most important project that comes along while leaving their current work stagnant in a feature branch for someone to come back to… and don’t even ask if there is documentation.

Business stakeholders are constantly asking for the status of their projects, not knowing that their project has been moved down the pecking order and when they do finally find out the truth, they badmouth the department for not being transparent and also taking too long to deliver making the messenger of that time-scale seem incompetent.

Familiar?

IT departments are black holes for projects.

There are countless initiatives and pieces of widsom all over the internet of how the situation above can be tackled (Kanban for example) but one thing I’ve been looking at recently is the silent killer of all teams; Work In Progress. The easiest way to tackle WIP is something that everyone in your department can do from each developer, team leader, product owner to even the IT managers.

Say no.

The difference between successful people and really successful people is that really successful people say no to almost everything — Warren Buffett Saying no to projects and requests from the business may seem alien to some, but it actually begins to create a behaviour which very few teams actually have; the ability to truly be working on the projects that matter to the business.

The role of the software development team should be, to put it bluntly, to add revenue or lower costs to the company. Software is purchased or developed in companies to tackle problems.

How do you value revenue and cost within a development project?

It could be flat cost that a project lowers, or it could save business operating time which means human cost is reduced, there are numerous ways to put a value on it. However, until you can ask WHY or say NO to every single request to truly see if it is of business value, the team will constantly be working on items which are not adding value to the business or they are generally down to HiPPO (highest paid person’s opinion).

So how does saying “No” help your team? Depending on which methodology you use, there is a simple way to answer, but taking the below Youtube video is case in point;

Velocity equals the amount of work you can do in a sprint and if someone within the team keeps adding items of work to the backlog blindly within questioning the item, you quickly build up a bottleneck of work which will never be unclogged.

So the next time someone asks for a feature or story to be added to the backlog; have a think about the business value of such a proposal. Constantly finding members of your team working on more than one project at the one time and never really getting anything out the door? Add a WIP limit to your team guidelines.

Get a last minute request for the most senior director at the company?

Probably do that… you need to keep your job to help manage the WIP!