High Assurance Series Update

A few quick notes to those interested in the agile and high assurance and regulated environments series..

Whitepaper Update

A draft of our whitepaper Agile Software Development with Verification and Validation in High Assurance and Regulated Environments was made available to attendees at Agile 2011 the week before last. If you’d like a copy, please contact Craig Langenfeld at Rally Software (clangenfeld@rallydev.com). The final paper will be released in mid to late September. When it is, I’ll post a copy here.

Upcoming Webinar

Rally Software just announced a webinar on this very topic:

Agile in High Assurance and Regulated Environments: September 27th – EMEA 15:00 (GMT + 01:00), 10am ET / 7am PT
September 27th – Americas 1pm ET / 10am PT.

Craig and I, along with another industry expert, will be covering this topic in a one hour webinar. You can register here:

Upcoming AAMI report : Guidance on the use of agile practices in the development of medical device software.

A month or so back, Mike Russell sent me a draft of the upcoming AAMA (Association for the Advancement of Medical Instrumentation) Technical Information Report of the title above.

I reviewed the report and it is exceedingly well done. It provides a comprehensive view of adapting agile practices in the context of regulated medical device development, including an analysis of the impact on the company’s quality management system. Whether intended or not, it also provides a detailed look at high quality agile practices, so it can serve as a bit of a primer for those in the industry who are not familiar with Agile development.  I suspect this will be a pivot point in the movement to agile in this industry, as it is specific enough to provide excellent guidance for those making this transition.

Upcoming AAMI TIR

Mike notes that “the report is currently in the working draft stage, preceding the formal first committee draft, that is due out probably early September.”

Scaled Agility Framework for High Assurance Development

Finally, in prepping for the upcoming webinar, I put together this version of the Big Picture Scaled Agility Framework. The changes aren’t that significant, but they may be material (and perhaps helpful) to anyone following this blog series.

Draft of a High Assurance Scaled Agility Framework Diagram

Advertisements

Podcast: Building the Lean|Agile Enterprise

While I was thinking about my then-upcoming presentation entitled Five Keys to Building the Lean Agile Enterprise for Agile 2011, I was contacted by Joe Dager, owner of Business901, about doing a podcast on essentially the same topic. Joe did an excellent job of interviewing me and framing the discussion in pragmatic terms that are directly relevant to most every leader, manager and executive contemplating, or in the  midst of, a substantial Lean|Agile enterprise software transformation. A reader just pointed me to the podcast which is posted here. (The title, Lean Agile Software Train Description, is a little different, but the content is even broader than the Agile 2011 presentation.)

This is a pretty far ranging discussion, and on review, I thing it does a fair job of covering a number of critical topics, including:

➵Not Everything is a User Story: Scalable Agile Requirements
➵Think Agile Programs, Not Just Agile Teams: The Agile Release Train and Program Kickstart
➵Enterprise Systems Require Intentional Architecture: Rearchitecting with Flow
➵Portfolio Management Must be Agile Too: Addressing Legacy Mindsets and the Agile PMO
➵Your Enterprise Can Be No Leaner Than the Executives Thinking: Lean Education and The Big Picture

as well as a discussion of lessons learned in a number of larger scale transformations.

John Deere ISG Case Study: Reaching the Tipping Point

In an earlier post, we introduced the Agile transformation occurring at John Deere’s Intelligent Systems Group. In this post, we’ll describe some of the challenges and activities we encountered to get the development and management teams to the “agile tipping point” – the point at which we got the final green light for an “all in” Agile transformation.

Background: Earlier Pilots at ISG

In 2006, a few teams at ISG started experimenting with Agile development. Chad Holdorf and Steve Harty were two of the early adopters. Chad described it this way: “I remember being asked one day by Mano Mannoochahr, ISG Manager of Global Solutions Engineering, if I knew anything about Agile or Scrum. I replied ‘nope’.” Mano said, “Well then, it’s time you learned. I’d like you to lead the desktop teams (North America and India) and use Scrum.”

When asked about the change vector, Mano noted “the primary reason was to introduce the discipline of Agile –I just didn’t think our current process was producing the highest possible code quality. Plus with all the issues and product opportunities we were facing, we needed to increase the productivity of teams and the quality at the same time. Scrum gave us a way to get the whole team engaged more effectively towards that goal.”

Steve Harty, ISG Program Manager & (and now) Release Train Manager, commented:  “We knew we needed to increase our speed to market while keeping our budget and resources static. Moving our team to Scrum was scary, challenging, and liberating, all at the same time.  Scrum was ‘our little secret’ that helped move our delivery time timeframe from 12-18 months to 2-4 weeks. Plus, our engineering teams were happier and customer satisfaction went up.”

Based on this positive experience, an ISG Agile Transformation Team was formed to develop a plan to move forward with a much larger, and far more impactful, rollout.  Of course, as they did so many, many questions from important stakeholders started to appear.  For example:

1)   Is this an undisciplined process wherein we will lose control of requirements, system behavior and worse, the entire project?

2)   If we collocate testers with devs, what happens to the independent quality assurance function? Without requirements, how will we even know what we are supposed to test?

3)   What will engineering and test managers do if the teams are empowered and self-organizing?

4)   How will the factories react to our Agile plans? What about our continued need for long-term commitments to support new vehicle rollouts?

5)   What do architects do in agile? What happens to our architecture?

6)   Will software capitalization change, and if so, how?

7)   Will this even work with our Enterprise Product Delivery Process (stage-gated governance model)?

8)   What is all this write-the-test-first stuff anyway? That seems kinda stupid. And, are we going to have to do pair programming? What if we don’t want to?

9)   How do 10-20-30 or more Agile teams coordinate their activities? How can great solutions possibly emerge from all this potential entropy?

10)  How and who gets trained and what will the costs be to accomplish that? Who has the budget?

11)  How will long range portfolio planning work when the teams can change anything at any time?

12) Who will serve as ScrumMasters and what is a ScrumMaster anyway?

13) This Product Owner thing, who could we possibly empower to make such key decisions that affect our future?

14)  Will we suffer a loss of productivity during the transition? (“we can’t afford to go backwards now, not even one day….”)

15)  Does management really support this?

16)                  ……(editors note: we could do a whole post on this, but I tend to write too much anyway)………..

Clearly, there were more possible objections and objectors than we might have imagined. This was starting to look like a losing round of “agile objection whack-a-mole”. So working collaboratively, we organized our ongoing work in four threads.

#1 – Get management onboard and up to speed fast

As this was not “our first country fair”, we knew that we would never succeed without active support (and drive!) from middle and top management. So, in addition to a series of ad hoc informational meetings, we decided to educate them more formally as quickly as possible. After all, these are our leaders, so we resolved that they should lead, not follow, the transformation. (Note to a Scrum team: managers may be “chickens” to you, but to an enterprise, they are “pigs”, and big pigs indeed. Ignore them at your peril.) To this end, most managers participated in a two-day Lean|Agile Leadership Workshop we hosted. Workshop modules included Lean Thinking, Agile Orientation, Experiencing Scrum, Scaling Agile, Agile Technical Practices, and a final half day on Lean|Agile Leadership. This was a very successful series of trainings. We reached virtually all the managers in the R&D organization, as well as key stakeholders in marketing, product validation, factories, etc., in just a few short months. With that background, and an understanding of the potential business benefits, most of them came on board fairly quickly.

Lean|Agile Leadership Workshop. Reprinted with Permission of John Deere.

#2 – Establish groundswell and pull from the Dev Teams

Agile was developed by and for software developers and testers, but that doesn’t mean that all those who have never experienced Agile know what it is or necessarily think they want to do it. To that end, we did a significant amount of socializing with the team leads and first line development managers, looking, not only for support, but for a program that was ready to take the plunge. This was not a particularly difficult challenge, and it culminated at Agile 2010 over a dinner meeting, where we had the opportunity to discuss the challenges and opportunities face to face with a number of the Agile Transformation team members and various team leads.

Andy Beck, ISG Development Lead, Machine Controls, led the charge: “I always thought that Agile could be a great process, but until the conference, I had difficulty seeing how we could transform the John Deere waterfall methodology. After just a few days at the conference and that evening meal, the lights came on and the way was clear.  I knew that we needed to make a change in the culture at ISG and Agile had the potential to make a huge impact…if we could just get it started. Well then, might as well start with my teams.”

#3 – All In

Because ISG’s displays contain many millions of lines of code that had 200+ developers and tester working on it, we couldn’t only have half of the people on board. Joel Hergenreter, ISG Manager of Product Validation and Verification, noted, “Because our system was not well componentized, it would be difficult to implement Agile with a portion of our teams.  First, the merge strategy: how do we plan and continuously integrate if some teams are Agile and others are not in a tightly coupled system?  Second, once we implemented Agile on a few teams, others would want to jump on board quickly due to the strong cultural desire to deliver high quality products faster.  It would be impossible to say who wanted to make these types of improvements. We also knew that we would need more than Scrum to scale agile across the enterprise, so we adopted Dean Leffingwell’s Scaled Agile Delivery Model, which consists of a series of release “trains” operating on a common cadence.”

GreenstarTM 2630 Display, developed and produced by ISG. Reprinted with permission of John Deere.

Holdorf notes: “Once we agreed to add everyone to the train, we began drafting initial teams of 7 +/-2 that would work together until the 2630 launched. You wouldn’t believe how hard it was to just put people on ONE team and have then focus on ONE thing. People were so multiplexed it was painful and nearly impossible to understand the current situation or even write it all down, but we knew we needed teams to focus if we wanted to be successful”.

# 4- Establish a training plan and budget

Chad continues, “Because we were training so many people so quickly, we decided to train them all at once. I remember Dean asking me, ‘well, how big a room do you have, Chad? We’ll just stick ‘em all in it and just do it’.  We have a really big all employee room at ISG, so the game was on. Of course, we had to put together a budget for trainers and coaches, and that was not trivial, but at least we now had a plan to budget against (though I admit to being quite nervous about the scope and impact of even the initial training)”.

The Final Go Ahead

Eventually, we had enough support from all the key stakeholders, and a budget, so we were ready to forward. However, one small problem remained – we needed a program. One program – a display, controllers, guidance and documentation systems, and related software projects largely branded under the GreenstarTM label –was an obvious candidate. Plus, that’s where we had established the most pull from Andy and other development managers and teams. However, therein, another problem appeared – that program was in the throes of a waterfall-end-game-prerelease-firefight, with an immovable goal of a January 15 product launch.  It was then September of 2010. Could we launch such a major transformation at the tail end of a waterfall program? Will we make it worse? NO? Are we sure? Do the potential benefits outweigh the real risks?  Or should we simply wait until next year?

With the courage of its newfound Agile convictions, ISG eventually concluded to simply go, and GO now, on the Greenstar program.  At that time, with the support of his peers, Larry Clemens, (Manager, Program Management), stepped up and signaled the final go ahead. Clemens noted the angst present during the deliberation and how he came to the “GO” decision: “There comes a time in all major change initiatives when you have to stop piloting and just make the change within the organization.  We don’t have any programs that are not critical to experiment with, so these are never easy decisions. But the longer you wait, the later you receive the benefits”.

Summary

Now we had our program, a budget, a method, consultants and trainers, dev teams, a really big room, and a lot of (perhaps not unanimous?) management support. Now, it was our time to execute. How hard can that be? Hmmmm.

Next post: The All Aboard the GreenstarTM Release Train

Background on John Deere ISG

From the company’s job posting website:

John Deere Intelligent Solutions Group plays a key role for Deere & Company in designing and delivering the technology needed by their customers to help them meet the challenge of growing more food and building much-needed infrastructure – challenges that must be met as the world’s population is expected to grow to 9 billion people by 2050.  They’re a great place to work, too. With technology that utilizes satellite-based global-positioning, John Deere Intelligent Solutions Group designs displays and receivers, guidance systems, field and crop management, and information and logistics systems their customers rely on. They leverage Agile project methods to deliver the most advanced innovations to their products. They foster a creative environment where employees feel empowered to put their best ideas forward and forge their own career path.” (And yes, they have ping pong and foosball tables. Maybe a future post about office environment changes).

Jobs at John Deere ISG

Like every successful software business, Deere is always looking for talented people. If you are interested in a new career, building software with agility, and more importantly, helping address the challenges of feeding the world, contact Arneda Shelton and check out: www.johndeere.com/careers/

Agile 2011 Presentation: Five Keys to Building the Lean|Agile Enterprise

I’ll be speaking at Agile 2011 this week on Wednesday at 9 AM. The presentation is entitled: Scaling Software Agility: Advanced Practices for Large Enterprises. The presentation highlights five key elements necessary to build the truly lean|agile software enterprise. Here is the topical outline.

➵Not Everything is a User Story: Scalable Agile Requirements
➵Think Agile Programs, Not Just Agile Teams: The Agile Release Train and Program Kickstart
➵Enterprise Systems Require Intentional Architecture: Rearchitecting with Flow
➵Portfolio Management Must be Agile Too: Addressing Legacy Mindsets and the Agile PMO
➵Your Enterprise Can Be No Leaner Than the Executives Thinking: Lean Education and The Big Picture

You can download a copy of the presentation here:
Hope to see you there.

Agile Software Requirements is Available in eBook Format.

I’m happy to finally announce that Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, is again available in ebook form from InformIT.

With the purchase ($31.99 at this writing) you can download it in PDF and EPUB format. PDF files work just fine on Mac and PC, and the EPUB format is compatible with a number of mobile readers including iBooks on Ipad. This is the version I use as it provides adjustable fonts and decent navigation.

The watermarked PDF files are also compatible with the “Latest Generation” Kindle, 2nd Generation Kindle, or Kindle DX.

Note on the native Kindle ebook format: unfortunately, we are still working with Amazon to restore the native Kindle version. There were problems with the large graphics in the book which we are still attempting to resolve. In the meantime, however, there is a converter available at http://www.informit.com/store/ebook-formats/kindle.aspx which you can use to convert the EPUB or PDF files to a native Kindle format. (However, I haven’t tried it, as I gave up my Kindle for my Ipad sometime back).

HIgh Assurance Series Update

I haven’t posted much in this category lately as I’ve been busy drafting and redrafting the new whitepaper: Agile Software Development with Verification and Validation in High Assurance and Regulated Environments.

(Ok, I’ve been goofing off some, too.) But finally, Craig Langenfeld and I finished the final draft and it’s now in Rally’s hands for release. (Note: the body of the whitepaper is solely method guidance and is tool agnostic; but Craig has provided 8-10 screenshots of using Rally’s app in the Appendix. As I have mentioned, it’s foolish to attempt enterprise agility, much less high assurance agility, without proper tooling of some sort. Pick your vendor, but pick a competent tool).

I’d expect the whitepaper will be released by Rally next week at Agile 2011, and as soon as it is, I’ll post a copy here, too. I’ll be presenting at Agile 2011 on Wednesday, though not on this topic. My presentation topic will be Advanced Practices in Enterprise Agility: Five Keys to building the Lean|Agile Enterprise. I’ll post that briefing here this weekend.

In the meantime, those tooling high assurance will want to take a look at Craig’s latest post HIgh Assurance Agile Software Development Traceability Matrix Examples which illustrates traceability options inherent in a well formed, and tooled, requirements hierarchy.