By Kevin Kerr, The Resource Group
To compete in today’s marketplace, your small business may be faced with the challenge of getting your software development team “Agile enough.” You may not have sufficient resources to employ all of the classic Agile/Scrum methodologies (Scrum Alliance basics) that larger companies can leverage. But a small business, even with a single developer or two on staff, can still apply Agile techniques to make your team more responsive, and thus more competitive for today’s business.
The most critical of these methods is the concept of a central prioritized backlog. Even a single developer can receive conflicting priorities – Customer A needs this patch by the end of today, Customer B is still waiting on their bug fixes, help! the company web site is down, and drop-everything-because-the-boss-needs-this-RIGHT-NOW! Add another developer or two to the team, and some weeks they may spend as much time keeping tasks and priorities straight as they do writing production-quality code.
The Resource Group uses the Agile concept of a central prioritized backlog to make our development team more efficient and to help keep us focused on our clients’ needs and requirements. Classic Agile/Scrum considers an average development team to have seven members all on the same project (optimal size according to Dr. Jeff Sutherland; see also http://www.scrumalliance.org/pages/scrum_roles ). With proper prioritization, even two developers can share a backlog that will help make their work tasks more efficient.
A central prioritized backlog starts with all tasks on all current projects and ranks them in relative order to each other. When creating your own backlog – don’t get too detailed to start with – create tasks using four- to eight-hour blocks of time, then put them in order by priority: the top task should be what needs to be completed first, and the bottom task is the last intended to be performed. Prioritization factors will vary by business type and needs, but delivery date, size of engagement, and relative complexity are all important factors to consider.
The real key is getting all stakeholders to have input to the backlog and agreeing on the priorities. The first time you create such a backlog, it may take several hours or longer to get everyone to agree. But once the backlog is “stacked and ranked,” it should become fairly easy to maintain – each new task that comes up must fit somewhere in the list (and not necessarily at the bottom).
And when you do you re-sort your backlog list? As often as needed, but only you can decide what suits your business needs. Daily stand-ups may not fit your company culture (yet), but even a once-a-week scheduling meeting can keep a backlog in order for 5-10 developers who are each working on multiple different projects at the same time.
So grab a whiteboard and some sticky notes, or even just a spreadsheet, and start prioritizing those tasks into a backlog – your development team will start getting more Agile when they have only one source of tasks and priorities. And the more efficient your team, the more focused you will be on satisfying your customers.