Software Development

Adopting the scrum method for agile software development

Scrum is a project management approach for agile software development. Discover the 10 keys to successful scrum adoption, as identified by Construx Software.

Scrum is a project management approach for agile software development. Construx Software has helped numerous organizations adopt the core principles of scrum and adapt it based on their unique situations and challenges.

During Construx's consulting and training work with clients, the company identified 10 keys to successful scrum adoption, which are:

  • Evaluate scrum's suitability
  • Commit to core principles
  • Tailor the practices
  • Transform roles
  • Collaborate across disciplines
  • Balance perspectives
  • Invest in essentials
  • Steward the architecture
  • Deliver multiple aspects of value
  • Adapt with purpose

Read this Construx white paper for detailed information about each of these keys.

If your organization has already adopted scrum, please share your experiences and tips for successful adoption in the discussion.

Additional resources about scrum

About

Mary Weilage is a Senior Editor for CBS Interactive. She has worked for TechRepublic since 1999.

7 comments
kenr
kenr

Now before everyone starts flaming me, remember inside every large project that fails are a dozen small projects struggling to get out and succeed. Break up the large project into small projects and use Agile on them. A project of 6 months duration might fail, a project of 12 months duration will probably fail, a project of 18 months has already failed and is struggling to compensate. Unfortunately projects are to support or improve the real world, and no matter how much we'd like it to, it won't stay still. Have an architect (or architecture group) take the strategic view of the whole environment, and build the components using Agile. Just be aware that this will probably mean that some if not all of the early projects will have no visibility to end users (being building blocks for future projects) and be prepared for the struggle to get approval for those.

adams_john73
adams_john73

I'm responsible for budget reporting for large software projects for a fortune 500 company. We do $200 million annual in strategic projects and whether or not a project manager can capitalize the expenses and thus spread the costs over subsequent years is a huge issue that is often overlooked by PMs moving to an Agile method. If moving to Agile means that your project doesn't get funded - well - you might reconsider the move. Have your project accountant or finance contact familiarize you with FASB SOP 98-1 and related documents before switching to Agile for large projects.

mjf
mjf

kenr, good insight. A few questions: o Do you think it's the size of the large project or its duration (or both) that makes it less amenable to Agile/scrum? (Size and duration are closely related, but not equivalent.) o Isn't breaking a large project into smaller sub-projects a good practice regardless of approach (agile or otherwise)? o Any thoughts on techniques for managing the "main project" that is composed of many agile/scrum sub-projects? An uber-scrum? :)

SteveWhisenhant
SteveWhisenhant

My company is transitioning from waterfall (plan driven) methods to agile/scrum methods and the same questions about capitalization are being asked. In the past, strict rules about design artifacts completeness and approval were in place to satisfy external auditors. Now, we say the teams determine what level of design/documentation is required so that they can understand the user stories and deliver what the product owner says customers need. I see the original post was over a year ago, but no one replied to the original question... Is agile compatible with expense capitalization? If not, what is the expectation for meeting the "materially complete" moment when capitalization can begin?

Justin James
Justin James

It is also very difficult to track time spent on Agile projects, from what I can tell, depending on how they are managed. J.Ja

kenr
kenr

The bad news is that it's both size and duration that make it less amenable to Agile/Scrum. The cost of communications amongst a team is proportional to the square of the number of people involved, whereas the output of a team is proportional to the number of people. You can use tools to put a better multiplier in front of each of those, but unfortunately the proportional relationship remains the same. If you'll forgive the folksy truism, "you can't make a baby in one month by impregnating nine women", all you do is create a big problem in the future. Absolutely breaking a large project into smaller sub-projects is good practice. Unfortunately it is also one that is often ignored. There are all sorts of justifications for this, the "but this way we only need one approval" is one of the more common. I'm actually suggesting that you dispose of the main project, essentially turning it into a "strategic direction", and define the sub-projects so that they have short durations and useful outputs, even if those outputs are only useful to following projects. Empower and rely on your architect(s) to maintain the direction (and don't let them go "ivory tower" either - include them in small portions of the development work. It will help them establish their credentials with the developers and provide useful informal feedback mechanisms too). Also "reuse" developers from the building block sub-projects in following projects. They get to be the "experts" in that team (it never hurts to stroke a developers ego, if it's justified) and increase output because they really are the experts. I'd suggest monitoring of the sub-projects is deliverables based with only four states: "none", "started", "good enough for other projects to start using" (ie the dependency gate), and "done". Thoughts?

mjf
mjf

As usual, communication is (probably) the crux of the issue. Re. communications and the number of people involved. The cost is proportional to the square only if every worker has to separately communicate with every other. And, in some cases that must be done. In others, a broadcast makes it somewhat cheaper. But in general you're right...doubling the number of folks on a project more than doubles the communication costs. And unfortunately you're right about the "but this way we only need one approval" syndrome...ouch! I really like the idea of the strategic direction...the "vision thing" as Bush Sr. put it. I think that's important, regardless of any other techniques we use. That way everyone should be able to (okay, *might* be able to) see why things are aimed the way they are, and possibly make corrections when things aren't aimed where they should be. And we *must* depend on our subordinates, even to looking at them less as subordinates than as team players. I find that's a fine line to draw, but things work out best when that line is drawn/redrawn appropriately. Our developers aren't just coders, or just architects. They're problem solvers, yes? BTW, Tech Republic just notified me of your reply from 8 April (it's now 20 April).