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.
Screen shot from Missile Command
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.
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.
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.
Essencewas created by the Software Engineering Method and Theory (SEMAT) community and approved by The Object Management Group as a standard in 2014. The basic of Essence is that “provides the common ground for defining software development practices” (see [R1-ES]) and also is intended to build and maintain an open library and marketplace of software engineering practices and education materials (see [R3-SMMS] ).
Essence is important, (see specification [R1-ES]), because:
“Provide a common base that is useful for software engineering endeavors of all sizes (small, medium, and large)”
“Enable method building by the composition of practices, so that methods can be quickly assembled by a project team to match their needs, experiences, and aspirations. Allowing the method to start small and grow as needed”
“Support method agility, so that practices and methods can be refined and modified during a project to reflect experiences, lessons learned, and changing needs”
“Support scalability including from one product to many, from one team to many, and from one method to many”
In this article I show how to describe DAD Essentials. Essentializing DAD is different from similar endeavors because Disciplined Agile (DA) is not a prescriptive method/framework like Scrum/SAFe. Instead, DA is a toolkit based on similar goals as Essence in that it is generative – both provide building blocks from which you can tailor and evolve a process that meets your needs.
DAD Essentials
The role of this Essentials is to provide an overview of the DAD guidance and over the capabilities that could be developed for each significant aspect (“Alphas”) of an Agile & Lean process. What is really happening on Agile/Lean adoption (and in any process improvement) is developing & exercising of new capabilities. What is specific to Disciplined Agile is that it provides guidance for developing the capabilities that team & organizations needs for their specific context.
DAD Essentials are presented here in cards format using the OMG/SEMAT Essence Language constructs as Alphas, Patterns, Resources, Activities, Work Products (see Glossary section below). Each “card” has a name, a description, and a list of capabilities for your team or organization to develop.
Glossary
The following terms are used in Essence.
Alpha
An essential element that is relevant to an assessment of the progress and health of the software engineering endeavor.
Patterns
A generic mechanism / complex concepts that are made up of several other elements
Resources
A source of information or content.
Activities
One or more approaches for carrying out some work to be performed and can recommend actions on alphas and/or work products in order to and relevance this work.
Work Products
An artifact of value and relevance for a software engineering endeavor.
Full delivery life-cycles
Full, beginning-to-end, delivery life-cycle it is an explicit representation of how a software release will progress in time. The pragmatism and effectiveness of Agile (<> Waterfall) are based on realistic progress milestones with the evolution of working software toward a consumable solution. A team could have a reference lifecycle, but in a different context, they may need to use also other types of life-cycles.
Capabilities to develop:
A reference life-cycle
Support for Iterative-Agile, Lean, Continuous Delivery life-cycles
Support for high incertitude deliveries
Support for long term roadmaps (product, business, technology)
Consumable Solution
Consumable solution is more than working software. Consumable means that we meet stakeholder needs in the context constraints and it is usable, desirable, and functional. A solution implies that, as needed, we:
Develop high-quality software
Provide new or upgraded hardware/platform
Change the business/operational processes which the stakeholders follow
Change the organizational structure in which our stakeholders work
Update supporting documentation
Capabilities to develop:
Understand Consumable Solution
Build using DAD guidance the Consumable Solution across life-cycle milestones, considering various life-cycle and practices options depending on context
Adapt to Context
DA supports two principles that motivate you to adapt your approach to your context:
Context counts. People, teams, and organizations are all unique – leads us to a critical idea that your process and organization structure must be tailored for the situation that you currently face.
Choice is good. Different contexts require different strategies – teams need to be able to own their own process and to experiment to discover what works in practice for them given the situation that they face. This is why the DA framework presents people with choices through the application of process goal diagrams.
Select practices per process goals in a given context and life-cycle
Use DAD Library of practices & context options guidance
Make experiments to see what works in your context
Core Agile Practices
Core Agile Practices will help you have a Lean process: they address the main sources of waste and have multiple benefits at the same time. It is not a coincidence that XP is based on some of them, Disciplined Agile and Agile Modeling refer them as critical practices. (See also references from Mary Poppendieck / Tom Poppendieck in “Lean Software Development”). Some core practices are:
XP practices: Small Releases, Pair Programming, Simple Design, Refactoring, TDD, Coding Standards, and more.
DA/Agile Modeling practices: Requirements/Architecture Envisioning, Architecture Handbook, Model Storming, Rolling Wave Planning, and many more.
Method free practices: Clean Code/Architecture.
Interestingly, Essence describes in detail several dozen core agile practices in detail whereas Disciplined Agile puts several hundred agile, lean, and even traditional core practices into context. This is one of several reasons why Essence and DA are complementary to one another.
Capabilities to develop:
Understand how and why you will eliminate waste
Context usage: Core Agile Practices are not “best practices” and we still need to know the trade-offs and options for different context (See Adapt to Context alpha). Make experiments to see what works in your context
Teal Teams and Organizations
Optimize the whole: the Organization (and its constituents teams) represents that “whole” where the work optimization really makes sense. In Reinventing Organizations, Frederick Laloux presents the historical evolution of organizations from tribal to modern agile approaches:
Green (Post-Modern/Information): Value-based, consensus/participative style
Teal (Self-Organizing/Adaptive): Cellular organism with evolutionary purpose
Disciplined Agile use this model and propose as a goal the Teal organization (or at least Green): cellular, self-organizing, adaptive, aware, with evolutionary purposes. Most likely, your organization is a “rainbow” (e.g. Orange/Green/Teal). Context counts, different teams faced different situations and you can choose your strategy. You want to be at least Green because that will provide – through a participative & collaborative style – a solid foundation for further process improvement. Also, the DA Principle, Be Awesome has some expectations:
Treat people with respect, honesty, be reliable and open
Willingly collaborate with others
Capabilities to develop:
Teams will offer psychological safety with clarity about roles and responsibilities
Cross-functional skills teams, where T-skilled “generalizing specialist” is the most pragmatic, effective, efficient approach.
Use collaborative work to envision, look ahead and just-in-time clarifications.
Collaborative and continuous process tailoring and improvement, not only on retrospectives
The purpose of the Continuous Improvement process blade is to enable people within your organization to easily share their improvement learnings with one another in a systematic way. The technique of Guided Continuous Improvement (GCI) shows teams how to leverage the DA toolkit to speed up their process improvement efforts.
Capabilities to develop:
Continuous improvement must be explicit and fundamental
A base support for improvement should be running: life-cycles, collaborative work, retrospectives
Kaizen strategy: continuous improvement should always be running in small steps and experiments. This lean strategy is fundamental for addressing problems complexity & incertitude.
apply the DAD toolkit to adapt to context (see corresponding alpha) for process goals as: selecting a life-cycle, forming the team, addressing changing stakeholders needs.
hire/listen experienced coaches
make progress on adopting Core Agile Practices
have explicit goal/guidance for Evolving your WoW
An Agile method such as Scrum, or a framework such as SAFe, can be a good start but it will have too few guidelines for choosing your way of working (WoW) in context or too little guidance for core Agile practices. DA provides the guidance for evolving your WoW and Essence the details regarding core practices. As Ivar Jacobson likes to say, this will enable you to break out of “method prison.”
Patterns
DA Principles
Delight Customers, Be Awesome, Pragmatism, Context Counts, Choice is Good, Optimize Flow, Enterprise Awareness
Agile & Lean Principles
DAD use Agile and Lean Principles intesively. Examples: Practices support and guidance, the Disciplined Agile Manifesto, Lean and Agile life-cycles etc.
Collaborative, Cross Functional Teams
Collaboration is a fundamental Agile and human value, and DAD supports that with several practices. Also, DAD promotes T-skilled “generalizing specialist” as an effective, pragmatic approach of cross-functionality.
Pragmatic Agile Roles
The DAD toolkit suggests a robust set of roles for agile solution delivery, roles that work well in real practice. DA propose also some secondary roles (less used, temporary or at scale)
Process Goals
DAD toolkit takes a light-weight, goal-driven approach to support adapt/tailor WoW to context. While process capabilities (goals) remain the same, you can use different choices and select different practices in a given context.
Scaling Factors
The context will permanently change and the Scaling Factors are significant aspects that will drive tailoring your element reflect the situation that you face.
Resources
Guidance, Adapt to Context: Select Life-cycles
Solution delivery teams face different situations so one lifecycle will not fit all. DAD offers more options for Agile and Lean life-cycles and appropriate guidance:
For each factor of process goals, DAD toolkit proposes more options of practices with guidance about efficiency and tradeoffs in context.
Library of Practices
DAD toolkit offers a library of practice including both Core Agile Practices and options for each process goals.
Agile Modeling
Agile Modeling Core Practices are art of the DAD toolkit and where developed as complement to XP.
Agile Data
Agile Data Core Practices are used by the DAD toolkit
Work Products
Consumable solution Increment
The basic element for measuring progress. Also referred as “working software” or “product increment”. See “Consumable Solution” alpha for differences.
Work Items Representations
Is not reduced to Product Backlog: we can use Work Item List (improved backlog concept), Work Item Pool or others.
Definition of Ready
Eliminate waste: streamline the flow evolution from incoming work to WIP. DAD practices: Look Ahead Modeling and Look Ahead Planning.
Definition of Done
Eliminate waste: advance without technical debt, avoiding re-work and unexpected problems and interruptions.
Activities
Selecting a life-cycle
Team activity: each release has a life-cycle choice. Preserving the one from the previous release or a model from an Agile Method (or even Waterfall) is also decision. Guidance & past experience will help.
Selecting practices
per Process Goals
Team activity: for each process goals the team will have its own choices. Preserving practices from previous releases or selecting others from some Agile methods is also a decision. Guidance & past experience will help.
Look Ahead collaboration
Looking ahead variants: envisioning the release, iteration look ahead and opportunistical look ahead before or inside the iteration. DAD offers collaborative practices for all of them and not only for iteration and daily planning.
Just in time collaboration
Just in time collaboration to clarify requirements, solution or other aspects. Example of practices: Pair Programming, Model Storming.
Lightweight Milestones Reviews
You can go beyond prescribed iteration level review in several ways. At the release level, you have the ones for the life-cycle milestones, including the one for proven architecture. At a smaller level, especially if you get the working software faster you could have automatic reviews (see Automatic validations).
Retrospectives
Improvement meetings, fundamental for continuous improvement. Collaborative work makes them effective.
Automatic validations
Include more kind of validations: automatic tests, automatic design check, and others. Fundamental for continuous integration, continuous delivery, and also for any form of often delivery/small releases.
Acknowledgements
I want to thank Scott Ambler who started this Essentializing DA initiative and collaborated with SEMAT from 2009. Scott helped me with feedback and review of current materials. DA Essentialization began with the example of the DB Refactoring technique earlier this year.
Use of Essence – Kernel and Language for Software Engineering Methods Specifications is the subject of Term and conditions & Notices found at https://www.omg.org/spec/Essence/1.2
The Disciplined Agile (DA) Tool kit is a tremendous resource to be used in every Lean-Agile adoption / transformation effort, from team-level to enterprise-level. The DA Tool kit, now with more clarity on choosing your way of working (WoW), offers new and established teams an opportunity to evolve further through consideration of their context and the many goals, factors, and options available to them.
Disciplined Agile Delivery (DAD), with its focus on delivery has provided a solid foundation for building high performing delivery teams. As enterprises come to value the benefit of these team-level improvements the desire to leverage these improvements throughout the enterprise, scaling these improvements, is a common enterprise strategy today. Of course, DAD Teams are enterprise aware and ready to work with the enterprise to reduce overall delivery time and cost.
There are many scaling factors to consider as an enterprise seeks Agility at Scale. Additionally, the DA tool kit provides straightforward guidance for scaling into Disciplined DevOps and then into value streams. Finally, the toolkit provides guidance for a Disciplined Agile Enterprise. It is here that I want to focus on Principle 6, Optimize Flow.
DA recognizes that enterprises are complex adaptive systems. The solutions they are providing are also complex solutions. Gone are the good’ol days of simply being complicated!
The challenge, as stated by the principle to Optimize Flow, is how to ensure collaborating teams do so in such a way as to effectively implement our organization’s value streams? And, how do we optimize our overall workflow?
I’ll take the liberty here to rephrase and combine the two questions. How do we organize long-standing teams to support the delivery of value for the enterprise in a way that allows for ongoing optimization experiments (as in Lean Change)?
To ‘implement’ the organization’s value streams for delivery of solutions, we must first identify and visualize the operational value stream of the enterprise and then determine the nature of the solution being delivered.
To the sharp-eyed reader, you’ve noticed that I’ve qualified the use of value stream with a reference to operational value stream. Yes, I believe there is a value stream that is characterized by the enterprise: The value stream through which it delivers value to its customers, clients, members, or whomever external to the enterprise is paying for the value delivered. This is the operational value stream, the flow from order to cash.
Well, there is no reason to qualify the use of value stream if not for at least a second type of value stream. That second type is a development value stream. The development value stream is where we can fully leverage the wealth of resources available from the DA Toolkit. This is not to say that we can’t use various ideas and principles from the DA Toolkit to improve the operational value stream. Only that the sweet spot for considering the Disciplined Agile Enterprise (DAE) is from the point of view of the development value stream.
So, what is a development value stream? A development value stream is responsible for implementation and maintenance of solutions that provide for business capabilities that are in turn needed to support to operational value stream. Here, in the development value stream, is where we are better able to apply the Optimize Flow strategies of delivery at a sustainable pace, optimization of the whole, making work flow, and using experiments to eliminate waste and to gain an understanding as those long-standing teams participating in the development value stream use validated learning through metrics to continuously improve.
A development value stream is implemented by way of establishing and organizing DAD teams in alignment with the flow of idea to solution for improvements of business capabilities within the enterprise.
Sustainable pace
For a team of teams aligned to enable business capabilities the continuous generation of business capability improvement ideas can easily exceed the capacity of the delivery teams to implement each idea. It is important the leaders within the enterprise understand that more can be accomplished with the people they have when they limit the amount of work requested of them to their capacity to do the work. Exceeding that capacity ultimately results in less work being accomplished overall as we lose productivity though excessive multitasking. Yet, each team will want to be responsive to the perceived demand of the enterprise. In their efforts to self-organize to improve on what they can accomplish it is important to keep the next strategy in mind, optimize the whole.
Optimize the whole
Within a team of teams each team is typically striving to contribute a smaller outcome that, together with the outcome of other teams, contributes to a larger outcome needed to improve a business capability. Teams should seek to optimize around the delivery of the larger outcome rather than only their own contribution. It is important to be aware that the optimization of a component of a system may, in fact, cause a sub-optimization of the larger system. Focus on the flow of the larger value delivery to make work flow better overall.
Make work flow
The principle to visualize work enables teams to identify and remove bottlenecks. Kanban is a great method for this visualization. But, the idea of a Kanban board is not limited to being applied only for a Kanban team. Scrum, and indeed, anyone or team can borrow from Kanban. An overarching visualization of the work is our need. For a team of teams, that visualization to optimize the whole needs to encompass the effort of the team of teams. While the individual teams may focus on the flow of user stories, the team of team should be visualizing the flow of the large outcomes that the team of teams is striving to delivery. With that visualization the team of teams can work together to eliminate waste that, from their team point of view, might not be visible, or might not have been within their ability to influence improvement experiments that required the support of the team of teams.
Improve continuously
Everyone familiar with Scrum understands the value of periodic retrospectives. These retrospectives allow for the self-organization of the team to streamline their processes. This same approach should be considered for a team of teams. Periodically, perhaps once a quarter, the team of teams should collective gather to consider experiments that will streamline the more overarching issues they all face.
Experiment to learn
Consider the ‘implementation’ of all improvement ideas as experiments. Just as we can no longer provide concrete implementation plans for the complex technical solutions delivered today, we can not develop a concrete process/behavior/culture improvement plan for today’s enterprises that are themselves complex adaptive systems. Also, we’ve learned that small changes are better than big changes. Choose to learn with small Minimal Viable Changes (MVC). Advance your learning by leveraging the learning of Lean Change.
Measure what counts
For each experiment to learn determine the measures of success before starting the experiment. What is the goal of the change (experiment)? What questions need to be answered to know if the outcome of the experiment is likely to realize that outcome? What measurements can be used to obtain the information needed to answer those questions? Don’t waste time and money on vanity metrics.
Prefer long-lived stable teams
Where is the value once you optimize flow when you throw out that value by disbanding your high-performing team of teams? By aligning your team of teams, your development value stream, with business capabilities that enable your operational value stream you have created an organization that can be long-lived because the business capabilities of an enterprise tend to be persistent for the life of the enterprise.
The bottom line
When you find yourself coaching a larger number of teams for an enterprise with the vision to become more agile overall, I propose that you expand upon the principle of the Disciplined Agile Toolkit to Optimize Flow. The principle to Optimize flow applies at the larger scale of a team of teams. This article has hopefully helped you map the Optimize Flow principle to a larger number of teams, a team of teams, organized as a development value stream when you consider the transformation/adoption needed for a Disciplined Agile Enterprise.
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:
A mea culpa where I walked through my work in method and frameworks over the past two decades.
What is a framework?
What problems do we have with process frameworks/methods?
Why are frameworks so popular?
Some industry stats on how effective frameworks are in practice
What actually works in practice?
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:
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.
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.
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!
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!
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.
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?
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.
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.
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.
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.
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?
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.
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.
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:
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.
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.
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.
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.
#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.
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.
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.
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.
The results of the 2018 State of Agile survey (StateOfAgile.com) have just been released. This survey, while not particularly scientific in its approach, is a widely read and frequently quoted survey of what people are actually doing on a variety of agile topics. It is good to see that Disciplined Agile continues to grow in popularity, up from 5% marketshare to 7%, behind only SAFe which commands a 30% market share and is the clear leader (Scrum of Scrums is ahead of DAD, but it is just a practice, not a method). While we are very pleased that people are finally starting to understand what DA is and how it can help them, I am not particularly fond of the way the question is framed in the survey and would like to share my thoughts for how it could be improved, and my interpretation of the findings.
Disciplined Agile (DAD) is listed as an option in the “Which scaling method/approach do you use?”. People who understand DA know that it is actually not specifically a scaling framework. It is rather a toolkit of strategies, a hybrid of practices from many methods and frameworks which can help you optimize your way of working (WoW) regardless of which approach you use. It can be used on one small Scrum team, or dozens of SAFe teams. Whatever approach you use, DA can help you to become even more awesome! #beawesome
As I said above, Scrum of Scrums should not be one of the choices as it is simply a coordination practice for Scrum at scale, not a method.
“Don’t know” is interesting as an option. It puzzles me that people that are answering this survey aren’t aware of their organization’s approach. My suspicion is that many of the people picking this selection actually mean “Not applicable” as many organizations do not scale agile. I think that this should available as a selection.
The question really should be a multiple choice, rather than single. Most organizations use a variety of approaches. It would be more useful to ask “What percentage of your IT spend uses each of the following approaches?”
Spotify is actually not a framework. It is how a Swedish music company circa 2014 had adapted agile at that point in time, to optimize their WoW for their unique context. If you copy their approach you are copying an old approach of a company in a situation unlike yourselves, and for which they have evolved away from significantly.
I find “Internally created methods” intriguing as a choice. We think that this is what all companies should aspire towards. Start with either where you are currently, or one of the other methods (recipes), and then use the DA Toolkit to either evolve away from, or to improve your approach for your unique organization and team context.
Spotify actually embodies this approach. They have continually evolved, improving, and optimizing their way of working. Menlo Innovations also has done the same thing, starting with Extreme Programming (XP) as their core method, and then optimized for what works for them. Rather than copying other companies approaches we should “learn how to learn” about what works best for us. We describe this approach of leveraging proven fit-for-context practices in our Choose your Wow! book as “Continuous Guided Improvement”. Starting with some basic scaffolding of an existing method (what we refer to as “lifecycles” in DAD) provides a jumpstart on your WoW optimization.
We would recommend that you do not aspire to “be Spotify”, but rather “be like Spotify”. Start with a basic method/lifecycle (recipe), then spice it up with the help of proven strategies from the DA Toolkit (ingredients).
Become your own Spotify or Menlo, not somebody else’s.
