Dual bandwidth agile team?

Question

I'm trying to figure out how to solve some challenges that my team is facing while attempting to apply agile. The one that is causing the biggest headache at the moment is due to the dual role nature of projects that come into the business.

Basically, we have a number of software that we produce and deploy for various markets. This software is planned and scoped in quarterly release cycles. At the same time we have large contracts come through that take anywhere from 1-3 months to complete. The problem comes from the fact that management wants to work on the incoming contracts first and foremost and all normally scheduled release work is brushed aside to get the next contract out the door.

We're trying to scope the releases to shorter than 3 months so that a contract would have to wait that long for work to begin.

Has anyone dealt with a scenario like this while trying to apply agile? What are some ideas/approaches to working on release scoped/planned work and keeping management happy that high priority contracts are being delivered in a timely manner?

Answer 1

The only way I can see is an internal market.
Assign a $ value to the next release of your 'real' product and then you can fairly apportion effort to that vs the incoming contract.

Of course the value of the 'real' product depends on management but at least it pushes the problem onto them in a rational way.

Answer 2

If you haven't got management buy-in, doing Agile is very difficult.

By the sounds of it, the management don't have a problem at the moment. They drop a contract on you, you do it, the quarterly release slips but they get the nice contract money.

Is your team large enough that you could conceivably split it into two teams: one focused on the internal releases, one focused on contract work or perhaps two teams that swap over responsibilities after each release so they each get to spend some time on green field and some time on BAU projects.

On a general Agile methodology note, you'd be better off with Kanban than Scrum because it sounds like if you tried to plan iterations, you'd end up with 90% of the work in the unexpected 'contract came in' column.

Who is driving the quarterly releases on your product: customer requests or what you would like to do? Like mgb said, what profit is the business making from them?

Answer 3

I think it's first important to define by what you mean to "apply agile." There are a lot of different parts of agile and I would try and start small with the pieces that you can do. For example, do you have a continuous build running? Have you developed a product backlog?

Working on multiple projects is difficult to begin with but without management buy-in (as Wysawyg mentioned), it will be difficult to become more agile. You need to show the benefits of agile development in terms of cost savings to management. Have you determined why you want to become agile? How will it help? Once you have shown why, then just start doing some of the pieces that you can and after you start seeing some improvements, talk to management about the bigger pieces.

Answer 4

Even in an agile workplace there is some kind of "resource planning" at management level. As long as there is some predictability on when the contracts come in, the allocation of people to teams and between teams can be decided before the start of each iteration.

If an unexpected event occurs and it is necessary to terminate a sprint, or re-plan it mid-iteration then that's what you have to do.

Agile methodologies are supposed to help you to "embrace change" and make sure that the highest value requirements are delivered first. They don't change the fact that there is always more work to do than people to do it, but they do provide a framework for managing the chaos that this will cause if people aren't realistic about priorities, actual staffing levels and work rates (or "velocity").

Agile doesn't mean that there won't be difficult conversations, but if it's done well then the conversations should mostly happen in time to take some kind of corrective action.

---

I'm assuming that there is some kind of officially sanctioned agile process in place. I don't believe that agile methodologies (e.g. Scrum) can be made to work under the radar, because:

1. Agile methodologies are about self-managing teams. If your management doesn't accept the teams' right to self-manage then there is going to be a power struggle.
2. Agile methodologies are about having high quality communication both within a team and between the team and it's stakeholders. It doesn't work if the process is hidden from the stakeholders.

---

From the comments above, your process seems to be in pretty good shape. You have identified a genuine business problem and you are having a constructive dialog with your management team.

Answer 5

Instead of looking at your situation as multiple shorter projects that are interleaved into one longer project, you might instead think of it as a single larger project. The small projects then become interrupts or the equivalent of scope changes, which are things that all large projects need learn to manage anyway.

As with interrupts and scope changes, you will need to address schedule impacts, the effect of "context switching" overhead on your staff, etc -- and possibly consider dropping features or cutting back in other ways in order to make your next scheduled delivery date.

If management wants the new work to be done first, while the mainline project is put on hold, then it seems to me that's what you should give them. Why drag your feet for 30 or 45 days before starting the new project? From the perspective of a single larger project, that's certainly not very agile. You could instead get a faster start, and then communicate the resulting impact.

Over the long term, you may find certain staff members are slowed down more by periodic course changes than others. In those cases, you might consider making semi-permanent assignments, so they can continue what they were working on, even in the event of interrupts. Similar arrangements are typical in larger, interrupt-driven shops.