Trying to adapt Scrum

1. What is stopping the Development Team from owning their Sprint Backlog and determining their own priorities for meeting the Sprint Goal?

2. What is stopping them from estimating work by whatever means they might choose, such as story points?

3. What is stopping them and the Product Owner from refining the Product Backlog to the point that work is “Ready” and can be planned into a Sprint and acted upon?

4. What is stopping them from inspecting and adapting their build and other processes, such as by means of a Sprint Retrospective?

I recently joined organization with 3 teams following Agile and are running Sprint 30 currently.

Manali, please read your post again, and then honestly answer the question whether your organization is truly practicing Agile, or whether they are simply re-labeling past practices and calling it Scrum?

Hi Ian,

Thanks for the response. Below are the  answers I think for your questions:

1. What is stopping the Development Team from owning their Sprint Backlog and determining their own priorities for meeting the Sprint Goal?

A. Requirements are changing frequently in the middle of sprint. Bugs and change requests coming from client(actual stakeholders who find bugs by integrating our product in their application) pull dev team from existing tasks and they have to switch task to other priority.

2. What is stopping them from estimating work by whatever means they might choose, such as story points?

A. Requirements are not clear and they dont know how much time it shall take to complete the issue.

3. What is stopping them and the Product Owner from refining the Product Backlog to the point that work is “Ready” and can be planned into a Sprint and acted upon?

A. Product Owner is the one who continuously shifts items during active sprint based on customer request.There is no release plan in place, so adhoc requests come and things are delivered. Backlog grooming session are felt as Planning meeting by dev team.

4. What is stopping them from inspecting and adapting their build and other processes, such as by means of a Sprint Retrospective?

A. Teams feel they dont want to invest in retrospective; as things are going to change, hence additional meeting might obstruct their productivity.

I am trying hard to put things together. Any suggestions on how to tackle such situations are welcome.

Thanks again,

Hi Timothy,

Thanks for the response. Yes, I honestly believe, organization is not truly practicing Agile. Teams believe just delivering fast and haphazard way is Agile. 

Any guidance on such situation will be welcome.

Thank you,

It all stems from whether leadership is behind creating agility in the organization. If it's someone from the team (even if it is a group) that's trying to adapt and propagate agility through Scrum, they are going to run into the organizational/systemic issues that you mentioned. Scrum is not just about starting to do the events, it about cultural change that is supported by the 'framework' that Scrum is. 

The next time the team does a Retrospective, do pose these facts to the team and try to get to the root cause of the several issues you are facing as manifestations of the root cause. 

Manali,

In response to teams believing that Sprint Retrospectives are a waste of time, I would simply ask them how they currently improve how they work.   If they already have something in place, good.   Odds are though that improvement is not on their radar, which I would then respond to by questioning why they feel that they can become more efficient and grow as a company without seeking improvement.   

It should be clearly communicated that their competition is  always looking to improve, and that they will fall behind if they do not do likewise.   Spending 1-2 hours every sprint in this activity seems a very minor cost, considering the gains in productivity that may result from addressing issues and identifying potential improvements.

It does not seem that your Product Owner understands Scrum, either.   Scrum supports agility, in that you have pivot points built in at the end of each sprint to go in a completely different direction if desired.   However, these pivot points do not exist during the sprint.   How can any sprint forecast by the team be trusted (or even accurate) if your PO allows the scope of the sprint to be changed constantly?

I understand that the team is also apparently tasked with run-time support, and this is a pain point that can be discussed in a Sprint Retrospective to possibly manage better (for example: creating a sprint buffer to account for production support, or identifying a 1st-level team to handle all production issues, thereby isolating other scrum teams to focus on sprint work).   This may not address the context-switching (which is incredibly wasteful in and of itself), but it would be a good step to begin the discussion on this, and at least try to improve it.

Good luck.

Thanks for the response. Below are the  answers I think for your questions...

None of the answers given stop the Development Team from taking control of their situation. They are choosing to allow others to control their plan of work during a Sprint; they are choosing to plan work which is insufficiently refined into their Sprint Backlog; they are choosing to view refinement as ad-hoc “planning”; they are choosing to short-change and undervalue their Sprint Retrospectives.

My advice is to bring the focus onto Sprint Goals and the need for people to be able to commit to them. Also, if the choices currently being made are a result of pressure from higher-ups - whether directly or indirectly through the Product Owner - then that must be acknowledged as a problem to be solved.

Yes, the team can go on a strike by sticking to the Sprint Goal and not allowing it to change... But that would make the PO very unhappy, and everyone else as well, eventually. 

Maybe it would be a smaller effort just to switch to Kanban?

What do you mean by switching to Kanban ?

Team will probably continue having more and more expedite requests, they will lose the notions of "goal" and "commitment".

It doesn't look like a pull system :-(

Limiting the WIP (with a Kanban system or shorter Scrum sprint) could maybe help to have less expedite requests and having more a pull system.

What do you mean by switching to Kanban ? Team (...) will lose the notions of "goal" and "commitment".

It already seems to be reality, as "Requirements are changing frequently in the middle of sprint. Bugs and change requests coming from client (...) pull dev team from existing tasks and they have to switch task to other priority. (...) Product Owner is the one who continuously shifts items during active sprint based on customer request.(...) adhoc requests come and things are delivered."

To me this sounds like either a lot of work to make shorter sprints stable (if possible at all), or just stop pretending to be doing Scrum and start doing Kanban.

Filip,

In my opinion, just because the team, the PO, and the business are doing a very poor job of practicing Scrum, doesn't mean that they are therefore a good candidate for Kanban.

Kanban is by no means the magic answer to their issues, but if the intent is to manage small items of miscellaneous work from a flow perspective, they will still require much more discipline around limiting WIP and disruption to effectively practice Kanban.   This discipline seems to be sorely lacking in their Scrum approach.