Get certified - Transform your world of work today

Close

Scrambled Scrum

10 May 2016

Liz Lewinson
Agile Consulting Services


I was recently interviewed by eight different people for a coach role at a financial services firm. I had been given a bit of background: It was a top-down management decision to embark on using the Agile framework. A new group had started Agile in late January 2016, after training was given to both the designated Agile teams and related managers. They had created five teams working on the same release and were about to complete their second three-week-long sprint. They sensed they were running into trouble. 

During the eight individual interviews that were set up for me, each person I spoke with shared their concerns and I made a few suggestions, couched by the phrase, "I would have to sit with you and observe, but this might be an option." My outer comments were reserved, but my inner reactions were visceral.

I first spoke to a product owner. Prior to release planning, she was told by senior management that she must conduct all product regression testing for her team. Now, she said, this was taking up so much of her time that she did not have time to groom the product backlog or reach out to her stakeholders. The integration testing was not planned until the end of the third sprint. She said that the team was considering regression test automation, but that would be far off, not a priority.

Meanwhile, five product owners (one for each team) were going to every daily stand-up for each team. There was no Scrum of Scrums. The five teams were all having trouble deciding on how to write user stories. 

Notes to self:
  • OMG, this team is already dead in the water because the product owner can’t do her role, can’t energize the team. Her voice sounded so tired that this energy is probably conveyed to the rest of the team. 
  • Managers have assigned testing to the product owner as a mandatory activity. Not good — the team is not self-organizing.
  • The team has not had sufficient discussion around testing. It sounds risky to put integration testing at the end, close to the final release date. Why?
  • Why start with three-week sprints? That is not recommended practice. 
  • Five product owners at every daily stand-up? No Scrum of Scrums? This can be improved.
  • User stories — don’t know what the issue is but this is worth exploring.
I next spoke with a ScrumMaster (one of two). He was new to Agile and came from a Waterfall background. He said each of the five teams was made of up of four developers and one tester. Testing was already an issue because of the bottleneck with the product owner doing the regression tests. They were struggling with user stories.

Notes to self:
  • This person is catching the rough spots, even if he is not sure how to change them. 
Interview #3 was with a developer/team member. He had one point he strongly wanted to make: User stories were an issue on the team. He believed the user stories should contain all the lines of code of a complex algorithm they employ because this best explains their work. What else could a user story be?

Notes to self:
  • I will work with the team on user stories and the value of putting them in plain language understandable to managers, all stakeholders, and potential auditors.
  • They have been into this for almost six weeks, with five teams, and they have no agreement on user stories. What are they actually doing?
My fourth and fifth interviews were with an Agile manager and an enterprise methodologist. They asked me a lot of general questions about Agile. 

Notes to self:
  • If I get this job, it will be interesting to find out why they are asking me these questions. Are they just checking my knowledge, checking their knowledge, or picking my brains? I’m beginning to suspect the latter.
Interviews six and seven were with people introduced to me as lead developers. The first person seemed very anxious. Agile, he said, is not as good a system as Waterfall; they were better off before. They can barely get through one user story in one sprint. Agile, he opined, works better for front-end projects. A back-end project is not suited to Agile. The second lead developer told me they were still trying to kaizen the same thing after two team retrospectives, and there had been no change after six weeks. He said he is being expected to do twice the work that he had done before Agile, including handling production issues and training others. He was confused about user stories. He said the teams have been pressured to increase velocity right away. He said he doesn’t like Agile and that it is “socialism.”

Notes to self:
  • Help team understand why/how Scrum works well with back-end systems.
  • Look into the retrospectives.
  • Find out if the team is overcommitting.
  • Find out if ScrumMaster and product owner are removing impediments for the team.
  • Educate management about velocity.
  • Yup, check on user stories.
  • Agile is socialism??
Finally, I spoke with ScrumMaster #2, the person with the most training in Scrum. I found out that it was his idea to launch the brand-new teams with three-week sprints. He said he writes the user stories himself and uses Waterfall phases to slice the stories. He said the teams are not colocated and, even though he works with a number of team members locally, he does not use paper charts for information radiators, only Jira. He revealed that he controls the content in Jira and thinks they are doing well on testing. The new coach will report to him.

Notes to self:
  • OMG, source of trouble with user stories found.
  • Domination and control does not work on Agile teams and squelches collaboration (evidence: every person wanted to speak with me separately to air their concerns).
  • Gaining business value from the Agile framework is in a temporary sinkhole with this group.
                                                       *            *            *            *
The good news is that an Agile coach can slowly untangle all the issues, and some of this can probably be done fairly quickly. A few changes will make a big difference. A little bit scary — how did they get off to such a shaky start in the first place?

I felt bad after this set of interviews. Scrum works; scrambled Scrum does not.   

Did I get the job? No; they decided to wait for another coach they had spoken with who said she could join them in the next several months.
 

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 4.3 (6 ratings)

Comments

Peter Geiser, CSP,CSM,CSPO, 5/10/2016 10:48:51 AM
Nice article. There are many issues that are familiar. Did you have a chance to ask the managers why they wanted to implement Scrum in the first place?

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.

 

Newsletter Sign-Up

Subscribe