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,