“If you don’t know where you’re going, you’ll end up somewhere else."
- Yogi Berra

Over the years, many flavors of Agile have emerged: Scrum, Lean, Feature Driven Development (FDD), Agile Unified Process (AUP) and Extreme Programming just to name a few. These methods have numerous complementary and distinguishing features, but the gamut of choices can be confusing and disorienting - as if being told to choose the best from 31 flavors of ice cream.  Return on Investment (ROI) is important to me, so Lean must be the answer.  But wait, I also want to be agile with my business priorities so I’ll choose Scrum.  On the other hand AUP facilitates scaling, so... we are left wanting a simple question answered: “Which Agile method should I choose for my organization?”

I have found that one can view an organization at three levels: the Executive/Project Management Office (PMO), the Management/Project and the Development/Delivery.  While the organization typically (or hopefully) has aligned goals, each level has their own sub-goals, focus and deliverables.  A strategy-focused executive’s eyes will glaze over if you evangelize the virtues of Extreme Programming (XP) such as continuous integration; these technical details are so foreign to the executive that you might as well be discussing the virtues of object-oriented programming.  However, the executive will hungrily ask for more information and how fast can we get started if you describe creating greater shareholder value by removing waste and optimizing across the organization, i.e. Lean.

So, as Agile matures within organizations we find the question, “Which Agile method do we choose?” is revised to, “Which Agile METHODS do we choose?”  I have found that the various organizational levels align near perfectly with three specific Agile Methods: Lean, Scrum and Extreme Programming. In this article, we will look how to best align Lean, Scrum and XP across an organization.

The Organization As A System
Imagine on an episode of the T.V. show “House M.D.” the brilliant, but curmudgeonly, Dr. House sees a patient suffering from severe lower back pain.  She has suffered for years and gone to numerous doctors, but nothing has worked.  After a cursory glance, House asks her to stand up and attempts to balance a book on her head.  The book slides down to her left side and falls to the ground.  House tries again and the book once more slides down to her left side.  House stares at her and tersely says, “What you need are new shoes.”  “What?” she surprisingly asks.  “New shoes! Your left leg is slightly shorter than your right.  You need a lift added to your left shoe and then your back will be fine,” House states as he walks out of the office.  While the other doctors neglected to detect the cause of her pain, House again proved his reputation as an unparalleled diagnostician by looking at the whole system and relating her shorter leg to her back pain.  He performed “System Thinking” (Smith, 2007).

What is “System Thinking?”  Simply put, System Thinkers “view the world, including its organizations, from a broad perspective that includes structures, patterns and events, rather than just the events themselves” (McNamara, 2005).  Based upon System Theory, System Thinkers understand that “like a living body, an organization is best understood as a whole, rather than in parts.”  For example, breaking up an elephant doesn’t create a bunch of little elephants…just a mess (Smith, 2007).  The concept of an organization as a living organism inspires one to look at a company’s organizational levels not as mutually exclusive divisions, but rather as mutually dependent sections of the whole.  In following sections we’ll see why this view facilitates Agile successfully fitting across an organization, but first let’s look at a simplified breakdown of an organization into levels.

On the Level (Of An Organization)
A large corporation, or organization, over time typically migrates towards a leveled structure where employees are divided along either functional or corporate responsibilities.  I have witnessed both ends of the spectrum: small start-ups where everyone on equal footing wears most every hat and massive corporate entities where hats are individually distributed - line managers, functional heads, workgroup leaders and relationship managers just to name a few.  While every company differs, most people can relate to the following software product delivery focused corporate organizational levels and responsibilities (diagram 1.1):

Each level has distinct goals (where they want to be) and objectives (how they get there).  The executive focuses on the strategic corporate and shareholder level.  The project manager focuses on the team and product delivery level.  The developer focuses on the engineering and task delivery level.  Each group usually only has a superficial understanding of the levels outside of their own, with the middle-child project management the most universally aware.  For example, as a developer I once received the executive level defined corporate goals of “Client First: Foster Client Trust and Increase Client Value.”  I understood the goal, but as a developer I honestly had no clue on how to take action other than to keep it in the back of my mind – the corporate mantra didn’t directly apply to my developer level goals and objectives.  On the flip side, I once witnessed a newly promoted developer to project manager attempt to discuss with an executive that we needed to re-organize the directory structure in SVN (a source code control system).  The executive, so far removed from the hands-on development world simply stared blankly at the new project manager – the SVN re-organization didn’t directly apply to the executive level goals and objectives.  Remember that “talking in terms of the other person’s interests pays off for [everyone].”  As Dale Carnegie pointed out, Teddy Roosevelt “knew, as all leaders know, that the royal road to a person’s heart is to talk about what he or she treasures most” (Carnegie, 1981).

Having defined the three types of organizational levels, let’s move onto narrowing down the numerous Agile processes.

Choosing The Right Agile (Let The Right Agile In)
I often hear colleagues new to Agile proudly declare, “We’re now practicing Agile at my company” or “Our projects are now Agile projects.”  “Fantastic,” I usually reply, “What type of Agile did you go with?”  More often than not they answer, “Um, well, Agile.  There’s more that one?”  My answer: “Yes.  Yes, there certainly are.”

Agile, as stated in the seminal Manifesto for Agile Software Development, is a set of principles – a philosophy rather than a step-by-step process.  Heavyweight processes (Waterfall or SDLC) dominated the development world and were considered, well, heavy.  Managers soon began playing with the notion of doing more with less.  Over time, lightweight processes emerged that focused on collaboration, communication and adaptability.  Finally, in 2001, the Agile Manifesto crystallized the common philosophical concepts of now familiar Agile process – Scrum (1995), XP (1996) and DSDM (1995) to name a few – into a unified set of guidelines and statements.

However, this begs-the-question, “Which of the many Agile methods do we choose?”  While over time we may see several Agile processes fall-out of favor, for now we have many types to choose from each with unique characteristics and benefits.  Three Agile processes standout as ideally differentiating: Lean, Scrum and Extreme Programming (XP).  Let’s take a quick look at their key features (Lane, 2006):

As you can see, these three types of Agile processes each have unique strengths that compliment one another.   However, like any good superhero movie, the origin back-story usually gives us great insight into our hero’s motivation (if the robber hadn’t killed Peter Parker’s Uncle Ben, our superhero Spiderman would never have been born).  So, let’s take a quick look at the three Agile processes.

Lean
Lean originated within the Toyota production line as a way to remove waste, optimize across the organization, flow value from demand and focus on those who add value.  The success of Lean at Toyota led innovators such as Mary and Tom Poppendieck to begin applying Lean to software development.  They found that Lean, as a set of thinking tools rather than a distinct process, could greatly improve the efficiency of the software delivery lifecycle and help “shorten the time from problem recognition to software solution” (Poppendieck, 2002).

Lean development promotes seven key principles:

Lean thinking has been applied across a myriad of industries and has been found to regularly produce significant customer value add.  Let’s look at an interesting example with the recent decision by Spirit Airlines to begin charging $45 for carry-on overhead luggage (no charge for luggage that fits beneath the seat).  At first glance you might think this decision yet another airline tactic to penny-pinch the customer, but consider for a moment the three main concerns of a frequent flyer: speed, comfort and cost.  When the overhead bins are stuffed, the three main customer concerns are negatively affected.  First, the boarding and deplaning takes longer.  Reduced speed and greater cost emerges as an issue the longer the plane sits idle.  Second, customers need to check carry-on bags that don’t fit in the overhead bins.  Have you ever boarded a plane and found all the overhead bins were already full (try as you might to stuff your bag into that too small of a space)?  Finally, the plane weighs more.  It makes sense: more weight, more fuel, more cost.  Spirit’s lean decision to charge for carry-on baggage arguably creates greater customer value and choice.  As Spirit's Chief Operating Officer Ken McKenzie put it, "Bring less, pay less. It's simple" (Huffman, 2010).

Scrum
The Scrum process provides a simple framework that facilitates team organization and getting high-quality work without sacrificing productivity (Sutherland, 2007).  The name Scrum derives from the rugby term that refers to the “mechanism to restart the game after an infraction.  It is the general idea of a team huddling together to move the ball toward the goal” (Lane, 2006).  Like Lean, the concept of Scrum originated in the manufacturing world.  At the Easel Corporation in 1993, Jeff Sutherland first applied the Scrum concept to software development.  Finally, in 1995, Ken Schwaber and Jeff Sutherland formally introduced the Scrum process after analyzing common development processes and concluding that they were not suitable for empirical, unpredictable and unrepeatable processes (Coetzee, 2008).

Scrum focuses on team organization (ScrumMaster, Product Owner and Development Team) and practices (Daily Scrums, Sprints and Retrospectives).  Scrum has an interesting delineation between those committed to building and delivering software frequently (the “Pigs” – Product Owner & Development Team) and those interested in the project but not committed to delivery (the “Chickens” – Stakeholder & Managers).  The terms “Pigs” and “Chickens” comes from a classic joke on commitment, wonderfully illustrated below by Mike Vizdos and Tony Clark:

Extreme Programming (XP)
Extreme Programming, the most widely adopted Agile process in the US, is a “programmer-centric methodology that emphasizes technical practices to promote skillful development through frequent delivery of working software.  [Extreme Programming] got its name when its founder Kent Beck asked the question, ‘What would happen if we took each technique/practice and performed it to the extreme?  How would that affect the software process?’” (Lane, 2006)  For example, if code reviews and refactoring are a good idea, what happens if we go to the extreme and do continuous code reviews and refactoring?  Thus was born the four core practices XP (with an example of each):

XP contains a lot of similar Scrum practices with the engineering elements that Scrum is traditionally missing.

Aligning Agile Across an Organization (If the Shoe Fits…)
At this point, we’ve begun to see that the three organizational levels (Executive, Project Management and Development) align quite nicely with three specific Agile process (Lean, Scrum and XP), respectively.  While all of the Agile processes have commonality, their sweet spots are attuned to specific organizational levels: different “views” for different audiences.  Lean shines when applied to those with a strategic, organization and shareholder value focus: the Executive.  Scrum shines when applied to those with a team organization, management and project delivery focus: the Project Management.  Extreme Programming shines when applied to those with a development delivery and tactical focus: the Development.  Diagram 1.5 illustrates this concept.

Putting on our System Thinking caps for a moment (and never taking them off), we must remember to address the whole system and not individual parts.  Apply Agile across an organization and not at any one single organizational level else we risk organization goal misalignment and an increased chance of failure, or at least less successful than we could have been.

For Your Consideration
What about the technicalities of managing three Agile processes across an organization?  In other words, how do you actually make it work?  While that answer goes beyond the scope of this article, please consider the following as a potential guideline.

As we all know, companies’ culture and organizational breakdown can differ greatly.  At one financial company where I worked, the high-level Managing Directors often boasted that they could still code with the best of them.  The corporate focus leaned more towards a tactical mind-set, i.e. XP.  In other words, a company’s unique culture and organization will determine the appropriate Agile fit; whether applying Lean, Scrum and XP to the afore mentioned three organizational levels or a mixture of Agile process to the unique corporate tiers.  So remember two things: first, Agile promotes fluid and adaptable processes, thus you can practice the “Agile Way” of keeping what works and leaving out what doesn’t.  Second, always “System Think” and apply across the organization and not to a single part.

Final Thoughts
We can view an organization at three levels: the Executive/Project Management Office (PMO), the Management/Project and the Development/Delivery.  These levels, each with their own focus, goals and mind-sets, perfectly align with the sweet spots of three Agile processes: Lean, Scrum, and Extreme Programming.  By applying these three processes across the organizational levels (System Thinking – applying not just to a single organizational level), we increase our chance of adoption, productivity and general success.

I believe that we are on the verge of inventing a new way of looking at Agile: a maturation and simplification of Agile from numerous processes to a few or even one.  Perhaps even a new process might emerge that addresses the needs across an organization.  However, creating a new process will take significant fortitude and community accord.  As Albert Einstein noted, “Three Rules of Work: out of clutter find simplicity; from discord find harmony; in the middle of difficulty lies opportunity.”

Bibliography
Carnegie, D. (1981). How to Win Friends & Influence People. New York, NY: Pocket Books.

Coetzee, L. (2008, Oct 6). What is Scrum? Retrieved from Swat Blog: http://www.mihswat.com/2008/10/06/what-is-scrum/

Huffman, M. (2010, Apr 7). Spirit Airline Charges For Carry On Bags. Retrieved from Consumer Affairs: http://www.consumeraffairs.com/news04/2010/04/spirit_bags.html

Lane, R. C. (2006, Oct 17). A Practical Guide to Seven Agile Methodologies. Retrieved from devX: http://www.devx.com/architect/Article/32836

McNamara, C. (2005 Feb). Thinking About Organizations as Systems. From Free Management Library: http://managementhelp.org/org_thry/org_sytm.htm

Poppendieck, M. (2002). Principles of Lean Thinking. Retrieved from Lean Software Development: www.poppendieck.com/papers/LeanThinking.pdf

Smith, K. M. (2007 28-Sep). Understanding Your Organization as a System. From Ezine Articles: http://ezinearticles.com/?Understanding-Your-Organization-as-a-System&id=755700

Sutherland, J. (2007, Oct 14). The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process.

The Free Dictionary. (n.d.). Scrum. Retrieved from The Free Dictionary: http://www.thefreedictionary.com/scrum

Trackback(0)

TrackBack URI for this entry

Comments (2)

...
written by Mohamed Kishawy, May 13, 2012

The concept of the "agile across an Organization" is very interesting. Being flexible and applying only the tools that suit each level of the organization instead of sticking to one agile methodology seems the right way to go.
I wrote an article (inspired by this article) on what I called the "selective integration" of agile methodologies. Check it out at:
http://www.agilejournal.com/co...?task=view

• 
• +0
• 
• 

...
written by Udayan Banerjee, May 12, 2010

While deciding on what agile methods to use, I think it is important to understand the characteristics of the software project. For example, if you are creating the software for running the next generation of Boeing aircraft - your methodology would be quiet different from what you would do in a project for enhancing the company web site.

I think there are 5 distinct categories of software project and the approach to each one of them needs to be different - http://setandbma.wordpress.com...e-project/

• 
• +5
• 
• 

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview