A Sudden and Sad Loss of a Partner and Friend

In a previous post, I announced the formation of a team, Scaled Agile Partners,  committed to extending and publishing the Scaled Agile Framework so that ALL teams and enterprises can leverage the benefits of agile development. Mauricio Zamora was a founding member of that team. He was also a great personal friend and trusted partner.

Mauricio died suddenly on Thanksgiving day. He leaves behind a wife, Pam, and son, Trey, aged nine.

Scaled Agile Partners, Oct 2011. From left to right, Colin O'Neill, Alex Yakyma, Dean Leffingwell, Drew Jemilo and Mauricio Zamora - (Died, November 24, 2011)

We all mourn the lost of this outstanding contributor and great human being. The world is not a better place today than it was last Thursday.

Mauricio had committed his next career to Scaled Agile Partners in order to help individuals, teams and enterprises enjoy the benefits of agile, including better outcomes for business, improved lives of users everywhere, and the basic humanity and just plain fun, that comes when individuals work on empowered, self-organizing agile teams − teams that get the results they deserve for all their hard work.

His passing reminds us that life is short, and therefore we must all make it meaningful. All the Scaled Agile Partners are committed to continuing this important work and building on the foundation that Mauricio has helped create. We will continue our work, but we will miss him terribly.

Advertisements

Update and Coming Webinar on the Scaled Agile Framework

As I announced in a previous blog entry , the Scaled Agile Framework further elaborates and refines the scaling practices described in my books Agile Software Requirements and Scaling Software Agility, as well as this blog.

As I work with my colleagues to elaborate and extend the framework and make it publicly available as a structured, interactive website, we’ve begun introducing it in different forums. Next week, Drew Jemilo will be presenting a webinar introduction to the framework as part of the European Agile Knowledge Hub webinar series. For details, see below

WHAT: The Scaled Agile Framework (SAF): Applying Lean-Agile to the Enterprise

WHEN: Tuesday, November 22nd, 2011, 9:00 PM – 10:00 PM CET

(I’ve translated times for you since the Agile Knowledge Hub is attended by professionals from around the world:)

9:00 PM – 10:00 PM CET (Berlin)
8:00 PM – 9:00 PM GMT (London)
2:00 PM – 3:00 PM CST (Chicago)
6:00 PM – 7:00 PM BRST (Rio de Janeiro)

You can read about the session on the Knowledge Hub Blog and sign up via GoTo Meeting.

Meanwhile, we are still on track for a private beta release of the framework in early December and our general release in late February.

You can find out more http://www.scaledagileframework.com. You can also sign up for news updates by entering your email address in the lower right of the home page there.

New Whitepaper: Agile and High Assurance

Finally.

For those who have been following the High Assurance and Regulated Environments series, I am pleased to announce the completion and publication of the whitepaper: Agile Software Development with Verification and Validation in High Assurance and Regulated Environments.

(Click on the image below to download a copy.)

This document was the result of a year-long research project and collaboration with a number of other experts in the field. I’d like to particularly thank Craig Langenfeld of Rally, who persistently moved the project forward and built all the examples, and Michael Messier, VP for Software R&D at Omnyx, who provided in-depth domain expertise and helpful reviews along the way.

Scaled Agile Framework – Hardening Iteration?

Things done well and with care, exempt themselves from fear.
— William Shakespeare

The hardening iteration in the Big Picture (and as I’ve described at length in Agile Software Requirements) has always been a source of fear, comfort, concern, (sometimes even loathing), and occasionally, all of the above combined. Emails in the form of “that isn’t agile, teams will use it as an excuse to defer technical debt”, and “big-company dummy, don’t you know you should be shippable every day”, and “of course you have to have it, when else can you do the final field testing we can’t do in our environment” and “anyone who doesn’t think you need a hardening sprint  has never worked on a really big software program” have found their ways into my inbox since the Big Picture was published. In any case, since the framework is nothing if not pragmatic, let’s consider the hardening sprint from three aspects.

  1. Stuff you must do, and probably can do only in hardening
  2. Stuff you should be doing earlier, but have to do in a hardening sprint for now
  3. Stuff you absolutely should have done earlier, and for which you are using the hardening sprint as a waterfall crutch

Let’s look at each of these individually.

Stuff you can probably only do in hardening

In many environments, there are a number of things that must be done, and can only be done (efficiently) during hardening. To name five:

  • Final exploratory and field testing
  • Validate solution against release, quality, and standards governance, and any marketing/sales/deployment/operations requirements
  • Develop deployment, installation documents
  • Create release deployment package
  • Create release communications

In addition, in high assurance environments, you’ll probably also have to finalize and “sign” product requirements and software specifications, and also finalize traceability artifacts and other documentation of quality as required by regulatory requirements or internal Quality Management Systems.

Stuff you should be doing earlier

In addition, especially in the first year or so of transition to agile, the hardening sprint may be used legitimately for a number of other things. These may include:

  • Final cross-component integration and/or integration with third party or customer components
  • Final, integrated, system level testing
  • Final System Quality requirements testing (testing nonfunctional requirements (NFRs) such as performance, reliability, accuracy, load, scalability, etc.)
  • Finalize localization across all required languages
  • Finalize user documentation

Stuff you absolutely should have done earlier

And finally (and hopefully only for those just transitioning to agile) , five examples of some of the stuff “you know better than to defer to the hardening sprint (don’t you?).”

  • Final system integration
  • Elimination of P1, P2 defects that remain
  • Automate remaining manual test scripts
  • Deferred regression testing
  • Update user documentation

Hardening Sprint Cadence and Summary

When it comes to cadence and length of the hardening sprints, while the Big Picture appears to indicate periodic hardening sprints just prior to program level PSI/release boundaries, the reality is a lot more flexible and (a little more complicated). But let’s state it clearly:

Agile Teams can place hardening sprints anywhere, if and when, they are needed.

So long as you are not “doing the stuff you should have done earlier,” and you are continually lightening the stuff in the  “should be doing earlier” pile, then you are increasingly agile and on the right track.