The Meeting
I was recently invited to a high-level meeting with a group of executives who were interested in learning about how they could make their internal software development teams more Agile. The presenter started to explain how they helped other clients become more Agile and what the key challenges were. After a while, the Group Vice President (GVP) sitting next to me interrupted the conversation and explained that they weren?t ready to talk about the cultural changes required to transform the teams. Well, needless to say, the guy who spent all week putting together the perfect Agile presentation was dead in the water. The presenter got a bit confused and he didn?t understand what the GVP was asking for. After some dialogue back and forth, the conversation really started to deteriorate.
I piped up at that point and interjected that the GVP was asking, ?What does a modern software factory look like?? The presenter looked at me incredulously and said, ?Well, it?s all right there.? I had to remind the presenter that not everyone in the room understood the complexities of the day-to-day process, tooling, and rationale of what he was presenting. Basically, he was talking to everyone as though they had been in the software development game for a while. The GVP turned to me and said, ?Yeah, that?s right. Could you explain how all this stuff works together and why I need it?? I said, ?Sure!? not realizing what I had just committed myself to. I then left the meeting wondering, ?How am I going to explain this stuff without his head exploding?? The funny thing was, the same type of question came up at the next executive meeting that I had with a different client.
The Epiphany
After thinking about both of these conversations and being on the hook to produce some sort of explanation, I started working on this blog series. The goal of the series is to explain how people are enabling their Software Factory and why they would choose differing approaches. The series is also about telling the story from an objective viewpoint and not emphasizing vendor solutions, process frameworks, and implementation best practices. Feel free to use my mistakes (I?ve made plenty over the last 27 years), analogies, and observations as your own. I?m not a professional writer, but I do think this is something I can contribute to the community.
The Buzzwords
As with all subjects, there are some terms that you need to know to get the full picture of what I?m explaining. For this part of the series, here is a quick glossary of terms pulled from Wikipedia, along with some added commentary:
- Systems Development Life Cycle (SDLC): "The Systems Development Life Cycle, also referred to as the Application Development Life Cycle, is a term used in systems engineering, information systems, and software engineering to describe a process for planning, creating, testing, and deploying an information system." I?ve heard the words ?System? and ?Software? used interchangeably to describe the SDLC, so no, you?re not crazy.
- Agile Software Development (Agile): "Agile Software Development describes a set of principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change." I?ve also seen the term being used to describe organizational processes that have adapted principals from this methodology.
- DevOps: "DevOps (a clipped compound of Development and Operations) is a culture, movement, or practice that emphasizes the collaboration and communication of both software developers and other information technology (IT) professionals, while automating the process of software delivery and infrastructure changes." My interpretation of this is that it describes the space between Development and Operations, but not much else. From my experience, the term seems to be overused in reference to initiatives, and it doesn?t really define what the focus is all about.
- Continuous Delivery: "Continuous Delivery (CD) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time." I like this definition because it describes something tangible for the SDLC. However, I would like to add the word ?quality? to the definition so that it reads, ?Continuous Delivery is a software engineering approach in which teams produce quality software in short cycles, ensuring that the software can be reliably released at any time.? No sense in pushing out crappy code extremely fast! Also, this definition implies that Agile techniques are being used in concert with tooling automation to achieve the desired outcomes.
The Digital Transformation Blueprint
Image A below depicts a common blueprint of how other entities may interact with your business through various channels of communication. Clients, employees, and partners are demanding a secure, reliable, personalized experience across multiple platforms through these channels. We see this kind of behavior every day. Examples would be you digitally accessing your bank account, benefits, car insurance, or airline to perform common actions in an intuitive manner on any available device. It?s also important that partners can easily interact with your business. An example would be purchasing something online and having the shipping company and the credit card company interact in real time with your transaction.
Image A
What kind of impact does this transformation and demand have on IT? It?s a force multiplier! Basically, change is happening faster than ever, and the solutions are far more complex, causing IT departments to think differently about solving these challenges with constant, available resources. This is especially true in the DevOps and/or Continuous Delivery space, which is where your software is being created and implemented.
A Needed Change in Thinking and Process
So, what?s the big deal about the process of creating software? I mean, why can?t we continue to create software the same way that we always have?
Well, we can, but there are some drawbacks to how we?ve traditionally created software. Image B lists some of the more common activities within software development, broken down into six functional categories. As you can see, it?s quite a bit of work overall.
Image B
In a Traditional Software Delivery model, all of the planning is done up front and then the application is created from the design requirements. This makes a lot of sense, but in practice can be challenging because the requirements keep changing based on feedback more quickly than the application can be created. This means that you cannot keep up with the rate of innovation, which may be a disadvantage to your competitive position in the market.
What we need is more speed, Scotty!
Whoa, hold on! More speed? Are you insane? That means we?ll have more problems and security risks! Au contraire. The numbers favor you speeding up your application delivery process. I had the opportunity to attend one of the DevOps Days events in Minneapolis, Minnesota. The keynote speaker was Dr. Nicole Forsgren, who presented The Data on DevOps: Making the Case for Awesome. She was dynamite, and a very cool person to meet. Her work indicates that high-performance DevOps and Continuous Delivery Teams propel their businesses and are more Agile and more reliable. In essence, they?re finding and solving challenges more rapidly, improving reliability, and improving stability, while increasing application delivery.
Image C
So, most people say to me at this point, ?Okay that?s cool, let?s go to Warp 10, but how do I do it?? The answer lies in traditional manufacturing methodologies and supply chain management techniques. In a Traditional Delivery style, the work is done in almost a one-way manner. The application work is very linear and sequenced accordingly through each stage of the process. A Traditional Delivery style could take months or years before the final product is revealed. The Continuous Delivery style has shorter incremental delivery cycles, called Sprints, that last two to three weeks over a three to four month period. The objective of each Sprint is to produce working components ? pieces of the total application ? that can be demonstrated to the people commissioning the work. Input is collected at each stage, and a new Sprint is begun with changes included. Image C above illustrates a high-level style difference between Traditional and Continuous Delivery methods.
In the manufacturing world, the Traditional Delivery style would be similar to having one team create the entire product from start to finish, whereas the Continuous Delivery style would be similar to a modern assembly line ? where parts are accessed just in time and incremental work is handed off to the next team as soon as it?s finished. The advantage is that the work in process moves to completion faster.
A good example of this was a coin-flipping exercise that I participated in. We had 20 coins and four people. The beginning objective was to have each person flip each coin and record heads or tails. When finished, the 20 coins were passed to the next person to do the same thing. It took us roughly four minutes to complete as a group. The next time through, we performed the coin flip and recording, but then passed the coin to the next person immediately. It took a fraction of the time to complete the exercise the second time through.
Now, the Continuous Delivery style has some ramifications that may not be obvious. Working in short increments means that you?re going to find problems faster, that communication and collaboration need to be more deliberate, and that the term ?project? really doesn?t make sense anymore because everything is in constant motion with no end. Huh? In addition, as I mentioned earlier in the glossary comments about Continuous Delivery, I look at this engineering practice as Agile techniques working in concert with tooling automation. You need the automation piece in order to go through all the tasks we outlined every two to three weeks ? a process that used to take months.
Fortunately, people who are much smarter than I am have created process frameworks that help us work through all the complexity of implementing a Continuous Delivery approach. Some of the most common frameworks are Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS), and Disciplined Agile Delivery (DaD). All these frameworks are effective and free to learn about. I think there are a lot of benefits, however, in receiving thorough training on the framework of your choice. I was certified on the SAFe framework, so most of the comments in this blog will lean toward those concepts.
I think the cool thing is that the term ?Agile? has moved beyond just being a developer term into a description of the organization and how people manage these efforts. In the SAFe framework, the constant communication loops scale up through the management chain. The overall effort is called a Release Train, funded based upon capacity, like manufacturing facilities. This is why I?m referring to this series as a Software Factory.
We now have some idea about why and how to change the process of implementing software. In my next post, we?ll dive into the tooling piece and talk about common platforms and the environment used to facilitate Continuous Delivery.
