4

I suspect that the problems on Scrum teams in my current organization supersede this one aspect, but wanted to focus the question more specifically to how Scrum can be done better than it is currently being done.

We are a new organization to Agile/Scrum and have many challenges. We are horizontally stratified to the point of sheer lunacy where nearly every aspect of software and technology has been provided through some external enterprise platform team that monopolizes an incredibly specific aspect of an overall software system (Eg. ESB team, Reporting team, DBA team, Scheduled Tasks Team, Business Events Notification, etc...)

Our project is a hub of sorts with an absurd number of external interfaces spiderwebbing into and out of our software that we are trying to deliver. We have many many many layers of abstraction from business and operations, to operation business analysts, to Product Owner, to business systems analysts that define detailed functional requirements in the form of user stories and acceptance criteria.

This project has a big budget so they formed off two scrum teams but to my extremely vocal objections the decision by the scrum master was to horizontally segregate the two scrum teams such that one scrum team deliver on user stories for stakeholders while the other scrum team delivers on more technical and interface stories in a digestable form for the other scrum team. My unheeded objections were that a user story should be a full vertical slice otherwise we harm our ability to be cross functional. The argument against mine is that even the simplest most atomized slice of business value could not be delivered in a two week sprint because of the obscene amount of external dependencies any one story calls for. Instead the second team works ahead of the user story team.

This is all failing miserably in practice, but despite all of this the bigger problem still is that our backlog grooming and sprint planning sessions take 8+ hours to complete.

Our scrum master insists that we cannot end the meeting until enough stories are ready for the next sprint, no matter what. Most of the stories just aren't ready in terms of requirements I feel to where the user story is clear and the acceptance criteria makes sense. I am constantly trying to stifle extended deep dive technical discussions that technical folks in the room insist on talking to death about but usually I just give up after a while and let them talk through whatever anxieties they have.

Originally I tried taking a hard stance in the meetings and calling the story Not Ready and moving back to Backlog, however I was being lectured from the frustrated Product Owner that we are failing to bring anything useful at all into the next sprint.

Next I tried to call for a return to Sprint Zero because we just aren't ready to work on anything yet. It is clear the Scrum Team needs more guidance on requirements and high level design, and being as I am responsible for system architecture, I agree that we are moving too fast for me to give the level of design detail that the technical folks feel they need to work on a story. I try to make up for this by being completely available for questions or concerns during the sprint but it doesn't ease the anxiety that the team feels about the impending public humiliation that comes when they are in standup and have to admit that they don't know what to do and that their story is at risk yet again. My call for Sprint Zero is unheeded by the Scrum Master who insists that we are not going to meet our strict regulatory deadlines of minimum scope if we "waste time" in Sprint Zero. It is a completely immutable position that he refuses to step down from.

So our Backlog grooming and Sprint planning has devolved into 8+ hr sessions where we essentially try our best to piece together requirements and design details for each story, and where discussions can go in excess of 45 minutes on each story.

This whole experience has me wondering if Scrum just doesn't scale to large projects in practice.

What else can I do as a technical architect to help pull the project out of this vicious death spiral it found itself in? How can I help the team get to a point where we can groom, slice and size a story in less than 10 minutes?

Improve this question
1
  • 1
    Separate backlog grooming from sprint planning.Allow only fully defined stuff go to sprint planning. Make sprint planning strictly time boxed. Be realistic, estimate the complexity and make multiple grooming sessions when needed.
    – Thinkeye
    Aug 16, 2018 at 12:16

3 Answers 3

Reset to default
4

Our scrum master insists that we cannot end the meeting until enough stories are ready for the next sprint, no matter what. Most of the stories just aren't ready in terms of requirements

Your scrum master isn't doing their job and this may be a discussion that you need to have with them (tactfully and in private) to see whether they're willing to change their approach.

Sprint Planning sessions must be time-boxed to prevent exactly this from happening. No one should be more pedantic about time-boxing these meetings than the scrum master.

Basically all documentation on Scrum will back you up here (for example : http://www.scrumguides.org/scrum-guide.html#events-planning )

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.

The sessions are going so long because they're allowed to go that long. Time-box the session and the team will soon learn to be more productive / less detailed due to necessity. This is why time-boxing works - it makes time a non-negotiable so other things have to be negotiated (eg depth of discussion, definition of ready, general grooming process).

Improve this answer
6
  • Thanks for the input. I think there are competing priorities at play. He is also the project manager responsible for the overall success of the project. His priority as a PM is to make sure that we are not letting our expensive onshore contractors go under utilized. Furthermore this is why he insists on micromanaging hourly tasks to make sure that everybody is at capacity. The more I think about it the more I realize he acts more like a micro managing PM than a scrum master. He tracks velocity, but this metric is useless if he still insists on measuring our delivery on hourly tasks.
    – maple_shaft
    Oct 14, 2015 at 1:19
  • 1
    Ahh, that makes sense. It'd still be worth having a conversation with him and letting him know that, by restricting flow and trying to force team dynamics, he's creating a team that a) can't work without him (no sick leave, no holidays for him!) and b) is not as efficient as it could be. Time-boxing planning may lead to initial friction and underutilisation, but it will quickly correct itself out of necessity. There is NOTHING efficient about trapping a team in a room for an 8+hr meeting.
    – mwan
    Oct 14, 2015 at 1:59
  • 1
    It sounds like your SM is a very long way from understanding how to run a Scrum process. Their attitude seems to be command and control, and the interest in managing hourly tasks shows he doesn't trust the team. I would caution that you will have a very long way to go with this individual to improve the process and in my experience not everyone can make that change. Do what you can, but perhaps consider a more extreme alternative of moving teams/companies?
    – Robin
    Oct 14, 2015 at 8:31
  • @Robin I used to be under his sprint team and was pretty miserable until I was recently promoted. I am now more like a technical stakeholder and an arm of the PO. He is kind of cold to me lately, maybe he doesn't like not having control over me anymore. I think I am just trying to bring more technical design clarity into the conversation so that we aren't anxious about HOW we will implement during these meetings.
    – maple_shaft
    Oct 14, 2015 at 10:56
  • Backlog refinement (not planning), under Scrum.Org guidelines is timeboxed at 10% of the total sprint so 8 hours for a full refinement seems within the guide. However Mike Cohn and the Scrum Alliance take a slightly different tact regarding refinement.
    – Venture2099
    Oct 16, 2015 at 8:31
2

You may need a new Scrum Master, because your supervises the team not mentors and challenges. You can also try to move him from supervision to mentorship. That would be a great help to your team.

As a technical architect you take the technical mentoring role and improve your team to be better at software development. You can do it officially by asking for time from SM, or unofficially by going around, see who needs help, and help: pair programming, small discussions around technology and architecture, and give brown bag talks.

The planning meetings are usually long because

  • team members are on different technological levels
  • team members are on different domain know how levels
  • team members know less about anything

As a technical architect you can reduce the first by education. If there are no more technical discussions on the planning meeting, the can focus on the domain, and with time, they'll finish earlier.

Unfortunately, there is no snake oil for "groom, slice and size a story in less than 10 minutes". It takes time, a lot of mentoring effort, management support, patients, and team that stays the same. Assuming these are present and based on my experience, you may see a reduction in planning meeting time after 5-6 sprints.

Improve this answer
1

It looks like you've done a lot of thinking about the problems and potential sources, but have you considered rounding everyone up and doing a root-cause analysis? Given your info, I would guess that even the initial step of framing the current problems will generate a lot of interesting conversation and expose alignment issues around what it means to be agile, whether you are truly following Scrum tenets, etc.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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