devopsy.kinsta.cloud

Tag: value stream

  • Keys to Improving Enterprise DevOps Practices

    Keys to Improving Enterprise DevOps Practices

    As enterprises move to adopt DevOps practices, there is a desire to measure where teams are on their journey. This sometimes leads to the development of maturity models used to assess teams’ levels and progress. While I am not going to pass judgment on what might be useful for certain organizations, I believe that the real key is to drive positive DevOps practices, which include continuous improvement through data such as lead time, frequency of deployments and mean time to resolution (MTTR) (i.e. the key metrics from the State of DevOps Reports).

    Any static maturity model will become outdated. What’s more important is that teams are taught concepts that can help them continuously evaluate what is stopping them from delivering more quickly so that they identify areas for improvement. Key to this is the lean concept of value stream analysis. If you walk up to a team and ask them why they can’t go faster, they will typically say they are waiting for something. They could be waiting for more work to flow into their backlog. They could be waiting for infrastructure needed for development or testing. Or, they could be waiting for another team to develop a service they need to consume.

    Many teams don’t spend time in retrospectives talking about how to overcome these types of blockers or wait states and developing countermeasures as continuous improvement initiatives. One reason for this is the lack of objective data that can be analyzed to provide insights on this. This is where the lead time metric comes into play. Historically, lead time has been defined as (last) code commit to deploy into production. While this is important, it only tells part of story because accelerated delivery and feedback really starts with a customer concept and measuring how long this takes until it is delivered into production so feedback can be provided.

    One challenge to providing this kind of end-to-end metric, which spans the entire delivery value stream, is the lack of an integrated delivery pipeline from which data can be automatically collected. A customer concept starts in the portfolio space, which might result in data being entered in some type of PPM (portfolio management) system. Once approved, this results in features being created which eventually should flow into a product backlog. Stories are then created that can be pulled by the agile line supporting that product into an iteration. This information is typically in some agile management system (e.g. Jira or IBM Rational Team Concert). Then the team develops and builds the stories, tests them and deploys them into production via a deployment tool like UrbanCode. So, this flow of work goes through various tooling and generally is not visible or easily traceable across the value stream.

    Our initial goal in measuring lead time was to shift left and measure the time from story card backlog until the story was released into production. This would then give us four discrete measures that would provide more insight into the time spent in different parts of the value stream.

    1. Time spent in the backlog
    2. Time spent developing the story
    3. Time spent testing the story
    4. Time spent once the story was completed (marked “done”) until it was deployed

    We mapped the first and last categories into wait times and the second and third into process times to provide a baseline of this metric. While we have just started providing this information to teams, we are finding that scrum masters believe this type of data can be used in retrospectives to better understand why some lead times are high. They also believe that this will help the team better understand when blockers are encountered during development and testing and what contributed to them. We also plan to make that visible as part of our metrics (time spent in a blocked state). Tooling like TaskTop Integration Hub can help integrate your pipeline tooling to provide visibility and insight.

    Once teams gain more insight into what is slowing them down, they can identify countermeasures that can be applied. Categories of wait-states include:

    • Waiting for a dependent area to provide functionality necessary to complete a feature
    • SLAs associated with a service that is provided by a centralized organization (e.g. performance testing or security testing)
    • SLAs associated with infrastructure needed for an environment
    • Contention for a shared test environment

    Countermeasures associated with these types of wait-states are:

    • Architecture decoupling
    • Dark Launching / Feature Toggling
    • Expanding cross-functional teams to enable them to do self-service performance and security testing (at least some portion of it)
    • Automated Provisioning Capability for environment to avoid wait-states and contention

    The “State of DevOps Report 2017” contains information on the importance of architecture and how decoupling dependencies (using APIs and microservices) can mitigate certain types of wait states. DevOps Case Studies provides more information on applying DevOps practices such as dark launching.

    But again, at the heart of this is getting teams to think more about what their value stream actually looks like, how long it takes to deliver business value that can generate feedback and what is getting in their way of going faster. This is not a technology play. This is not something that somebody can sell or educate you on. This is something the team itself needs to take on.

    A good starting place for a team is to educate themselves on some of these concepts for DevOps practices using a book club. A great place to start is to study the “Phoenix Project.” This novel approach combines aspects of both DevOps and Lean to drive home some key points in the journey to discover types of work, manage work in progress and ultimately make visible and gain control over the work being done for the business. Once a team has an understanding of their value stream and blockers, they can then study the “DevOps Handbook” that provides practical guidance for improving their delivery capability and speed.

    About the Author / Carmen DeArdo

    Carmen-DeArdo-sqCarmen DeArdo is the director of Build Technologies at Nationwide Insurance. He is responsible for helping drive accelerated delivery utilizing Lean and DevOps techniques across the end-to-end delivery value stream.  One current focus area is the creation of an integrated delivery pipeline capability.

  • The Right DevOps Tools for Value Stream Velocity

    The Right DevOps Tools for Value Stream Velocity

    Think of DevOps tools as stepping stones to releasing new functionality into the hands of your customers faster and more frequently. Working together, tools automate processes and help companies become modern software factories. But isolated tools, like a lone rock in the middle of a river, are much less useful.

    Disparate tools may help an individual or a team do their job, but they impede the progress of the larger organization. To achieve desired efficiency across the application life cycle, companies may waste time and amass technical debt by integrating tools with scripts.

    The other answer is that organizations get restrictive. They may establish a “center of excellence” for DevOps that prescribes a toolchain that works together, but are those tools going to be the best fit for all individuals and teams, supporting an agile mindset?

    The ideal scenario is for a DevOps toolchain to become an integrated, dynamic continuous delivery powerhouse where “best fit” tools work in concert to enable better performing teams and better customer experiences.

    Start with the Right Tools for the Job

    DevOps teams are focusing on automating and streamlining all aspects of the application life cycle. It makes sense to choose the tool that’s best for the job. And teams should feel free to experiment and take advantage of new tools emerging every day that solve new problems or do a better job solving existing problems.

    Typical areas of DevOps tool investment include:

    • Planning and managing development work
    • Managing, tracking and documenting all code changes
    • Building, managing and deploying containers
    • Automating iterative builds/continuous integration
    • Developing and deploying to cloud platforms
    • Automating the deployment of applications into environments at all stages
    • Provisioning, configuring and monitoring environments
    • Managing all types of testing with the right requirements and data
    • Validating security before vulnerabilities become a problem
    • Promoting better agile team collaboration
    • Monitoring and managing an application in production

    These tool categories each serve a vital role in the application life cycle. However, there remains a significant lack of coordination and shared knowledge across the DevOps toolchain to generate the value stream velocity that can keep businesses competitive and customers engaged. For example, if a testing function is isolated, it becomes a black hole of activity and often a bottleneck to delivery.

    Build the Smarter DevOps Toolchain

    When teams can visualize, orchestrate and track the continuous delivery value stream from development through production, the pipeline becomes an intelligent entity of its own. How is the pipeline performing? How is it adding value to the organization? How do you improve the pipeline?

    For example, by integrating the planning and management solutions as part of the value stream, you can keep track of the user stories—including where they are deployed, what tests have been done and the results. Bi-directional integration enables automatic updates in the planning/management tool. Layer in collaboration tool integrations, and dev teams can get instant feedback and respond more quickly, shifting quality left.

    The result: real-time information and the ability to plan and prioritize more effectively. Release and development teams now have a shared view and understanding of release status and business implications.

    The testing function is another area where tools can work better together. Instead of sequential and separate functional, integrated, performance, API or security testing, you can build a testing workflow that runs in parallel, automatically promotes tasks, monitors progress and sends feedback of testing status. This can include orchestrating the generation of the right test cases, test data and virtual services for the app under test. With all the testing knowledge gathered in one place, it’s easy to see testing gaps and determine the risk of a release.

    Launch DevOps Mission Control

    A control center that manages the continuous delivery value stream can help teams not only manage the health and schedule of an active release more effectively, but it can also provide the visibility and analytics to help teams iteratively improve.

    There are a number of tools on the market that look beyond the silos of the application life cycle to connect and extract value from an end-to-end toolchain. As you assess tools that can enable a dynamic value stream, ensure they have capability in these five areas:

    1. Plug and play integrations: Does the tool support common DevOps plug-ins? How easy is it to integrate tools, whether they are open source, commercial or home grown?
    2. Full pipeline visibility: Does it enable orchestration and tracking of all releases at all stages—planning, development, test and production—including feedback loops and planning for the next release?
    3. Continuous quality: Does it support a shift-left testing model to ensure testing happens continuously and rigorously? Does it help you prioritize your testing and automate risk assessment for your releases?
    4. Business value alignment: Does it provide intelligence about the app content in the pipeline? Can you see what code is deployed where in the pipeline and its status? Can you map how the content of a release aligns to business priorities?
    5. Actionable analytics: Does it extract meaningful data points from pipeline operation to provide analytics that support real-time decisions, as well as inform improvements over time? Can you get insights into release and pipeline performance, testing coverage and speed, release readiness, team productivity, and so on?

    With intelligent integration of your DevOps toolchain you can increase your value stream velocity and deliver the best quality apps—every single time.

    — Patricia Johnson

  • 9 Lessons Learned: Getting Value Stream Insights in Only 2 Days

    9 Lessons Learned: Getting Value Stream Insights in Only 2 Days

    Gene Kim, Jez Humble and other experts say that understanding and improving your value stream is really what it takes to bring your software delivery organization to the next level. While almost every IT organization has this goal, actually knowing how to make it happen can be paralyzing, because it seems like such a daunting undertaking when trying to connect all of your systems tools and processes.

    Recently, we participated in an innovative approach that proved that you can take concrete and measurable steps and see real outcomes in only two days.

    Nationwide constantly strives to innovate and bring real change to its IT organization. The insurance and financial services company has zeroed in on improving its value stream. To begin the initiative, Nationwide developed a two-day workshop where the right disciplines would come together and determine the best way to make this happen. But the real innovation in this idea was that the organizers did not just talk about what to do. Instead, the end goal was to come up with at least one key metric the team could show to the Nationwide CIO by the conclusion of the workshop. This approach made the effort real, concrete and focused. While it was difficult, it worked.

    Here are nine important lessons learned:

    Lesson 1: Start with one artifact—specifically, defects. Measuring cycle time is extremely difficult because there are so many moving parts. To have a tangible outcome, start with defects because they tend to be the most well-understood artifacts and have relatively defined workflows and processes that people know and understand.

    Lesson 2: Commit to having a real metric based on real data. All too often organizations take the “boil the ocean” approach. When asked what metric they want to start with, the answer is typically, “Everything.” That is precisely the wrong approach. Aiming for everything is likely to get you nothing. Focus on a tiny amount to start. First understand, then improve, your software delivery value stream. Not only should you start small, but for IT value streams, start specifically with a certain artifact (see Lesson 1). And chose only one metric for that artifact, because less is truly more in this case.

    Lesson 3: Without a multi-disciplinary approach, you will fail. This part is extremely difficult. To be successful you will need the following mix of skills:

    • Domain Expert: This person knows this part of the value stream inside and out. She is a practitioner in that area of IT and truly understands the who, what, when, where and why of that particular area of the value stream.
    • Process Analyst: This person knows how the various people, systems and resulting artifacts are intended to operate together for the complete process. Often this person is closely aligned with the domain expert, but typically is not one of the practitioners actually participating in the process.
    • Data Warehouse Specialists: These are the people responsible for populating and managing the data marts or data warehouses. They need to have significant data transformation capabilities and intimate knowledge of the required data structures and formats the organization requires.
    • Report Writers: As often happens with the expertise required to wrap up a process, this role is sometimes overlooked at the beginning. This is not the right approach. The person who will report on the project should be involved from the very start.

    Some people might start by asking, “Don’t we need a data scientist?” After all, that is a title of authority when it comes to metrics. If you have a data scientist on staff, by all means, get them involved. But if you don’t, you can rely on someone with database skills—primarily, skills around writing advanced SQL (as old fashioned as that may seem). Most of this work will not require advanced data scientist skills.

    But the real challenge is to get all of those disciplines in the same room at the same time. This is no easy feat. Leadership must provide the necessary resources to ensure that each one of the roles is represented. Because if any of these roles are left out, you will not succeed.

    Lesson 4: Work in parallel. The process and domain experts can work on identifying the artifacts that must be used and manually identifying and mapping where the artifact originates, what systems touch the artifact when, and all the requisite status changes and their meanings. That work will inform the data warehouse team and report writers, but the data and report writers are actually faced with a very different problem: They must determine how to get the data, regardless of the identified artifact, and transform the raw data into a usable format that report writers and BI analysts can work with in their visualization tools. By having both teams work in parallel, with identified checkpoints along the way, you will be more efficient when it comes to the three required deliverables.

    Lesson 5: There are always three required deliverables for each value stream cycle metric you are interested in.

    • The artifact(s) of interest (defect, story, requirement, code commit, etc.)
    • The following data:
      • All required status changes and dates of changes,
      • Data to relate artifacts to each other (for the joins)
      • Any ancillary information needed to be able to slice and dice the data for the final visualization.
    • The final visualization showing the metric (which is typically not one metric but rather a macro metric that has drill down capabilities and other perspectives on the metric).

    Lesson 6: Work both forward and backward. It is always easier to get started when you know where you want to end up. In this lesson, identifying the end goal is key. Once you have identified the “end” then you can go to the beginning and determine if the end goal is actually reachable. You also can identify any holes that exist between the beginning and your end goal. In this use case, the backward story looks like this:

    • End Goal: A visualization (graph/chart) showing the metric of interest. The idea is to mock up exactly what you want the end result to look like. Create the mock up in the actual BI tool you intend to use as if you already have all of the necessary data at your fingertips.
    • Step 4: Provide the data needed to create the visualization—it must be formatted in a way that will enable the report writers to easily and efficiently create the visualization that is your end goal. Hint: start by creating a spreadsheet that contains the exact data structure and formats desired. You will use fabricated data to start. The idea is to make sure the data is structured properly to reach the end goal (the visualization).
    • Step 3: Create the interim views and tables that will enable you to get to Step 4
    • Step 2: This step is where you collect the raw data from the actual systems involved
    • Step 1: (The Beginning) Identify the artifact and all of the systems that artifact flows through.

    Lesson 7: Invite outsiders to participate. It’s difficult to see the forest for the trees in your own organization. You need outsiders who are willing to ask the questions, probe in challenging areas, push the boundaries—people who have a different point of view because they are not in the game. This does not mean outsiders should be the workshop facilitators. They could be, but it is more important for them to actually participate in the sessions and help define and create the deliverables.

    Lesson 8: Hold the workshop in a different space than you work in every day. Don’t use the conference room that you typically use. Bring the team to a completely different environment—one that inspires creative thought and innovation. It may seem like a fluffy requirement, but you will learn through workshop participant feedback that location has a major impact when it comes to productivity and focus.

    Lesson 9: Get executive leadership buy-in. The executive VP was genuinely impressed with what the team accomplished in only two days. And the positive feedback and kudos the team received has probably fueled their innovation engines for months to come. To feel a sense of accomplishment and be recognized by the executives in your organization has significant morale impact.

    Improving your value stream is no small feat. But by designing and executing on a workshop like this, you will see benefits and clear wins immediately. By the end of our two days, we had a prototype of defect cycle time and a defined repeatable process. Equally as important, the people involved were given the opportunity to fail fast and pivot where needed, which inspired innovative thinking and creativity. And, being able to present to the CIO real progress with real results in two days’ time fueled institutional buy in and momentum to drive a long-term value stream improvement program.

    About the Author / Nicole Bryan

    Nicole Bryan is Vice President of Product Management at Tasktop Technologies. Nicole has extensive experience in software and product development, focused primarily on bringing data visualization and human considerations to the forefront of Application Lifecycle Management. Most recently, she served as director of product management at Borland Software/Micro Focus, where she was responsible for creating a new Agile development management tool. Prior to Borland, she was a director at the New York Stock Exchange (NYSE) Regulatory Division, where she managed some of the first Agile project teams at the NYSE, and VP of engineering at OneHarbor (purchased by National City Investments). Nicole holds a Master of Science in Computer Science from DePaul University. She is passionate about improving how software is created and delivered – making the experience enjoyable, fun and yes, even delightful.

  • DevOps Chat: Mik Kersten, Tasktop on Value Stream Visualization

    DevOps Chat: Mik Kersten, Tasktop on Value Stream Visualization

    In this DevOps Chat, we sit down with Dr. Mik Kersten, CEO and co-founder of Tasktop. Mik besides being the founder of Tasktop, is also the creator of the Eclipse Mylyn open source project. Tasktop continues to lead the way in value stream visualization and software delivery integration.

    Mik gives us the latest on this and more in this conversation. Enjoy!

    Alan Shimel:               Hey, everyone, this is Alan Shimel, devopsy.kinsta.cloud editor-in-chief, and we’re here for another DevOps Chat. Our guest on this episode of DevOps Chat is Mik Kersten. Mik, for those of you who don’t know, he’s almost synonymous with Tasktop. Mik, welcome.

    Mik Kersten:               Thank you, Alan. It’s great to be talking to you again.

    Alan Shimel:               So how does it feel to almost be synonymous with your company?

    Mik Kersten:               Now that you mentioned it, it sounds good. It’s been an amazing journey with Tasktop. I think it’s just been a great now ten years of looking at how to bring those benefits of Agile and DevOps to large organizations. So it feels good is the short answer.

    Alan Shimel:               Another one of those ten year overnight success stories in the startup world. Mik, all kidding aside, there might be some people in our audience who aren’t familiar with Tasktop. So, if we can, just maybe a real quick 30 second sort of elevator pitch on what Tasktop is, what it does.

    Mik Kersten:               Yeah, absolutely. Most organizations now know that in order to get the up and coming productivity and efficiency that they’re after to be competitive in today’s world, they need to face an Agile toolchain and they need to deploy DevOps and continuous integration, and to do that you pick your issue tracking tools, your continuous integration tools, your release automation tools, and all of those bits and pieces. If you’re a large organization, you pick requirements management tools. If you’re doing any physical products, you need some additional tools for requirements and bills of materials and those kinds of things.

    What’s interesting is that once organizations scale up there are DevOps transformations. They’re both hitting more tools and different kinds of partitioners. So the missing piece for making all of these benefits of DevOps work at scale is this piece of integration infrastructure. We can connect up all the tools to get an end-to-end flow, so to get the benefits of Agile and Lean, all the way from business idea to running software and the revenue results and delighted customers.

    That’s what Tasktop has been doing. Over the last ten years, by release we’ve been connecting different stakeholders, processes and tools, so that you could have this end-to-end flow of information. So you could have the best of breed tools, the latest issue trackers or Agile planning tools, the latest continuous integration tools and so on, while getting this end-to-end flow, because really the problem that we’re addressing is that when you look under the covers in most transformations you’ll see that both DevOps and Agile have been deployed at these local optimizations. The team can do continuous integration or continuous delivery. Or the organization has continuous delivery, but has not optimized anything upstream, and that’s really the problem we’re trying to solve. Let’s get the entire IT organization to be Lean end-to-end.

    Alan Shimel:               Fantastic. Mik, in us talking before we started recording today, you said that the most recent release of Tasktop and the hub is probably the most important and meaningful thing you guys have done in ten years. Why don’t you share with our audience why you feel that way? What is this great functionality and great feature set that came out in this last release?

    Mik Kersten:               Absolutely. What we’ve noticed is that the way that – again, you take any large IT shop who has not yet deployed Tasktop and you look at how they support their transformation, and you’ll notice you’ll see all these point-to-point integrations. So you’ll see, let’s say, the Agile planning tool wired in through some APIs or Web hosts or some data integration technology into the requirements management tool, into the time tracking tool, into the quality management tool, into the automated test tool, into this _____ tool and so on.

    What we noticed four years ago is that the slave connecting things point-to-point was going to blow up. Once you’re making point-to-point connections, you get this exponential factor. So it’s okay if you’ve got two or three tools. All of a sudden you’ve got four or five tools. Just the sheer number of API calls are bringing down your servers actually.

    We know a lot of customers where they say their JIRA issue tracker is getting so many API calls from these integrations that it takes a minute to load an issue. So you get all these weird symptoms.

    You also get this thing that’s very difficult to maintain, because as soon as one tool changes or someone adds some new fields to a project’s definition of a user story or something of that sort, multiple integrations break and you’ve got this spaghetti code of Web host and API integration madness.

    So we realized four years ago we couldn’t even test all the integrations we’re supporting in that point-to-point way. It was already costing us hundreds of thousands of dollars of resources, of basically VM resources, just to test all the tools we support in a point-to-point based way. So we said four years ago, “We’ve got to stop doing things in a point-to-point way. It won’t scale. We need to support all the Agile and DevOps tools out there, and it won’t scale to supporting large scale DevOps transformations.”

    So we started creating this notion of models. First you look to open standards. So we got our feet wet and we on the committee of OSLC, but to get everyone to adopt open standards just didn’t work. And these tools are so complex because the stakeholder tools right now have become very elegant, basically. The developer tools are very tuned to the developer process, and with that comes a lot of complexity specific to developers, to testers and so.

    So we realized open standards won’t solve it. APIs alone don’t solve it, but are actually part of the problem. You need to take a different approach. So internally we made this integration factory so we could test everything, and we made these common models. The models are basically the currencies of Agile and DevOps and the ALM and SDLC systems, things like requirements, user stories, builds, releases, security, vulnerabilities, those kinds of things.

    That’s how we started testing everything and then we said, “Okay. If you raise the slave abstraction, it actually makes it much easier to connect everything. With last week’s release of the Tasktop Integration Hub, we’re actually taking that model-based approach and exposing it to all of our users. So you simply define all of your models in your value stream, again, like user stories, requirements, builds, releases, chain sets and so on, and then you plug in however many tools you want into those models and you get this amazing thing. You get complete automation for your value stream.

    So we’re calling that value stream integration, because end-to-end you can now have these flows and you can actually track things like cycle time, and you can basically get the benefits that a startup with 100 or 200 people is getting in terms of their speed of delivery at very large scales, at thousands or tens of thousands of IT staff. So you’ve got that value stream integration layer that we provide.

    With that, you can also inspect what’s going on and you can basically support these large scale Agile and DevOps transformation, all because of the fact that we’ve raised the slave abstraction to make these models, have you map your different toolchain in your models and, as a result of that, what we’ve actually done is we’ve made the toolchain itself be modular. So you can plug in best-of-breed tools Here’s some dot-net. Here’s some Java. Here’s some JavaScript there, maybe some Python for your AI. You can plug all of those separate tool streams together into one end-to-end unified value stream. Really, the key thing that we’ve done here, the game changing thing is this notion of model-based integration.

    Alan Shimel:               Excellent. I agree, Mik. You know what? Obviously you work at Tasktop. You’re very excited by what they’ve done. But for our audience out here who are generally pretty sophisticated technologists, I hope they appreciate really the – I mean it’s making people’s lives easier, right. When you can make people’s jobs and lives easier like that, it’s a good thing and this sounds like it could be a real game changer that way.

    Mik Kersten:               Yeah. Alan, that’s a thing that’s absolutely near and dear to me. My whole background was from productivity tools, empowering developers and taking the waste out of their day with all the open source work on Mylyn and the dev tools that we’ve done. Our mission was to bring about that change in the way people work at scale, because it gets even worse.

    You look at the large IT shops out there, the place where most of the world’s IT staff works, and we’ve measured what they do. Every developer or every tester, every business analyst, they’re spending at minimum 30 minutes, in some cases we’ve seen two hours per day of duplicate entering information for every code change they make, for example, because of all the governance and compliance and other rules which need to be there in large scale organizations, but all of that work is waste and it drives people crazy because they don’t like doing it, because it’s basically manual data entry.

    When you think of what it actually is, they’re entering information and logging into different systems, all of which could have been done automatically if, again, we took this value stream-based approach. You make your code change. All that information propagates into however many tools the organization had to set up. You might have to track different kinds of requirements and changes differently. That’s okay.

    So the most satisfying thing that we’ve seen with deployments of this, because we actually had customers in an early access program since April – the Tasktop Integration Hub is running in production at customer sites today – is that all of that waste gets taken out instantly. Basically our expectation is that the moment its deployed, and we’ve seen this, your employee engagement scores are going up that week or that month, that quarter, because you’ve taken out all that wasted work which drives the best people in their company crazy, the fact that you’re making them do it.

    So that’s our whole goal. The person goal is just make the lives of all those people in IT better by removing all that waste. Then of course the organization economic goal is through that: make your organization more innovative, because you’re now able to deliver at the speed of a startup and get that promise of DevOps at scale.

    Alan Shimel:               Absolutely. Mik, we’re running short on time, as we always are on DevOps Chats, but let me quickly pivot to something else I wanted to touch on with you, and that is the idea of the bridge of that job to DevOps or bridge between that job and DevOps. When I first started with DevOps four years ago, maybe more, five years ago, there was, “Well, DevOps really picks up where Agile leaves off,” but they were clearly two separate things. Agile is for developers. DevOps is for everyone.

    But what we’ve seen is that DevOps is borrowing more and more from Agile, more and more from Lean. Where do you see the connection between Agile and DevOps, if that makes sense?

    Mik Kersten:               It’s by different thought leaders, different vendors and so on. In the end, it’s all the same thing. It’s Lean for software and software at scale. So in terms of how organizations have aligned, I think what has happened is that so much of the bottleneck for software delivery for so many large organizations has been in deployment reliability and velocity and automation. DevOps has formed the big new movement and really picked up as a movement where Agile left off.

    In the end, the technology is you need continuous delivery. You need to implement continuous delivery, but the DevOps movement has come from that side, from development and operations and said, “We need to deliver things faster, more reliably, and automate all the stuff that’s manual in their account.” That’s actually shifted and taking over where the Agile movement started, which is we need to track work and be responsive to change and bring customers into the feedback loop.

    So there are two key components and I think the sheer velocity that we have right now behind organizations going to DevOps has made it the more important transformation agent. Everything that was going with Agile stays as a key part of the transformation. I think it’s very important for those leaders out there, putting together those DevOps transformations to not stop at code commit.

    You have to actually take the Lean fast feedback loop, continual learning all the way into business analysis, design and so, because if you stop you’re going to have to solve the deployment bottleneck, but not the upstream bottleneck. For example, if you don’t have enough UI designers, it won’t matter how quickly you’re deploying. You’ll do bottlenecks on your UI design. You’ll need to higher there.

    So I think we all need to take this end-to-end Lean view and DevOps is just a great transformation agent and a great movement to help us all do that.

    Alan Shimel:               Good stuff. Mik, we’re coming up to the end of our time. I want to ask you one last question, not a trick question, but I always like to ask if possible. For our audience out there, if you could recommend one book that they read, and not an obvious one, don’t tell us The Phoenix Project or even the DevOps Handbook. It doesn’t have to be DevOps related. What book would you recommend?

    Mik Kersten:               I’m holding it up right now. I know you can’t see it, but it’s the book Learning to See by Mike Rother and John Shook. If you even just flip through this book, you’ll see the value stream mapping and value stream integration and management approach that make the manufacturing work. As we go into this post-DevOps, post-Agile bigger picture world, it’s that same view of the value stream, focusing on the end-to-end value stream that I think need to inspire that next generation of leaders creating these transformation.

    I think the DevOps Handbook contains a lot of this. It’s a great book. I’m nearly finished reading it. It has a lot of the right sources, but in terms of something that you might not have seen it’s this Learning to See book, which is really about learning to see production. We need to learn to see the flow of software across the value stream and most organizations have not done that yet, and that’s really – our mission is to help organizations do that, but the ideas are here. We’ve done them before. Again, it’s been done in manufacturing and now it needs to be applied to software delivery.

    Alan Shimel:               Fantastic. Mik Kersten, Tasktop, thanks for being this episode’s guest on DevOps Chat. Continued success and looking forward to more, and maybe seeing you at DevOps Enterprise Summit in London.

    Mik Kersten:               Absolutely. Thank you, Alan. Great chatting with you, as always.

    Alan Shimel:               All right, Mik. You be well.

    Mik Kersten:               Thank you.

    Alan Shimel:               This is Alan Shimel for devopsy.kinsta.cloud.

    — Alan Shimel