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)

Who’s Your Competition?

Bo Pelini is the head football coach at Nebraska. That first hyperlink is a bio that starts with, “It is about the process.” The phrase expresses a mindset for Bo, judging by how often the public has heard that message from him. Sportscasters say he tells the players that, “They are their own barometers.” Or, “They’re their own standard.” Or not to worry about the other team; if Nebraska players execute the plays right, the game results will take care of themselves. (That last one demonstrates considerable confidence in his coaching staff, eh?! He’s a leader to them, too!)

Is your mindset non-competitive? Do you compete with peers? Or with an idea?

My experience suggests non-competitive mindsets are the least common. We commonly teach aspiring members of our workforce that we and our organizations achieve more if we and they set goals and track progress toward achievement. The PMBOK® Guide devotes one of the largest of its five “Process Groups” to “Monitoring and Controlling”. At the start of each Sprint (or Iteration) in Scrum, teams set goals for the Sprint in a Sprint Backlog. At the end of each Sprint, teams focus for a time on what went well (so we’ll be more likely to do it again) and what didn’t go well (so we’ll be more likely to try something else). Maybe goals and competition with them are intrinsic parts of the human condition.

Some problems in our organizations relate to competition. On a sports team, two players at the same position “compete” for playing time and for approval of team, coaches, and fans. There are parallels in the workplace. It’s too common that people react with jealousy, sabotage, and other attributes and acts we’d rather not see in our organizations. (Or … in ourselves!)

At the same time, some benefit to our organizations relate to goal-setting. It is one way people notice when there’s a better way to complete a process; they consider (and sometimes choose) to improve that process. It is one way people widen the breadth of their thinking and base decisions on more information. (They avoid “rearranging the deck chairs on the Titanic”, or what some mathematicians call “suboptimization” or “local optimization”.) Goal-setting is one way to introduce a feedback loop into our decision processes. And each point this paragraph makes about people applies also to our organizations.

Is Bo Pelini competitive? It’s just my opinion, but I’ll say the veins sticking out on his neck after something doesn’t go Nebraska’s way is powerful evidence! I’ll say … he’s competitive.

I conclude Bo Pelini is teaching Nebraska football players to compete against an idea: the “perfect” game in which each player executes every plan as assigned and adapts as intended. Because Bo establishes that emphasis, players at each playing position focus on each other as teammates rather than as competitors; they work hard to develop the skills they contribute to the team. The players learn to think simultaneously at a position level (“Who am I supposed to block this play?”) and at a team level (“This play is supposed to achieve [I don’t know–a running back running the ball through a particular gap; whatever]; if the player I’m to block is out of the play for any reason, I’ll find another way to contribute to the larger goal.”)

I suspect Bo chooses this coaching mindset in part because it helps his players focus on cooperation with teammates and skills they contribute to the team. He believes teams work better when team members cooperate.

I suspect Bo feels the team is stronger if all players focus on doing all they can to help the team win. And avoid focus on comparing themselves to teammates. He seems to want them to feel that if they focus on being the best player they can be, the playing time will take care of itself.

I see parallels for those of us serving less visible teams than Nebraska football. My examples come, of course, from software engineering projects.

  • A clear and accepted team goal (say, completing the software tool a customer needs to implement their planned new business process) is valuable in helping team members make supporting decisions and independently adapt to unexpected conditions. It encourages initiative and free thinking. (Some in the U.S. military use the terms “Command Intent” or “Commander’s Intent“.)
  • Teamwork may be achievable, but it is more difficult if a team “knows” that two teammates want a promotion (or raise, bonus, or recognition award) only one can get. Maybe those two people sabotage each other. Maybe those two people are exemplars of good behavior, but teammates suspect otherwise.

NCAA Division I athletics (and software engineering projects) are tough enough without optional obstacles! I like Bo’s coaching mindset.

Hmmm … college athletics are supposed to be education, right?! Maybe they’re working beyond the teams! Thanks, Bo!