Saying Goodbye to a Friend

Mauricio Gaston (“Mo”) Zamora’s (see post) memorial service and celebration of life was held Thursday at the United Methodist Church in Davidson, North Carolina. Mauricio died November 24 (Thanksgiving) while out running with his son Trey, age nine. He was 42.

Mauricio and Pam Zamora were very active in the local community and there were many hundreds of friends, family, church members, and soccer moms-dads-kids in attendance. Pam opened her house to guests thereafter and what a crush that was! (It looked like an entire soccer team was there, in uniform!)

Even though I knew Mo pretty well, I was indeed amazed to find out what an incredible Renaissance person Mo was. He was an accomplished guitarist (classical and electric), woodworker (built guitars and furniture), vinophile (has an amazing wine cellar and his own small vineyard on the property; was the resident wine expert in our partnership – at the reception, we drank only wine that he had made), photographer, soccer player (was invited to practice with a semipro team), soccer coach (see soccer scholarship program below), outdoorsman, scuba diver (his personal dream was to dive the great white sharks-I’m sure he was saving for that upcoming adventure), not to mention husband, father, brother, son, and entrepreneur, agilist and software industry executive.

Mo will be missed in so many ways and he leaves a void that will never be filled. With respect to this blog, and this industry, he was my good friend and partner, an accomplished enterprise agilist who was currently engaged in rolling out lean|agile transformation programs to a number of enterprises. Mauricio was passionate about the business results, the empowerment of self-organizing teams, and the intrinsic motivational and simple humanity benefits that agile can deliver. This was to be his next, full time, career. He’ll leave a void here, too, as now many hundreds of teams, programs, and ultimately, entire enterprises will now never be able to leverage his unique skills.

If we are going to any way make up for this loss to our industry, then we are all going to have to just pick it up a little bit, aren’t we?

For those who knew Mo or are otherwise interested, memorials may be made to:

North Meck Soccer Club, 11138 Treynorth Drive, Suite B, Cornelius, NC 28031 or Davidson United Methodist Church MC, PO Box 718, Davidson, NC 28036. I talked to one of the Meck club coaches and he said that any funds received will be used for a “Mauricio Zamora Scholarship” which will be used to help aspiring youth-athletes participate in a program that they could otherwise not afford (priced a kids soccer uniform lately?). I can just imagine the mental and physical benefits such a scholarship will bring to some number of lucky kids.

Rest in Peace Mo. You will always be missed.

Advertisements

Lean|Agile Leadership Workshop in Wellington, NZ 28/29 Feb, 2012

I’ll be holding a rare, open-enrollment version of my Lean|Agile Leadership Workshop in Wellington, NZ on 28/29 February 2012. It will be hosted by Assurity, a Rally-enabled partner. You can register by emailing training@assurity.co.nz.

Here’s the flyer that Assurity is using to promote the workshop.

Assurity Lean Agile Workshop Description

I’ll also be holding the workshop in Sydney (7/8 Feb) and Melbourne (14/15 Feb). You can register for these workshops at Agile University.

(Since its summer then, maybe some of you colder-climate-bound folks will come down to play in the sun and also attend the workshop? We’ll be serving tea!)

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.

Agile Software Requirements is Now Available in Native Kindle Format

Well, after more emails than I care to think about, and after being tempted to give up on the entire concept, Agile Software Requirements: Lean Requirements Practices for Team, Programs, and the Enterprise is now (again) available in native Kindle format from Amazon.

Order native Kindle format from Amazon

Thanks to Chris Guzikowski, the Addison-Wesley team and Amazon for finally making this happen.

Of course, it is also available in Ebook format from InformIT.

 

The Big Picture is now the Scaled Agile Framework

OK, additional feedback drives me to make yet-another-minor-change to the Big Picture (sorry!). I’ve renamed it (hopefully for the last time) to be the “Scaled Agile Framework” (SAF for short). I’ve also tweaked the product owner and scrum master icons for better graphic discrimination. The latest is below:

Scaled Agile Framework Big Picture

Also, a number of us will be working to further elaborate this framework in web form over the next few months. If you are scaling agile in your enterprise, you might want to stay tuned to this blog for a while, as we’ll be pushing quite a bit more content out this fall.

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).

2010 SSA Blog Stats – Year in Review

Hi,

This year end summary of Scaling Software Agility blog stats from wordpress might be interesting to some…. (or it might not!)

-Dean

=============================================

The stats helper monkeys at WordPress.com mulled over how this blog did in 2010, and here’s a high level summary of its overall blog health:

Healthy blog!

The Blog-Health-o-Meter™ reads Wow.

Crunchy numbers

Featured image

The Louvre Museum has 8.5 million visitors per year. This blog was viewed about 88,000 times in 2010. If it were an exhibit at The Louvre Museum, (Dean’s personal  note: yeah, interesting little market blurb, but that’s pretty unlikely!) it would take 4 days for that many people to see it.

In 2010, there were 37 new posts, growing the total archive of this blog to 224 posts. There were 68 pictures uploaded, taking up a total of 57mb. That’s about 1 pictures per week.

The busiest day of the year was November 29th with 573 views. The most popular post that day was Software Verification and Validation in High Assurance Agile Development: Definitions.

Where did they come from?

The top referring sites in 2010 were Google Reader, leffingwell.org, en.wordpress.com, agileproductowner.com, and twitter.com.

Some visitors came searching, mostly for product roadmap, product management, release management, release planning, and product owner.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

1

Software Verification and Validation in High Assurance Agile Development: Definitions November 2010
4 comments

2

Agile Software Requirements (the book) November 2009
19 comments

3

Agile Product Manager in the Enterprise (5): Responsibility 3 – Maintain the Product Roadmap June 2009
2 comments

4

Agile Product Manager in the Enterprise (2): A Contemporary Framework May 2009
5 comments

5

Enterprise Agility-The Big Picture (8): The Roadmap August 2008
4 comments