Disciplined Agile

Mark Lines and I edited a special issue of the Cutter Business Journal in 2018 entitled A Disciplined Agile Approach to Business Agility which can be downloaded free of charge.  It contains several articles.

Itamae, the Agile Organization, and You by John Hogan

Hogan shares some insights on delighting customers. He argues for a customer-focused organizational structure, with Agile teams supported by Agile leadership. Hogan describes the importance of goal setting to focus on delighting customers, supported by incremental planning and delivery to do so. He works through the implications for:

1. People who face the customer. These people need to understand what customers need and then fulfill that need.
2. People who face each other. They need to identify their internal customers, collaborate with them, and bring business value to them at the lowest possible cost.
3. People who face suppliers. These people are effectively customers to that supplier and must collaborate with them as transparently as possible and should expect to be delighted.
4. People who are managers and leaders. They must be customer-focused and empower your teams.

The Agile Enterprise and the Division of Labor by Gene Callahan

Gene Callahan has some great advice for building awesome people. Beginning with the idea of the division of labor, Callahan walks us through the history of how traditional organizations find themselves as a collection of specialists who struggle to be responsive to the changing marketplace. He then examines the need for people who are generalizing specialists (people who can collaborate effectively and learn from one another).

The Necessities for Successful Enterprise Agile Transformation by Matthew Ganis and Michael Ackerbauer

This article describes how to build awesome teams. You want to be Agile (of course!) and adopt Agile practices. Awesome teams have the skills and resources to fulfill their mission and include the right mix of personalities. The authors argue that the organization is really a “team of teams” that needs a shared purpose and way of working to make the abstract concrete. According to them, awesome teams build on a common foundation based on the concept of Breakthrough Thinking/diversity of thought.

Business Agility: A Roadmap for the Digital Enterprise by Jaco Viljoen

In his discussion of the five levels of a digital business ecosystem (DBE), Jaco Viljoen explores the idea that“choice is good because context counts.” The five levels, each with its own set of capabilities that build one on top of another, are: waterfall/traditional, hybrid Agile (a combination of waterfall and Agile), regular delivery, continuous delivery, and continuous exploration. The five DBEs provide insight into which process-building blocks to apply. Viljoen also discusses using a frame- work to achieve business agility at scale.

Case Study: Linking Business Workflows and Agile User Stories in an SOA Environment by Gill Kent and Robin Harwood

Gill and Robin provide a case study about linking Business Process Model and Notation (BPMN) workflows and user stories. They focus on the importance of initial modeling during what they call the Discovery phase of a digital trans-formation project. In their example, they followed a pragmatic, Agile approach to modeling the business and their host systems to gain important insight into the enterprise transformation scope and a vision of the required system change for their endeavor. This enabled them to establish a business/stakeholder vision that captured a clear scope for the following phases. With an initial technical strategy/architecture identified, the team was able to name a backlog of architecturally relevant stories, mitigating the risk of late identification of system integration requirements and the potential for significant rework. In short, a pragmatic investment in initial modeling and planning paid off in huge divi-dends for their Agile team.

The Wizard of OSS: Follow the Open Space and Sociocracy Road to Enterprise Agile Transformation by Jutta Eckstein and John Buck

The principle of enterprise awareness appears in several of the articles, and Jutta Eckstein and John Buck walk us through an enterprise-aware approach that helps optimize the process flow of value streams. The authors show how to apply “Open Space” and “Sociocracy” to support enterprise Agile transformation. Open Space is a technique where everyone is invited to put forward ideas that they’re passionate about; if there is enough interest in the idea people will get behind it and make it happen. Sociocracy is a form of democracy for use in organizations, building feedback mechanisms into the organizational structure itself that ensure every voice is heard. Both strategies promote enterprise awareness, increasing collaboration between people in what would normally be disparate parts of the organization and helping optimize flow as the situation evolves.

Core Thinking Patterns for Lean/Agile Organizations by Srinivas Garapati

This article explores important philosophies and the mindset behind Agile and Lean. He starts with the thinking patterns required to be successful and then considers the nature of an Agile organization and finishes with strategies for organizational design.

The Institution of Engineering and Technology has recently published a paper entitled An Academic Approach to Transform Organizations One Engineer at a Time by Eduardo Juarez Pineda, Rocio Aldeco-Perez, and Jose Manuel Velazquez.  The DA toolkit features in this paper so I thought you’d be interested.

Paper Abstract:

I recently read the book 8-Bit Apocalypse: The Untold Story of Atari’s Missile Command by Alex Rubens. One of my hobbies is to collect, and of course work with, Atari 8-bit computers (such as the Atari 800) and peripherals. I heard about this book on an Atari discussion forum so thought that I’d read it. The story behind Missile Command itself is definitely interesting. For agilists the book covers some history about Atari’s culture and way of working (WoW) that provides some interesting background about Silicon Valley in the late 70s. This short blog explores both of these topics.

The Missile Command Story

Dave Theurer was the lead developer on Missile Command, working with Rich Adam (who went on to develop Gravitar) to do so. Although the game is long in the tooth now, it was incredibly innovative at the time using bright colours and a track ball. At the time Pong was leading edge, although new games were emerging that used colour and the joysticks and buttons that were soon to become ubiquitous in arcade machines.

An interesting aspect of the Missile Command story was that it was developed at the height of the cold war, with the threat of nuclear armageddon hanging over everyone’s heads. Dave wanted to send a message that there was no winner in a nuclear war. This message was implicit throughout the game in that there was no way to win, all you could do was stave off the inevitable. Instead of ending with “Game Over” as other games did at the time, it ended with “The End.” These subtleties were often missed by players who were more interested in being entertained than being educated, but some people did receive the message. A game that did more than merely keep you entertained for a few minutes was also an important aspect of Missile Command’s innovativeness.

How Agile Was Atari?

In the late 70s and early 80s Atari was the company to work at in Silicon Valley. For every open job position they received hundreds of resumes, not unlike some of the leading firms today. Atari had a work hard, play hard culture that we still see today at many Silicon Valley firms. Atari employees did not work at a sustainable pace, and in fact the book goes into detail about the health problems Dave Theurer suffered from as a result of the stress and overwork. So in that respect Atari was far from being an agile company.

Many employees dealt with the Atari culture through the use of drugs. In fact some of the mythology surrounding Atari is that the employees managed to stave off an acquisition by IBM by openly smoking Cheech & Chong quantities of marijuana the day the IBM executives toured the Atari facilities.

On the positive side of things the development teams were allowed to work autonomously, getting support from other groups for testing, marketing, and deployment as needed. Remember that they were building physical arcade game machines, and were on the leading edge at the time and were creating a multi-billion dollar industry. Development of the machine required a holistic design approach because the team was developing the game software, the hardware it ran on, and even the design of the artwork for the arcade cabinet. Atari development teams were very aware of the overall design, realizing that the look and sound of the machine were key to attracting people to play, whereas the actual gameplay itself was key to keeping people coming back. Given the level of competition in arcades, it was a lot harder to earn the quarters of the players than you would think.

Development proceeded incrementally. The team would build something, test it internally with their own people, and once they thought it was ready they would take it to one or more local arcades to test their game in the field. To do so they would basically take a test machine to an arcade, plug it in, and watch what happened. Atari had people in the arcades observing players with the games under test, and often talking with them about a game after they played it. Very often the developers of a game would go out in the field to be actively involved in this testing. This gave them critical insight into whether people liked a game and what aspects they (didn’t) like about it. They would then act on this feedback and update their game. The book describes how Missile Command went through a series of such iterations until they finally homed in on the final version. Very similar to the Exploratory lifecycle and experimenting through a series of minimum viable products (MVPs).

Atari developers inherently knew that for a game to succeed that it had to delight its customers – if not the player would move on with their fistful of quarters and play another game. For Atari as a company to succeed they had to continuously release new games that delighted customers because Atari wasn’t the only company competing in this market space.

You can’t possible blog about Atari without mentioning that Steve Jobs was one of Atari’s early employees. And yes, he was a total jerk then too. Another important part of Atari mythology is how Atari paid Steve Jobs to develop a circuit board for the game Breakout which he then outsourced most of the work to Steve Wozniak, without telling Woz about the hefty delivery bonus associated with the work (which Jobs kept).

Parting Thoughts

Yes, I’ve been looking for a reason to blog about Atari for awhile. 8-Bit Apocalypse is in fact a good read and there is some very interesting history surrounding Atari. I hope you enjoyed this blog.

Recommended Reading About Atari

• 8-Bit Apocalypse: The Untold Story of Atari’s Missile Command
• Art of Atari by Tim Lapertino is a fantastic coffee-table book. Because the Atari 2600 games were a bit rough, it was a 4-bit platform after all, Atari invested a lot in box artwork.
• Breakout: How Atari 8-Bit Computers Defined a Generation by Jamie Lendino is a great read for anyone interested in the history of the 8-bit Atari computer platform. Well researched and a great resource for Atari fans.
• Atari Inc. Business is Fun by Curt Vendel and Marty Goldberg is the definitive book about Atari’s company history. It’s 800 pages, albeit with a lot of great pictures. There’s a reason why Atari is still an icon today.

At the XP2019 conference in Montreal I had the privilege of giving the opening keynote.  The title of my keynote was “#NoFrameworks: How We Can Take Agile Back”.  My keynote worked through the following topics:

1. A mea culpa where I walked through my work in method and frameworks over the past two decades.
2. What is a framework?
3. What problems do we have with process frameworks/methods?
4. Why are frameworks so popular?
5. Some industry stats on how effective frameworks are in practice
6. What actually works in practice?
7. How we can take agile back?

During my keynote Ankur Saini created a sketch note and as you can see below he’s been kind enough to share it with us.  This blog explores the key ideas captured in the sketch (click on it to enlarge).

There are a collection of points about frameworks, most of which question the value of frameworks:

1. Leadership often adopts a framework because others are doing it. I hate to say it, but we often see agile frameworks, in particular SAFe, get adopted simply because other organizations are doing it. There seems to be less concern about whether the framework is a good fit, or even if it solves a problem the organization actually has, compared with whether others have adopted it (so therefore it must be a good idea).  In short, adoption of the framework often does more harm than good.
2. Developers like frameworks because of the easy certifications. What’s not to like about becoming a certified master after taking a two-day workshop, or a program consultant after a four day workshop? Back in the distant past (the 1980s) I had to go to school for four years just to get a job as a junior programmer.  But, if you adopt an agile method or framework, you can become certified in it in just a few days of training!  In short, the frameworks enable people to present themselves as more qualified than they actually are, and motivate them to think that they know more than they do, which more often than not leads to trouble later on.
3. Vendors like frameworks because it’s easy to support a single way of working (WoW).  Most tool vendors like well-defined, popular methods/frameworks because it makes it clear to them what functionality they should implement.  Prescriptive frameworks are particularly attractive because the tool vendor only has to implement a single way of working (WoW), reducing their development effort.  Cha-ching!
4. Consultants like frameworks because they’re easy to learn.  Prescriptive frameworks supported by certifications that you “earn” in just a few short days enable consultants with little experience in agile to present themselves are experts and even expensive coaches to the unwary and gullible.  Cha-ching!  And consulting organizations can swiftly build up an army of such consultants quickly in order to staff huge teams at their clients.  Cha-ching cha-ching!
5. Frameworks put you in method prison.  As Ivar Jacobson warns us about, we quickly find ourselves in method prison with prescriptive agile methods and frameworks that give you a limited way of doing things.  You’re often told that they’re flexible and can be tailored to meet your needs, but then they leave that very hard work up to you. The problem with this is that when organizations hit the limits of what the framework addresses, and the knowledge of their “certified experts,” that they either become disillusioned with agile or they find themselves on the very expensive path of extending the framework on their own.
6. Are frameworks right for you? I asked several questions to get people to realize the challenges surrounding frameworks.  These questions included: What if the rules (of the framework) don’t apply to your situation?  What if the situation changes?  What if the framework solves a problem that you don’t actually have? What if the framework solves the problem and you find yourself in a new situation? For methods/frameworks that tell you that you can tailor them, what do you do if you don’t know what the available options (practices/techniques) are?  What if you don’t know how to compare the options?
7. Are you joining a cult? When I was putting the keynote together I went looking for possible definitions of frameworks.  I noticed that they were suspiciously close to the definition of a cult.
8. Frameworks are not silver bullets. Regardless of the marketing promises, or more often than not the perceptions left by marketing promises, there are no easy answers to your process and culture-related problems.  It takes hard work to improve your WoW, you don’t just “install” a new method/framework and in a few short months you’re agile. In short, the purveyors of methods and frameworks often set very unrealistic expectations.
9. There is no best practice that applies to all situations. Every practice is contextual in nature, there are no “best practices” that apply in all situations.  Similarly, many of the “bad practices” that agile purists rail against (but hey, it’s not a cult) do in fact make sense in some situations (yes, there are often better practices available).  Sadly, many people are of the mindset “just tell me the best practices I need to adopt” and the frameworks/methods cater to that very attitude.  People willing put themselves into method prison.
10. Focus on the apex predators. A common question that we ask executives when we’re working with them to help adopt new WoW in their organizations is “Who keeps you up at night?  What organizations are you afraid of competing against?”  It’s been years since a banker, for example, has told us that they’re afraid of other banks.  We often hear that they’re afraid of having to compete against Amazon, Google, or fintechs.  They’re afraid of these organizations because they’re hyper-competitive “apex predators.”  We then ask them how these organizations became apex predators, whether the executive believes they adopted an “agile scaling” framework like SAFe, LeSS, or Nexus to do so.  When the executive says no, of course not, that’s when we can have an intelligent conversation about process improvement. In short, if the scary competitors, the apex predators, aren’t adopting these frameworks it should give you reason to pause.
11. Learn and improve through experimentation. In case study after case study after case study you learn that apex predators, the hyper competitive organizations that everyone respects and fears became so through continuous process improvement via small changes.  This is often called a kaizen loop.  You can speed up process improvement via a technique we call guided continuous improvement (GCI). Doesn’t it make more sense to act in a similar way that the apex predators act?
12. Improvement is a journey, not a project. An important lesson that we can take from the apex predators is that they all have learned that process improvement is a long-term journey, one that never ends.  Many of them may have started this journey with an improvement project, but the successful ones all learned that this was only just a good start.
13. You can only go to war with the army that you have.  You have likely staffed up your organization in a manner that reflects “the old rules” or your old way of working.  Part of improving your way of working (WoW) is investing in your staff to help them gain a new mindset and new skills. You need to help turn the people that you have into the people that you need.
14. No need for reinventing the wheel. Although every person, every team, and every organization is unique that doesn’t mean that you need to develop your own WoW from scratch.  There are thousands of great techniques out there that have been implemented by thousands (if not more) of teams around the world. You can also learn and apply these techniques too, combining them in a unique manner to address your unique situation.  Yes, you may stumble onto a completely new technique at some point.  Great, please share that with us.  But 99.99% of the time you’ll be following techniques that others have followed before you. Have the humility to recognize this and actively choose to learn from the experiences of others rather than take the long and expensive path of figuring out everything on your own. The DA toolkit can help with this.

To summarize, there are many very good reasons to question the value of “agile scaling frameworks.”  We can do better.  We must do better.

As you can see in the picture above I made several suggestions for taking agile back:

1. Respect yourself. The first step to addressing the meaningless certifications within the agile community is for people to push back against them. If you’re going to get certified in something then make sure that it’s a certification that you earn, not buy. It takes years to become proficient at something, not days of training.
2. Go back to fundamentals. A fundamental concept from the early days of agile was that we would work to learn and improve over time.  This is what the lean strategy of kaizen loops are all about and certainly what GCI is all about.
3. Be humble. The problems and challenges that you face today have been solved by many people who have come before you.  We can choose to learn from these people, to adopt and extend their strategies.
4. Be agnostic. We can learn a lot from the various frameworks and methods (and other sources of information) that are out there. Treat them all with respect, and take what you can from each. Spend a bit of time with the Disciplined Agile (DA) toolkit and you’ll quickly discover that we’ve already done a lot of that hard work for you.
5. #NoBestPractices. As I pointed out above, all practices are contextual in nature – they have advantages, they have disadvantages, they work well in some situations and poorly in others.  Our latest book, Choose Your WoW!, puts hundreds of agile and lean techniques into context, enabling you to identify strategies that are likely to work for you in the context that you face.
6. Start where you are. Whatever you’re doing today – be it following a traditional approach, or a Scrum-based one, or one based on SAFe, or something else – that’s where you’re starting from.  Adopt GCI to begin improving from base, and you’ll soon find that you’re working your way out of method prison to a much better future.
7. Observe, think, experiment. We need to observe what situation we’re in, think critically about what we face and about how we can improve, and then experiment with new WoW to see what works for us in our context.
8. Optimize the whole. We need to get better at looking at the bigger picture.  For developers we need to look beyond programming to DevOps, to IT, and to the business as a whole.  For business people, because everyone organization is a software organization now, we need to invest time to understand how IT works. We need to streamline at least our overall value stream that we’re part of and better yet our organization as a whole.

The message that I left the conference attendees was this: Start where you are, do the best that you can in the situation that you find yourself in, and always strive to learn and get better. Becoming agile doesn’t have to be hard.

While working with organizations to help them to learn how to improve their way of working (WoW), we’ve developed a technique that we call guided continuous improvement (GCI).  Adopting an agile method such as Scrum, or a framework such as SAFe, may give you an initial start at improving your WoW you will quickly find yourself in “method prison.” The organizations that break out of method prison do so with a kaizen-based continuous improvement approach, or better yet GCI.

First, some definitions:

• A kaizen loop is an approach where a team experiments with a small change in their WoW, adopting the change if it works in their given context and abandoning it if it doesn’t.
• Continuous improvement is the act of applying a series of kaizen loops to improve your WoW over time.
• Guided continuous improvement (GCI) extends the kaizen loop strategy to use proven guidance to help teams identify techniques that are likely to work in their context.  This increases the percentage of successful experiments and thereby increases the overall rate of process improvement.

In the article we go into the details of the technique, exploring:

• Why every team is unique
• Why agile methods/frameworks will only get you so far
• How to apply a kaizen-based improvement strategy
• How to improve kaizen loops with the DA toolkit
• How to break out of “method prison”

We hope you find the article to be a game changer for your agile adoption efforts.