Implementing Agile in Fortune 1000 Companies

[article]
Summary:
David Thach and Rick Rene share what they have learned are the most effective and readily adoptable agile processes, as well as a few techniques to integrate hybrid waterfall approaches. Companies adopt an agile software development framework to become more effective and more efficient, not to become a model of purist agile utopia—which, if attempted, ironically can be immensely costly and detrimental to progress, if not disastrous.

Through our combined forty years of experience consulting and running IT organizations in Fortune 1000 companies, we outline in this white paper what we have learned are the most effective and readily adoptable agile processes, as well as a few techniques to integrate hybrid waterfall approaches.

Companies adopt an agile software development framework to become more effective and more efficient, not to become a model of purist agile utopia—which, if attempted, ironically can be immensely costly and detrimental to progress, if not disastrous. A purist agile approach is not realistic for highly complicated Fortune 1000 companies that inherit unideal agile conditions. Teams with technical specialization, complicated reporting structures and governance committees, long-term roadmap planning and budgeting, conglomerate and subsidiaries in geographically dispersed locations, multiple shared product owners, mature legacy third-party installed applications, inherited roles absent in purist agile teams, a variety of IT vendors and partners with near-shore and off-shore blended workforces, and entrenched waterfall frameworks throughout hundreds of integrated applications are just a few Fortune 1000 company conditions that make it difficult to adopt agile.

As an example, one of our clients attempted to reconcile the Fortune 1000 conditions mentioned above with a full-on purist agile approach. This resulted in a fifty-six-page slide deck of prescribed instructions on implementing agile in their inherited Fortune 1000 environment that would also pass muster with all other stakeholders and their ancillary Fortune 1000 processes. It was complete with eight process flows, half-a-dozen swim lanes, and dozens of decision trees. They created this agile document after a year-and-a-half was spent gathering requirements in a waterfall-based approach. Their management, frustrated with the lack of progress, wanted to adopt what they heard was a new framework to push work forward more rapidly. However, the team ended up spending even more unproductive time creating the agile slide deck through countless discussions and approval rounds. And this was all before iteration 0 had even started.

In the end, they abandoned the fifty-six-page agile implementation slide deck, disbanded their attempts to socialize it, and instead called on us. In twelve weeks we not only implemented our simplified framework version of agile—what we are calling the “least common denominators” of agile—but we also developed the foundational components of their next-generation operational software.

As you can infer, there are aspects of agile principles that are more easily implemented in large, complex IT organizations that generate almost immediate benefits with very little relative disruption. These “least common denominators” of agile offer the biggest bang for the buck while being unintrusive enough to phase in at Fortune 1000 corporations. There are also hybrid waterfall and agile techniques that can be combined in order to gain the benefits of agile while both maintaining the benefits of the waterfall approach, which has been entrenched in the majority of Fortune 1000 companies, and enabling the framework to be more readily adoptable within these highly complex IT organizations.

Least Common Denominators of Agile
Agile is meant to be simple, but like all processes that start simply, it can quickly spiral out of control as layers are added and canonized in an attempt to standardize behavior. As a result, there have been tens of thousands of pages written about agile. But in this article, we are going to try to do the exact opposite and distill agile to its least common denominators. Agile can be broken down into three main process themes: artifacts, ceremonies, and engineering techniques.

Artifacts
The three key artifacts of agile are the product backlog, the iteration backlog, and the burn-down chart. Any individual team within a complex Fortune 1000 IT organization can adopt these artifacts by simply making a list of software requirements and to-dos (product backlog), breaking them into logical groups of work with estimates and assignments (iteration backlog), and tracking the work remaining (burn-down chart).

User Comments

5 comments
Robert Merrill's picture

"...being able to accurately estimate a budget and resources and establish a high-fidelity timeline."

I was surprised to read that accurate estimates and high-fidelity timelines are considered a benefit of Waterfall. We found estimation to be Waterfall's Achilles heel.


Our inability to make sufficiently accurate estimates (25%), quickly enough and at low enough cost to satisfy our customers, was the main reason we went agile 10 years ago.

I would love to hear more.

 

October 10, 2013 - 2:55pm
David Thach's picture

Hi Robert.  Thanks for your interest.  At Daugherty we have been implementing our unique, proprietary RPM requirements process at some of the largest Fortune 500 companies in the US. It's not just our process, but our talented people who repeatedly implement RPM at our clients sites that generates accurate estimates and timelines. Learn more about our case studies here: http://www.daugherty.com/casestudies/  

And, feel free to reach out to me directly if we can help your company with our agile transformation process. 

 

October 10, 2013 - 9:07pm
Ed Kelly's picture

I find several inaccuracies in your interpretation of Agile/Scrum that need to be addressed.  First, Agile/Scrum is not a process, it's a framework under which to build a quality product, including software.  Let's start with artifacts.

These should be accurately be called user stories, which are organized into a product backlog and team backlog.  There are no other artifacts required, although Agile does not exclude other valuable documentation like use cases and test cases.  Yes, the language of a story is prescribed because it is a time tested way to share requirements and elicit conversation.

The team or project burndown chart is a dynamic information source, not an artifact and should be reflected in story points rather than hours.  A burnup chart is even more effective.

Simply making a list of requirements circumvents one of the more valuable parts of Agile.  As Robert points out, estimating is one of the downfalls of waterfall.  By continuing this practice, you lose the concept of accuracy vs. precision.  As far as I know, no software organization has been able to estimate with precision weeks (or even days) in advance of the start of development.  By recognizing this, Agile uses the concept of Story Points which loose precision as the task gets larger and more complex.

Concerning ceremonies, you miss a critical one; the daily scrum or stand-up.  The whole point of Agile is to make course corrections immediately upon encountering a deviation from plan.  It is the reason that Agile works and waterfall doesn't except in environments that are guaranteed to be static.  If you can write requirements or a plan that will never change, by all means use waterfall.

Finally, regarding the scaling of Agile, you are trying to fit (excuse my overused metaphor) a square peg into a round hole.  With any change to the way an organization operates, change to the organizational structure is almost always required.  This applies to business productivity tools as well as business process changes.  To think otherwise is unrealistic.  I am in the middle of the "Agilization" of a software development organization of over 500 people in a Fortune 1000 company.  We recognized that the structure of the business and development organization must change as well as the relationship between them.  We are doing quite well.

 

If you need some objective evidence for the above assessment, please refer to "The Principals of Product Development Flow", by Donald Reinertsen.

October 16, 2013 - 3:03pm
David Thach's picture

Thank you Ed for taking the time to expressing your knowledge, experience, and opinions with agile.  We hoped that our article would hit a chord with practiioners out there to generate more discussions of this exacct natue. 

In fact if you get technical, even the user stories you mention are not required as the agile manifestio never mentions it. Neither does it mention burn up or burn down charts.  And, obviously our experience tells us that story points can be equally misleading.  I can also appreciate your distinction between acuracy vs precision as well as framework vs. process.  But, I think all of these "inaccuracies" reflect what we mentioned in our article as intolerant purist thinking and an attempt to over prescribe agile, which ironically is not the spirit of agile.  

Working wtih 500 people in a scaled environment, you can understand that not everyone in your organization will have the same opinion as you. And, a part of being a good agile coach and leader is to be tolerant of the ideas of those you coach in order to be effective in helping them become a better organization, not just insist your opinions or what you know is right. 

In the end our article is not about what is right or what is wrong.  Unfortunately we see too much energy in that unfruitful debate. Instead our article is about what, in our 40 years of combined experience running and leading IT organizations, have made our clients successfull. 

 

 

October 16, 2013 - 11:12pm
Rick Rene's picture

Robert/Ed,

Thanks for your comments.  I can tell you it was shocking to me as a huge Agile fan to see how many Fortune 500s were struggling with Agile adoption.  

When David started coaching teams and not doing it the way I had successfully done it with middle market companies, I was initially concerned.  However, he ended up being wildly successful where other coaches adhering to pure Agile methods were failing.  He listened and made small gradual changes without preaching and without trying to force my purist thinking on them.  Now he has converted 4 separate teams in being highly efficient Agile teams, but by migrating them slowly to the least common denominators.

His methods worked and proved to me to be far more effective in complex environment lide the Fortue 500.  In addition, I see Daugherty actually doing a great job at rapidly defining requirements that create a wonderful prioritized backlog that create the best of both worlds.  An actual estimate that our current funding methods normally require but not taking massive time up front to build them.  However, taking enough time to actually understand at least some gaurd rales on scope.  Just enough scope to get an relatively acruate estimate, but not rigid enough to eliminate the scope flexibility needed with the Agile process.

 

I now subscribe to a continues learning process on what works best for the more difficult fortune 500 Agile adoption.  My purist thinking is now being inspected frequently and adjusted to what is actually working at clients!  :-)

November 21, 2013 - 11:42pm

About the author

David Thach's picture David Thach

David is a Principal with Daugherty Business Solutions.  He has 14 years of IT consulting experience and is both PMP and CSM certified. Prior to his current role, David was an independant IT consultant for companies such as Hawaiian Airlines, Southwest Airlines, CBRE, and ADT.  David spent his career prior to this as a District IT Manager at the Federal Reserve Bank, an IT Program Manager at Ernst & Young, and an IT Management Consultant at Accenture.  A representative client list of his time at Ernst & Young and Accenture include:  Microsoft, Hilton Hotels, Blockbuster Videos, Verizon, AT&T, & Dynegy.

To learn more about implementing agile processes or conducting agile transformations at Fortune 1000 companies, feel free to contact David at: www.linkedin.com/in/davidthach/

About the author

Rick Rene's picture Rick Rene

Rick Rene is a Sr. Principal at Daugherty Business Solutions helping run and expand the Dallas office. He has CIO and CEO expereince and has passion for Program Management/PMOs, Mobility, Agile Application Development, Cloud Computing/Connected Devices and Social Media (over 8,000 followers discussing IT value).

Rick has a passion for technology and helping companies find ways to become more efficient and effective.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Nov 09
Nov 09
Apr 13
May 03