This Scrum Thing Isn't Working
When a leader says 'Something is off, Scrum isn't working' what questions and probing do you do to find out the root of the real problem? I have a group that has only been doing Scrum less than a year, so I don't think Scrum is the problem as they are still in the formative stage IMO. Eager to hear your thoughts based on the summary below...
---
March: Embedded with Organization X at our company, that did not yet use Scrum to deliver software but said they were open to it, so we moved a Scrum Master into that area.
June: Director of Organization X said that his managers and team replied favorably to it, so let's expand it to add another team!
October: Director wanted to add a third team! (all teams at this point in Organization X are doing Scrum or starting their Scrum journey). The first team that started in March is obviously the 'most' mature of the three teams, but still has a long way to go since this is their first time doing it.
November: Director says, 'We're too slow, something's not right. I could just take two guys, put them on a tiger team and skip all this Scrum process and knock out more work than the 8 person scrum team does in the same amount of time'. Director's Assertions: Scrum isn't working. Devs are idle waiting on QA, Scrum teams can't handle ad-hoc requests that come up (he's frustrated that Devs could technically start doing more work but are refusing to pull in new items that cannot be 100% completed, so he feels they are wasting two or three days just waiting for testing to finish. He wants them to just take more work and them to stop saying 'It has to wait until the next sprint', etc).
- We've explained the need for the team to be more cross-functional and start swarming on testing (Devs should help QA out near end of sprint, instead of just being idle). Yes I know, they are all "Developers" according to the Scrum Guide, but we don't have people that can help all items finish - (i.e. our QA Analysts cannot write code)
---
Also, do you all have any kind of vision or artifacts you all give them to show the multiple phases a team goes through before they reach the "Performing" level? Other than the usual radar graph team self-assessments that are out there, like SAFe's here: https://www.scaledagileframework.com/?ddownload=35424
Shouldn't a leader value empiricism and learning how to build the right thing at the right time, as opposed to “knocking out more work”?
Playing devil's advocate here for clarification...
I guess he's asking why should he care about those things when he is measured based on business value delivered.
In his mind, Widget X make us $4mm if it gets out in the next month, but only $2mm if we work on it in the 'delayed' sprint cadence where everything has to be refined, planned, then worked, etc. He is convinced that Kanban means 'devs can always work what's next and not have to wait' as there's no artificial sprint cadence/rules to mold work around. I don't have a spectacular answer for him, because he is fine dictating work directly, pushing people to work harder, ok with poor requirements (they will figure it out), etc.
he is fine dictating work directly, pushing people to work harder, ok with poor requirements (they will figure it out), etc.
Sounds like he is comfortable in a command & control role, which unfortunately isn't very compatible with Agile.
The benefit of working in Sprints is that the Development Team can make a forecast of completed work (increment) by the end of the time box that meets DoD. Your Director is apparently using other criteria to determine when something can be delivered. I would want the Director to explain what he is using instead of scrum to set his expectations. Personal opinion or "gut" feel is definitely not an Empirical approach.
I would also point him to the 8th Agile principle:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
How does a practice of "pushing people to work harder" align with the goal to maintain a consistent pace indefinitely?
Director's Assertions: Scrum isn't working. Devs are idle waiting on QA, Scrum teams can't handle ad-hoc requests that come up (he's frustrated that Devs could technically start doing more work but are refusing to pull in new items that cannot be 100% completed, so he feels they are wasting two or three days just waiting for testing to finish. He wants them to just take more work and them to stop saying 'It has to wait until the next sprint', etc).
This is fair criticism. If this is all true, this isn't Scrum's fault but rather the implementation of Scrum itself. Seems too much emphasis is on the Sprint output being the deliverable and the plan being perfect, and that's preventing the team from being successful.
- Why are folks idle and waiting on QA?
- What kind of ad-hoc requests can't the team handle?
- Sprint doesn't have to be 100% dedicated to Sprint Goal if regular responsibilities are known for this particular team.
- Where are the Sprint Goals? Are they transparent enough?
- Team shouldn't be afraid from starting the next most important work if the current Sprint Backlog items are complete or capacity was under committed, nor feel pressure that it must be done by the Sprint end.
- What level of Agile testing exists?
- Teams should have a sense of quality associated to the Acceptance Criteria. If I were implementing a story, I would not be able to call it "Done" and ready for integration testing if I haven't first performed basic tests for all Acceptance Criteria. It's the implementer's benefit to do these basic checks in order to confidently be ready to work on the next thing.
This is just a few thoughts off the top of my head but there are more questions around the effectiveness of the Product Owner and the Dev Team being able to achieve Agile principle of Simplicity, by being able to separate the "must do" from the "should do" when writing stories and building Sprint Goals.
What kind of game does he play? Short term, or long term? If we push developers to just work on new stuff all the time, how much time will pass till we wake up in "maintenance all the time world"?
Just because you can code more stuff does not help with value delivery if you can not test it and deliver to production without decreasing quality. What all of the players need to understand is that we do have limitations. If he is convinced to go for Kanban, then I would ensure that if we do this, it must be full Kanban without excuses and then, well... go for it.
- There still have to be some kind of WIP limits,
- There still have to be some kind of improvements,
- There still have to be some kind of items refining and ordering,
- There still have to be transparency, and the entire process (flow) probably will have to be transparent even more.
The point is, that it does not matter if you drop Scrum for the sake of Kanban, or the other way around. If you have a problem with working on your bottlenecks and limitations, then both approaches will make it transparent, but only you can resolve it. What you need to do is to embrace that fact and have the courage to act. Some people just need time to understand it after swimming in the same river a couple of times.
We've explained the need for the team to be more cross-functional and start swarming on testing (Devs should help QA out near end of sprint, instead of just being idle).
Forgot to mention this part too. Sometimes team need to swarm, that's fine. However, I want to suggest you try and identify what makes day 3 of the Sprint any different from the last day of the Sprint?
The goal isn't to create the perfect Sprint plan and achieve 100% completion. The goal is to be able to deliver a "Done" increment and demonstrate the functionality of the Sprint Goal so that the team can obtain feedback on it.
Instead of attempting to achieve predictability by accurately validating a plan, achieve predictable outcomes. Have the Sprint Goal successfully meet expectations and capitalize on each moment the team learns something as they complete some work.
Director says, 'I could just take two guys, put them on a tiger team and skip all this Scrum process and knock out more work than the 8 person scrum team does in the same amount of time'
Not long ago, I worked on two very lean teams. One in particular had five total team members (one non-technical client, one technical client, one Product Owner/Developer, one SME, one as-needed vendor SME). This team produced a Done increment every two to three days following the Scrum framework. We were constantly inspecting and adapting and actively practicing empiricism. Did we skip some Scrum events? Sure, we are human. So the Director in your example can run a Scrum team with three developers. No problem!
Devs are idle waiting on QA, Scrum teams can't handle ad-hoc requests that come up
How long are your Sprints? If they're two weeks and the Development Team can't negotiate with the Product Owner to add a Product Backlog Item, then maybe the Product Backlog Items haven't been refined enough. I'm also worried about your "QA" comment, but I will cover that next.
we don't have people that can help all items finish - (i.e. our QA Analysts cannot write code)
Scrum does a great job at exposing issues so that they can be fixed. This is a problem. I once had a client say something similar to me and I and others asked him why he didn't hire software engineers who could do development and test. Your developers should have multiple skills (develop, then test each others code). Consider pairing the testers with developers so they can learn new skills. They could take on repetitive, maintenance-based code. This will help the testers grow beyond testing and the team will grow with them. Self-organize.
show the multiple phases a team goes through before they reach the "Performing" level?
Is the team releasing Done increments through the Product Owner to the customer or end-user often? Is the customer satisfied? Are they more satisfied than they were a year ago (survey, conversation, poll)? Are they using your features more than they did in the past (usage)? Has sales converted more Leads to Opportunities to Close since the Scrum team started delivering more useful features based on customer feedback (metrics)?
Measure your Product, your customer's satisfaction and your ROI instead of focusing on the team performance.
At its core, Agile is about getting people out of their silos, talking to each other, to the business and to the customers. People talking to people to get work done. This is the social nature of human beings. If somebody blames this for bad productivity, they're looking for a scapegoat.
Amazing input and feedback you all. Thank you very much!
(Devs should help QA out near end of sprint, instead of just being idle)
Why only near end of sprint? If the highest priority item is now ready for testing, that item is not yet done. The team should not wait for the QA engineer to be available to do the testing, everyone within the team should be able to do the testing.
If we will only help our QAs near end of sprint, then there will always have that cycle that our QA will be drowning of items at one point in the sprint.
The QAs inside these teams should have the goal to influence and teach them how QA testing is done so that the developers can help as soon as the item is "Ready for Test". This could be in phases or stages before this can happen.