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.