Agile Myths and Ideologies Meet the Scaled Agile Framework

I spent a thoroughly stimulating evening last week at a meeting of the Omaha Agile Development group. I have recommended their meetings before; that recommendation stands. They’re doing valuable and important work serving the Omaha business community and its members.

CSG International, with operations here in Omaha, decided some years ago to increase their agility. Last week, author Dean Leffingwell consulted with them in Omaha, intending to help them identify good next steps and to help them more sharply focus their end goal. (Experience seems to show that such assistance from highly qualified advisors is an indicator of succeeding in and of speeding such transitions. But you may not find that advice offered by a consultant to be entirely unbiased! (grin)) As long as Dean was in town …

Omaha Agile Development learned of Dean’s upcoming visit and invited him to speak to us. CSG opened its new facility near Dodge and 180th (two big, beautiful buildings, judging by what I saw). Something like 70 people attended. I am thankful to all involved. Well done.

I knew of Dean from having read his book Scaling Software Agility: Best Practices for Large Enterprises (ISBN 0-321-45819-2) on recommendation of a member of Omaha Agile Development. I, too, recommend the book. The earliest agile books concentrated their advice on small teams; this book is among those extending agile advice to “scale” (to collections of teams and potentially to large groups of contributors).

I used the title of Dean’s presentation for the title of this post: Agile Myths and Ideologies Meet the Scaled Agile Framework. Below, I share some of what I took from his presentation, along with (a little) background. This post is undoubtedly not a complete record of what he said.

Dean observed that at the time of Royce’s waterfall paper, waterfall was better than other alternatives available and he supports the industry decision then to use waterfall more. Had we known then what we know now about waterfall, agile, and technology development, we might well have best moved differently. We didn’t know that material; our work with waterfall and new technologies has educated us well. Agile is good guidance for change now. If we knew now what we’ll be saying about agile in 20 or 50 years, we might move differently now. Dean says he doesn’t know what we’ll be saying, so he advocates moving to agile. Our experience with agile will inform future changes.

This paragraph is background from me: I have observed some bias among agile writers to give voice almost exclusively to well-developed aspects of agile. (I exclude from consideration statements of “religion war” fervor we sometimes hear among agilists, like “<Their method> is only for people who can’t figure out <my method, the right method>.”) A blog appropriately titled, Is It Blasphemous To Criticize Agile, is well worded, shapes the issue well, and points to valuable other reading. On that subject …

Dean gives voice to both well- and under-developed aspects of agile. My opinion: he does it respectfully and in pursuit of finding a better way for all of us. His balance is refreshing.

He talked about his writing. These days, he says, most of his writing time goes to constant updates of his web site. It’s a rich set of material. It must be a key basis of his consulting practice. It’s free (the web site is free; probably not the consulting (snicker)). He calls the process he advocates “Scaled Agile Framework (SAFe)” (no surprise that it’s part of the title of his presentation!)

He built his presentation around seven myths. I wrote them down as:

  • Agile is all you need.
  • <Scrum> is all you need. [Substitute your favorite method for “Scrum”.]
  • XP is too extreme
  • Everything is a user story
  • Architecture emerges
  • Governance and PMO are bad words
  • Leadership and the problem in Chicken and Pig

Among the points he made during his discussion of the first three points: A key to “being agile” is exercising the judgment to assess what practices are right for one environment and using them. No one agile method is assuredly “right” or “wrong” for that environment; each of agile method has great suggestions he recommends each environment consider carefully. Scrum has no software engineering component. That’s neither “good” nor “bad”; it’s the way they built it. A software engineering environment using Scrum may need some software engineering advice (perhaps from XP, for instance). Some environments need all the practices of XP; the right people to decide that issue for each environment are people in that environment.

He referred to non-functional requirements as exceptions to the statement “Everything is a user story”. He referred to non-functional requirements much as IEEE does: “all the -ilities” (maintainability, modifiability, scalability, reliability, security, responsiveness, … there are many more that can be on this list; not all end with “ility”). He indicates agile processes cannot enable software teams to magically ignore these factors; he notes that many agile books don’t mention non-functional requirements. That probably derives from early agile literature aiming at small teams, where very informal approaches to these concerns can be effective. He indicates that as we scale agile, those very informal approaches cannot work. By the same token, it is not possible to write one user story that “completes” any one of these (“security”, for instance). Nor is it likely to be possible to do all work for any one of these within a single iteration. He recommends that teams document non-functional requirements as constraints on the product backlog and review each of those applicable during each product demonstration (that is, each iteration). That periodic review will help keep the non-functional issues alive for everyone and increase chance of success.

For large teams, he doubts it is best to assert that “Architecture Emerges”. Maybe it works for small teams or small numbers of small teams with rich inter-team communication. For him and for larger numbers of teams, the chance of success for the enterprise is too low to depend on the collection of teams to create architecture. They’ll each work largely on local motivations; the enterprise needs a wider view. At scale, he advocates a structure to create an enterprise architecture. It could be a domain architect (or team) writing for all teams. It could be a group with representation from all teams. Other options are possible.

He showed “Eight Principles of Agile Architecture”; they weren’t on the screen long enough for me to capture them. If I remember right, they were the same eight as he discusses just before the halfway point (judging by my vertical scroll bar) in his discussion System Architect Abstract.

He doesn’t feel “Governance and PMO are bad words”. He defined IT governance informally as the things IT executives do to assure IT is fully consistent and supportive of corporate strategies and objectives. He defined PMOs informally as groups of people who understand lots of organizational context and who advise and motivate others to adopt processes most likely to contribute to organizational success. He sees no question that IT needs IT governance as he defined it; he observed PMOs have done lots of the work in some organizations making agile values mainstream.

He doesn’t find the “Chicken and the Pig” analogy useful. As we scale agile practices, we need committed support and contribution from all levels of the chain of command; they all have roles. We don’t help anything by telling anyone they’re “not committed” or “not as committed as I am”. We have no adversaries.

Smaller points he made informally:

  • Don Reinertson’s book The Principles of Product Development Flow (ISBN 978-1935401001) is a great read. It’s difficult to read because it is so profound, but it’s short, too. [Well … he said it’s around 180 pages; some online descriptions indicate it is 300 pages.]
  • Lean has important lessons for us. Your customer is whoever (or whatever) consumes your work; don’t inconvenience them! Lean is a great structure for management to use in working with agile teams.
  • Kaisen: there’s no direct translation. A good translation is, “We can do better.” That’s always true.
  • His least favorite iteration length is 3 weeks. Both 2 weeks and 4 weeks are preferable iteration lengths.
  • Q: Is there a maximum size of a program? A: Dunbar’s number is probably a guide. This is the number of people one person can keep track of in their professional environment. It’s something like 80 to 150. Beyond that, it’s too hard to maintain cohesion in the program.
  • Part of the reason he writes so much is that it helps him understand better.

I hope my taking the time to write this out helps anyone who did not attend get some of the value. Writing it helped me understand better! (grin)

Feedback

In many areas of my past study, feedback is considered good; I consider it important to software engineering life-cycles. I’ll give a definition useful for us here. I’ll mention several examples of feedback in modern life and I’ll apply those thoughts to software engineering life-cycles.

Feedback Defined

Let’s use this definition: feedback in a process flow occurs when a process influences a preceding process.

a process flow with two processes and one arrow; the arrow points from "Build Product" to "Sell Product",
Figure 1. A process flow: “Build Product” is a predecessor to and affects “Sell Product”.

That begs for an example and a picture. At high aggregation, we might say a company that produces product has two processes: Build Product and Sell Product. As shown in Figure 1, the Build Product process is a predecessor of and influences the Sell Product process. (That makes sense: In many cases, producing product makes it easier to sell.) Figure 1 does not include feedback; Sell Product does not influence Build Product.

a diagram similar to Figure 1, but adding a second arrow, this one from "Sell Product" to "Build Product" in addition to the one from "Build Product" to "Sell Product"
Figure 2. A process diagram like Figure 1, except that it adds feedback. Each process is a predecessor to and affects the other process.

Figure 2 adds feedback; Sell Product and Build Product each is a predecessor to the other; each both influences and is influenced by the other.

The feedback might support fiscal constraints; the company might stop production when warehouse inventory gets above a threshold.

The feedback might support customer satisfaction; it might report the results of complaints received, reports of satisfaction, or suggestions for future development.

The concept of a feedback loop is closely related. Figure 1 demonstrates a linear process; it has no loops (or cycles). Figure 2 is an example of a feedback loop.

Corporate Governance

I have heard it said that in parts of the 1900’s, American manufacturing had a relatively easy time designing product that would sell well. A manufacturing organization in that position generates the greatest profit by producing as much product as possible at the lowest possible cost. If variation results in extra cost and doesn’t result in extra profit, they cut variation. Wikipedia describes a 1918 environment in which over half of all U.S. cars were Ford Model T’s. Their black paint dried fastest, which reduced cost on the assembly line. Henry Ford wrote in his autobiography about that time, “Any customer can have a car painted any color that he wants so long as it is black”.

Feedback works. Wikipedia goes on to indicate, “By 1926, flagging sales of the Model T finally convinced Henry to make a new model.” The flagging sales were feedback; by 1927 the company produced the Ford Model A.

Steering Response

A three-year-old recently reminded me in several ways about feedback. She was driving a light and slow electric car; I was jogging beside her interested in assuring her safety. (I’ve later wondered whether I was thinking at all when I put her behind that wheel! There are so many warnings I could have heeded at that time! But I did not …) I didn’t want to be “that” adult in her life, constantly controlling her vehicle; my preferred behavior was to let her do all the steering. (Note to self: you silly man!) I soon realized that she didn’t yet understand the concept of steering this car. She understands steering; she drives her tricycle. On the car, though she held the steering wheel correctly, she didn’t exert enough force on it to change the car’s direction. (In her defense, even truckers might not consider this steering system to be responsive!) Her lack of steering inputs was feedback leading me to take the car to a deserted section of parking lot. We did; she had a great time going either in straight lines or in repeating circles depending how I had most recently set the steering wheel. All was well.

I mentioned this was a three-year-old. After perhaps three minutes of this, she wanted to go to the playground then sometimes within her field of view. Her wish to go to the playground was feedback reminding me about three-year-olds’ tendency toward short attention span.

I set the steering wheel to a position I hoped would get her vehicle to the playground. The vehicle turned well past the direction I wanted. The excessive turn was feedback reminding me that driving a vehicle is an active control process. We cannot set the controls once and be done with it; we must repeatedly check results and adjust the controls again. We get close to one side of the lane, turn away from that side, get close to the lane center, and turn the opposite direction to stay close to the center; we repeat that process all the way to our destination. That process depends on receiving feedback that our vehicle is “close” to an edge or center of the lane. That three-year-old either wasn’t receiving the feedback or wasn’t acting on it.

(By the way, controlling an airplane involves double the inputs. We must start the roll, thus changing the angle of the wings make with the horizon; that’s bank angle. Then we must stop the roll and hold the desired bank angle to turn. Just before we get to our desired direction, we must start rolling toward level. When the wings are level, we must stop the roll. Yup. That’s four control inputs compared to a car’s two.)

Feedback in a Software Development Process

The August 1970 original paper on waterfall software development by Winston Royce mentions the importance of feedback. His Figure 3 shows the classic waterfall diagram also with all feedback flows pointing for each phase “uphill” to the prior phase; the caption is, “Hopefully, the iterative interaction between the various phases is confined to successive steps”. His Figure 4 and the accompanying text recognize the likelihood of detecting problems in testing that invalidate program design and, in turn, invalidate software requirements; the caption is, “Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps”. This paper is convincing evidence that we’ve known since the inception of waterfall processes that feedback is useful. And that feedback can be expensive.

The most interesting part of this discussion is deciding how this observation drives today’s software development.

The Agile models answer unanimously: Do a very small part of the project, show it to the customer, get feedback “early and often”, and repeat. Feedback is an important component of the Agile models.

For those of us not using Agile, a useful answer is to divide the project into a series of shorter efforts, each of which completes one development cycle. Perhaps doing more development cycles will make some methodology processes or products excessive; we might find we can streamline those excesses to everyone’s advantage. There is perhaps a reasonable minimum cycle time advised by Agile: one to four weeks; if your organization gets to that point, it has done lots of the change needed to do all of Agile.

This post reviews feedback; feedback is good. We use it in many activities of our lives; in some parts of our lives, we use it without noticing. It is a valuable part of all software development. May we all have and use lots of feedback in our software development!

Standard. Methodology.

Professions establish vocabularies. After achieving consensus about definitions, professionals can communicate more precisely and quickly. I offer some candidates to our professional consensus here on terms for software development projects. What would you change here?

Let’s agree with guidance from the American National Standards Institute (ANSI®), quoting a joint standard of the International Organization for Standardization (ISO®) and the International Electrotechnical Commission (IEC®), that a standard is, “A definition or format that has been approved by a recognized standards organization or is accepted as a de facto standard by the industry. (As defined in ISO/IEC Guide 2:2004)”.

I suggest we consider a methodology to be the specific set of training, development processes, tools, templates, and controls a particular software development team uses to structure its work. A methodology includes reference (as needed) to specific tools, communication channels, approval meetings (and lists of attendees appropriate for each), document templates, development languages, and responsibility assignments. Harold Kerzner used the phrase “forms, guidelines, templates, and checklists” during his May, 2007 Omaha presentation advocating effort to detect and document best practices.

There is power in the statement that by this definition, a methodology is a company standard, with corporate leadership taking the role of “recognized standards organization”. Following the lead of the ANSI guidance about standards, I focus here on industry standards.

That definition doesn’t specify that a methodology is documented. (This is the “you cannot not have a methodology” argument. You might not have a repeatable or consistent methodology…) As team sizes and project sizes grow, my impression is that few experienced professionals on either side of the waterfall/agile discussion would recommend no documentation of the methodology.

Many of the agility models (the Agile Manifesto®, in fact) advise caution about excessive documentation. I agree. I have seen methodologies that seemed to have everything “plus the kitchen sink” in them. They were hard to understand and so difficult to use that teams did only those parts that were well enforced. After some point of growth, it makes sense to require that for everything added, something must come out of the methodology. Simple is better. Focus is great!

Examples:

  • The Project Management Institute (PMI®) publishes the PMBOK® Guide as a standard. At one point in its history, many project managers considered it a standard because they accepted PMI as “a recognized standards organization” (from the definition above). I hope that’s still true today (grin). Many people outside PMI probably consider it more powerful today that ANSI listed the same document as a U.S. standard (ANSI/PMI 99-001-2008®) and that IEEE® listed the same document among its standards (IEEE Std 1490-2011®).
  • A company’s methodology is the collection of policies requiring particular practices (perhaps requirements to use particular templates for documents; perhaps requirement to use a particular inter-project corporate-level shared resource for change management or version control or lessons learned (or other); perhaps in a waterfall environment, requirement for a phase-end tollgate or phase review (or any of many similar terms); perhaps in a Scrum environment, a requirement to use a Daily Standup and a Product Backlog).

Non-examples:

  • No company’s methodology is an industry standard, if only because it depends on tools, databases, training, and past shared experience not available outside the company.
  • No standard is a methodology. (Ever read a job ad stipulating that successful applicants will “use PMI methodology”? At one level of precision, that sentence means little!)
  • “Agile” and “agility” are not methodologies. (Recently I heard Susan Courtney (of Nebraska Blue; Apr 2012 AIM Institute Technology Leader of the Year) forcefully and committedly advocate agility and suggest (about software development life cycles, SDLC) that companies don’t understand agility if they want to “implement a new SDLC called ‘Agile'”. I agree with her; a company needs to change more than the SDLC to increase agility. Agility depends on a wider and deeper partnership than that. And provides more benefits than just an SDLC change.)

Between the concepts of standard and methodology is a set of guidance generally not as accepted as a standard or not as specific as a methodology; some call this group models or methods or frameworks or processes. There is considerable variety in the terms used (example). Let’s use model here, though it’s not a perfect label for this group.

Models help us select methodologies. Though the following is a (very!) partial list, examples include:

  • The original paper about waterfall. In my experience, it’s very common to hear reference to “the waterfall model”. (Interestingly, Royce didn’t use the word waterfall, though his central diagram clearly resembles a waterfall. This paper makes a strong point about the need for adequate documentation in a software development effort.)
  • Mary and Tom Poppendieck’s 2003 book, Lean Software Development, An Agile Toolkit (ISBN 0-321-15078-3). (This is a valuable contribution to software development thought and arguably had the most pivotal early impact in associating the concepts of Lean manufacturing with software development.)
  • The PMBOK Guide. (Though also a standard, it provides much of the detail typical of this middle group and allows considerable latitude in implementing company-specific details. Far more than not, agility models are consistent with the PMBOK Guide. The Fifth Edition of the PMBOK Guide is due out in 2012/2013; I’m betting agility models will have lots of impact on the new edition.)
  • The Scrum Alliance® summary of Scrum. (By the same token, I acknowledge the power to the statement, “That’s a standard! The Scrum Alliance is the “recognized standards organization”.)

How best can we make use of these concepts? Here’s one vote for our teams (maybe our companies; in the ideal world, teams have a role) using guidance from standards and models to define everything we need in our methodology (and not a bit more!) And applying the specificity that distinguishes a methodology from a standard.