lassedesignen - Fotolia
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.
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."
Learn about Agile ALM tools
Learn about ALM methodology
Take an Agile scrum approach to requirements
Read up on software development methodologies