How can we be doing "Agile" development if our manager constantly sets our priorities?

Question

We have been trying to implement an Agile workflow for at least a year. We have tried Scrum and now we are trying Kanban. The problem we are having is that our manager constantly resets our priorities and workload. Whatever we are working on, as soon as he gets any feedback or a new task, that becomes the new "hot" item that we all have to shift our focus to. We also have no fixed release schedule - we push a release whenever he tells us to (often with only minimal testing.)

It doesn't seem to me that this is "Agile" development in any sense of the word. It's more like Waterfall, or perhaps best described as "chaos."

Am I right in thinking that this is not how Agile is supposed to work?

Answer 1

Embrace Change...But Only At The Proper Inflection Points

The problem we are having is that our manager constantly resets our priorities and workload. Whatever we are working on, as soon as he gets any feedback or a new task, that becomes the new "hot" item that we all have to shift our focus to.

Within the Scrum framework, there are inflection points where changes in scope or priorities can be made "for free." Within the team, these inflection points are generally Sprint Grooming and Sprint Planning, where the Product Owner can re-prioritize the Product Backlog to suit the current needs of the stakeholders. From a stakeholder's point of view, the inflection points are the start or end of each iteration.

However, changes to scope or priorities within a sprint are not free. Any changes that would prevent the team from meeting the agreed-upon Sprint Goal should trigger an Early Termination and a return to Sprint Planning. This additional overhead is a visible cost to the project, but Early Termination is a valuable tool available to the Product Owner if the organizational needs are strong enough.

If your Scrum implementation lacks the rigor to enforce the integrity of the Sprint Goal or the need for an Early Termination, then this is an issue that the entire Scrum Team (and especially the Scrum Master) needs to take on board. You should raise these process issues at a Sprint Retrospective, and allow the team as a whole to address the problem.

Release Planning

We also have no fixed release schedule - we push a release whenever he tells us to (often with only minimal testing.)

A well-run Scrum should release a potentially-shippable increment at the end of each sprint. To do this properly, the Definition of Done may need to include continuous integration or user acceptance testing, and the team should factor releaseability into its estimates and the amount of work the Development Team accepts into each sprint.

Alternatively, some Scrum teams estimate the number of iterations needed for a given milestone or release, and the Product Owner ensures that the relevant release stories are moved to the top of the Product Backlog for the sprints where this work will be performed. While somewhat less flexible than a (potential) release per sprint, this still gives the Product Owner and stakeholders enormous power to manage the release schedule without interfering with the team's productivity within a given sprint.

Answer 2

What you describe is far from a Waterfall process. It might be chaos, but it might also be close to Agile. Your manager is responding to the reality that customer priorities are constantly shifting. Responding quickly to those shifting priorities is precisely what Agile is about.

Do you have Sprints? Having time-boxed sprints (think 2 weeks) is your protection from being pulled off a development task halfway through. The trade-off is that the development task needs to be small enough to fit within the Sprint.

It is absolutely what Agile is about for the composition of a Sprint to be changed only minutes before the Sprint starts. This is how your team responds to customer needs with agility.

As part of the deal, you get to work on a Sprint for a set amount of time without a new direction. But what you're giving to your manager and the customer is the ability to have a new top priority addressed in no more than a Sprint's length of time.

More details may produce an answer better-tailored to your situation. Bottom-line reality, however, is that you will always be shifting to new, hot, top-priorities. If you're still working on a priority that was identified a year ago, you're probably not really addressing the top priority. And why would you want to work on anything except the top priority? Once you address the current top priority, you move on to what is identified as the next top priority.

Your desire for a fixed release schedule tells me that you're probably not doing Continuous Integration and Continuous Testing. The hope in Agile is that at the end of every Sprint, you have production-ready code, so you shouldn't care that a given end-of-Sprint product is chosen for release. This takes a LOT of discipline, but is again about responding to the reality that releases on a regular schedule do not necessarily meet the customer's needs.

Answer 3

It doesn't seem to me that this is "Agile" development in any sense of the word. It's more like Waterfall, or perhaps best described as "chaos."

Am I right in thinking that this is not how Agile is supposed to work?

"Agile" doesn't work in any particular way as it is not a process. It's buzzword adjective to describe a set of principles.

If you are doing Scrum, sprints are (should be) locked. If your boss has a priority mid-sprint, it will either have to wait until next sprint, or something in the current sprint backlog as to be taken out and replaced with that, which has minimal impact. If you have an emergency lane in your Scrum, see below in KanBan.

If you are doing KanBan, you have two options:

1) All your boss can do is reorder the backlog stack and put it up top. When the next developer becomes free, he will start work on it as soon as he can.

2) If you have the emergency lane, all work on everything stops when your boss does this. He will soon learn that it better be a real emergency to do this, because the entire pipeline from PM to Dev to QA to Deployment is halted.

Notice that at no time are you being randomly pulled off what you are currently working on and thrown onto something else, unless the entire team is stopping too, so you know it's serious.

We also have no fixed release schedule - we push a release whenever he tells us to (often with only minimal testing.)

Here's the ideal:

Scrum - Through continuous integration and acceptance (QA), by the end of a sprint the project should be deliverable to the client in a stable state. How else are they to review that sprint's work for correctness and have a tight feedback loop?

KanBan - The way I've done it in the past is simply at any point, the boss can say "release time". At that point we but a little mark at the top of the backlog, and no new work is pulled in until the pipeline clears and the release is built. Through continuous integration, etc. it can work.