Disciplined Agile

We are excited to announce that the Project Management Institute (PMI) has acquired Disciplined Agile.  The official announcement is posted here. In the coming weeks we will have more information for you, so please stay tuned!

Security is one of the process blades of Disciplined DevOps. The focus of the Security process blade is to describe how to protect your organization from both information/virtual and physical threats. This includes procedures for security governance, identity and access management, vulnerability management, security policy management, incident response, and vulnerability management. As you would expect these policies will affect your organization’s strategies around change management, disaster recovery and business continuity, solution delivery, and vendor management. For security to be effective it has to be a fundamental aspect of your organizational culture.

The following process goal diagram overviews the potential activities associated with disciplined agile security. These activities are performed by, or at least supported by, your security (often called an information security or infosec) team.

Figure 1. The Security process goal diagram (click to enlarge).

The process factors that you need to consider for implementing effective security are:

1. Ensure security readiness. How do you ensure that your environment has been built to withstand the evolving security threats that you face?  
2. Enable security awareness. How do you help your staff to become knowledgeable about security threats, how to avoid attacks, and how to deal with them when they occur?
3. Monitor security. How do you identify when you are under attack (for most organizations the answer is constantly) and more importantly how you’re being attacked?
4. Respond to threats. When an attack occurs what will you do to address it?
5. Security physical assets. How will you protect physical assets such as buildings, vehicles, and equipment?  By implication, how will you ensure the security of your people?
6. Secure IT perimeter. How will you secure access to your IT systems?
7. Secure the network. How will you ensure the security of digital communications?
8. Secure IT endpoints. How will you secure access to devices such as phones, workstations, and other I/O devices?
9. Secure applications. How will you address security within the applications/systems of your organization?
10. Secure data. How will you ensure the validity and privacy of the data within your organization?
11. Govern security. How will you motivate, enable, and monitor security activities within your organization?

Further Reading

• The Security Process Blade
• Disciplined DevOps?

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.