We have 5289 guests and 8 members online
Home > Articles > Current Edition > Agile Release Management Strategies

Agile Release Management Strategies

 E-mail
Wednesday, 14 September 2011 00:00
january-09-unsolvebigThis month, we share more great agile experiences for your reading pleasure. Brian Bozzuto discusses how you can really and honestly get to "done" without having to kid yourself. I really like his notion that "software is incredibly expensive inventory." Brian also says, "If something hurts, do it often." Read his article for much more wisdom.

Dele Sikuade continues his series examining the Agile Manifesto principles, this time looking at the third principle—what it means to deliver frequently. In "Five Steps to Creating Effective Contracts,"

Angela Druckman examines what it means to be agile while dealing with a regulatory agency and its audits. You don't need garlic and crosses—the auditors are not vampires; they are people too.

"Branching to Distraction," by Steve Berczuk, addresses the topic of when and when not to branch. I'm not a fan of branching, but there are times when it is necessary, and I appreciate having guidelines for when it's reasonable to do so.

Finally, to round out this issue, I have an article about release trains. Release trains have been around forever—OK, for at least twenty years—and they are one way to establish a rhythm for releasing even if you can't literally be agile.

I hope you enjoy this month's Agile Journal.

Johanna Rothman
Technical Editor
Agile Journal

 
Featured articles...

Getting to “Done”
by Brian Bozzuto 
Three of the Agile Manifesto’s twelve principles reference the value of producing working software. It directly names working software as the highest priority—a deliverable to be completed often and the primary measure of success. Scrum practitioners should note the goal of every single sprint is to complete “production ready” code. The point to teams is clear: Agile teams should endeavor to deliver working software capable of rapid deployment on a regular basis. The message to stakeholders is also clear: If you see it in a demo, you can quickly put it in your production environment. But, what happens if that’s not quite the case?

Read More >>
 

From One Expert to Another: George Dinwiddie
by Don Gray
I met George in the Software Development Forum when CompuServe was the way for technical people to communicate. Scrum hadn't been defined, and the Agile Manifesto wouldn't exist for another eight years. Based on his long-standing reputation in the agile community, I wanted to touch base with him and learn how he got started in agile, what he's observed about teams, and what makes a real team.

Read More >>
 

Agile Manifesto – The Truth Behind Those Principles
by Dele Sikuade
Product owners in large organizations seem to have everything: the talented workforce, thicker wallets, well-recognized brand value, and the infrastructure to turn a seemingly common-sense idea into a spectacular business. Yet, they struggle to find the next innovative product that will create new markets and ecosystems. Is there something wrong with them? What prevents them from functioning like product owners in start-up companies who quickly release new products in the market with lower budgets?

Read More >>

More articles...
Adapting Five Steps to Creating Effective Agile Contracts
by Angela Druckman

When organizations use agile practices they may find themselves conflicting with the existing project management processes.  When an agile approach is used for projects that touch outside entities, like consultants or partners, the issue grows even more complex. Organizations with heavy regulatory requirements face a similar challenge. Those just learning the agile frameworks may often ask, “How can we use Scrum and pass an audit?”

.Read More >>
 
Branching to Distraction
by Steve Berczuk 

Branching is a source code management technique for enabling parallel development. When you branch, you create a code line that is essentially a copy of its parent. By keeping track of the ancestry of the new code line, you can identify what has changed since the branch point and apply changes from the branch to the parent code line and vice versa. A branch allows you to work on a variation of the code without immediately affecting—or being affected by—changes on the main code line. (Streamed Lines has a detailed description of other reasons for branching.)

Read More >>
 
Not Ready for Agile? Start Your Journey with Release Trains
by Johanna Rothman 

A colleague was looking for a way to move toward agile but not really transition all the way. “I don’t think we’re ready for two- or three-week iterations,” he said. “We want to move a little more slowly than that. But, we do want to do something more agile than waterfall. And, we want to help our customers move toward taking more frequent releases. They aren’t ready to take a release every month, even if we were ready to release that often. Is there some sort of middle ground?”

Release trains are that middle ground. When you use release trains, you commit to yourself and your customers to release your product on a particular date every quarter. That’s the iteration.

Read More >>
 
 
 
 

 

 
Last Updated on Monday, 19 September 2011 13:22
 
Cialis

Agile Marketplace - Announcements and Special Offers

The Business Case for ALM Transformation
Are legacy systems holding your company back?  Breakthrough these technical constraints with an open and scalable environment that meets your unique business need to transform. There is no reason to be locked into an obsolete platform. The output of a number of recent transitions from legacy systems, this is practical white paper shares lessons learned and illustrates how guidance and enablement can pave the way for change.
Download this Whitepaper