lassedesignen - Fotolia

Manage Learn to apply best practices and optimize your operations.

For scrum process, real change takes the long road

Many teams struggle with solid scrum processes. Take ALM to the next level with advice from QA and project management expert Matt Heusser.

Many software development teams find themselves stuck between the continuous deployment they'd like to grow into, the stodgy waterfall processes they grew out of, and the scrum process they claim to follow now. Being in the midst of scrum processes that face long-term change often leaves companies in a confusing position. Matt Heusser, principal consultant at Excelon Development, explains further. "If you go to an Agile conference, nine out of 10 people will say they do scrum … and they'll say, 'But…', or they'll say, '…ish', or they'll say, 'Yeah, we're not quite doing it right.'" Or they'll express in some other way that the system is failing," Heusser says in this podcast.

He goes on to postulate that maybe that's still an advantage over what the organization used to do. A part of the advantage of scrum, he points out, is "now these impediments become visible every two weeks, so they're on your mind more often." And the earlier a project manager can recognize an impediment and take care of it, the less effect that issue will have on the larger organization.

Matt HeusserMatt Heusser

But two week sprints don't just automatically happen; it takes adjustments to the organization's processes. Making real change in your ALM processes can ruffle a lot of egos near the top. After all, as Heusser points out, when scrum teams are self-organizing and self-directed, it doesn't leave a clear role for business analysts, which is a problem when the analysis department is well-established. "How do we change the organization in midflight?" Heusser asks, "How do we build the airplane while we're in the air?"

For small to midsize organizations, Heusser says, there's usually not a single view of all the work that's happening. Each manager has a list, each supervisor has a more detailed list and each individual has an even more detailed list. In such cases, organizations have two types of work: visible work and invisible work. The invisible work frequently causes delays. Heusser implies that if 30% of a team's work is invisible, you can guess they'll be about 30% late because they're only accounting for the visible work.

"A large organization is going to have a portfolio office," Heusser says, "and they're going to be able to visualize [the work]." A typical source of problems for these large organizations is building temporary project teams. A project is created and a team comes forth around that project. The team dissolves once the project is completed, and most people are on multiple projects and therefore multiple teams. "This leads to multitasking," Heusser says. "It leads to multiple bosses and all the stuff you saw on Office Space." Infighting and office politics find room to grow in this type of environment.

Heusser advises organizations to start with one major team that has all the skills the company needs and can be separated from the rest of development. In fact, he says that a core team usually already exists. "They may be distributed across a campus or distributed across the world, but that team is the heartbeat of the project. Every day that heartbeat is a day late, that project is a day late." And it usually reaches out beyond just application development. Any delay in that team causes massive delays.

So start with the scrum processes of just that one team, Heusser says. "Take all the work that one team was doing, put it in a bucket and visualize it. Make better choices around how to spend their time. Optimize that one team and the whole organization will see thousands or tens of thousands percent return on investment."

Next Steps

Learn about Agile ALM tools

Learn about ALM methodology

Take an Agile scrum approach to requirements

Read up on software development methodologies

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What are some common problems your enterprise has had with the SCRUM process?
The last organization i worked for was using SCRUM, and if I had to point at any one area that I found most frustrating about it, it was the fact that the development team was Agile/Scrum, but the test team was still a variant of waterfall. By contrast, the organization i am in now (while we use Kanban) has the testers involved at the earliest stages of story development. Having two worlds defeats the purpose of SCRUM, at least in my book.
You want problems with Scrum how about these?

Not planning back log items at least to some high level before sprint planning. (No release planning or Epic Planning)

Test teams and other down stream teams have to wait N+1 Sprints to integrate or perform testing.

Team cannot fully commit to any 1 project, because they have too many projects to handle.

Insufficient focus on training devs/testers in skills needed to really be able to do the cross functional work that is needed.

Dev/tester failing to try and learn skills to help keep product moving.

I'm sure there are many others.

Three big ones.

  • It's only effective for small teams, and sometimes we have more than a handful of people involved with a project. Some of those people are outside contractors.
  • It wants us face-to-face, when some employees actually work remotely. Not all of them by any means, but enough to make a difference.
  • We need more planning time, and SCRUM doesn't support that.
The SCRUM system isn't always bad, but... we don't use it anymore.
Scrum system is actually better for enhancement projects. I refer to applications that are already existing but undergoing enhancements. For such projects sprint planning cab be better, both dev and QA team will be confortable in following scrum.
in my experience, it isn't that SCRUM doesn't allow planning, its that heavy handed processes dictate more planning than may be necessary in many cases.  So many dev stories look like, figure out how, then do it... and often the first solution is good enough.
I don't believe all of these things are inherent to SCRUM itself, but here are some difficulties that my particular team had:

1. Finding the right amount of design to do while using SCRUM
2. We never, ever had one single sprint that did not get interrupted by something "important", and therefore...
3. There was absolutely no point in committing to a particular workload during a particular sprint, so we stopped.
4. Therefore, there was really no point in attempting to be a SCRUM team. We now use more of a Kanban method. 
Hey, Abuell, thanks for the feedback. Interruptions can be quite disruptive. Does a Kanban approach help keep the team from getting too far off track when "important" emergencies arise? Is it easy to get folks to understand when you say "We know x is important, but we have to finish y first before we get started on x." as opposed to saying "We have to wait for the gap between sprints before we insert x, no matter how important x is."? Or is it a case where it's just easier to work around the emergencies when you're not time-boxing the scheduled, "not important" work?
Saying Application Life Cycle Manage can help is a mouth full.  Many people think they need a one size does all tool.  Maybe we struggle with SCRUM because we as an organization that has problems with SCRUM does so because we do not fully embrace what it prescribes and build truly cross functional teams.  

Matt has a great talk called Save our Scrum that if you ever have a chance to catch covers a lot of these issues.  I'd highly recommend it.
There is more work to be done than just optimizing one team inside an organization whereas the optimization must be on a global scale.
Thanks for the feedback, I'll keep an eye out for Save our Scrum and maybe we can get it published in some form on the pages of SearchSoftwareQuality. @CCL, you're absolutely right! The title is a little misleading on this one, because we really only included the "how to get started" parts. This is just step one. We've got more from Matt coming soon. I think he suggests starting with just one team because it's manageable from a project perspective, so you can show the value of the changes this one team makes and then start spreading those lessons across the organization.
I'm pretty sure the whole "Start with one team" point he's giving here is in line with introducing the heavy paradigm shift in manageable stagered steps.

In a long term ALM you juggle many tasks that go from "forgettable" trivial to "fix now" urgent. You can gather a team charged with the tasks that are vital for you ALM, and set them in SCRUM. That way you get to add all the advantages of SCRUM to the portion of your ALM that is in need of fast and constant care.

Once THAT team is working well in SCRUM, you can start the teams charged with the next tier of tasks in it. Eventually, you'll reach the whole ALM.

I guess the point is that you don't really need to force SCRUM on those tasks that are so long term that 95% of meetings they only have two possible answers: "We're still on it, no major changes since last meeting", or "We'll put this one on hold to take care of something on this other one".
Focus your efforts into bringing a more agile management to the part of your ALM that can benefit from it NOW, bother with the rest when this segment has been fully integrated.
Yeah, we've definitely had those times when we're being agile/SCRUM but "not doing it quite right". I think that that's ok. A team's methodology is an evolving process, and it doesn't have to be all or nothing.

I have to completely disagree that a scrum team doesn't have a clear role for a business analyst, however - ours is amazing! I don't know what we'd do without him. His title is business analyst, but he might be more accurately termed a product owner, since he does have a true stake in the product requirements.