3

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?

| improve this question | | | | |
  • Yes and no. The Agile Manifesto values "[r]esponding to change over following a plan" but still provides for planning and a sensible demarcation between iterations. A more detailed answer has been provided below. – Todd A. Jacobs Apr 17 '14 at 17:23
  • @MarvMills I rolled back your edit; the original syntax is grammatically correct even if the negatives are inverted. :) – Todd A. Jacobs Apr 17 '14 at 17:35
  • @CodeGnome Duh! Of course you are right, what was I thinking. I read I as "It seems to me that..." :( – Marv Mills Apr 17 '14 at 19:37
4

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.

| improve this answer | | | | |
  • Regarding our release schedule, the problem is that our manager tells us that "I promised our bosses this feature [often not in the sprint] would go in this next release!" If left to ourselves, we could probably produce a release at the end of each sprint, but we are never allowed to because features are constantly being pushed into and pulled out of the promised release. – user1071914 Apr 18 '14 at 14:58
1

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.

| improve this answer | | | | |
  • I perhaps didn't explain what I meant by "he changes our priorities". I meant that he changes our priorities in the middle of the sprint. For example, if our sprint starts on Monday and we have five people working on tasks A, B and C, he may come in on Wednesday and say "I'm adding X and Y, and pulling three of you off to work on a completely different project." This happens every week. I've never heard of or seen that in any Agile workflow. – user1071914 Apr 18 '14 at 14:54
  • Right. I figured that was one of the possibilities. As such, @CodeGnome's answer points to the response: abort the Sprint and start a new Sprint. Be very clear that giving you the new priority means throwing away work that is in progress. Perhaps it is worth the lost productivity, but your manager should be sensitive to losing productivity. – Dane Apr 18 '14 at 16:58
0

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.

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.