Tag: IT innovation

  • Using DevOps to Be an Innovation Champion

    Using DevOps to Be an Innovation Champion

    Innovation, which increasingly is cited as the competitive advantage businesses need to meet their digital challenges, is widely misunderstood; it’s mistakenly reduced to the sophisticated features of a technology or a service.

    As a competitive matter, innovation is more than that; it’s primarily the process of translating ideas or inventions into high-value technology features or added-value services. In other words, to be called innovation, a technology or a service must satisfy a specific need and create value for customers.

    DevOps is very often seen as the perfect means to make an IT organization an innovation champion, it’s true. Yet, many CIOs and their solution vendors and consultants have failed to achieve that goal because they’ve oversimplified the process. DevOps is part of the process, not the process itself. DevOps isn’t the end but the means.

    In this article, I share two fantastic concepts—Innovation Virtuous Circle (IVC) and Value Stream—we leverage at ITaaSNow to enable DevOps and transform in a record time IT organizations into innovation champions.

    Define Your Strategy with the Innovation Virtuous Circle

    Making innovation your organization’s main competitive advantage isn’t as simplistic as investing in the most sophisticated technologies; it starts with defining your strategy, continues with implementing it throughout your IT organization’s value stream, and ends up with getting it adopted across your business.

    Improvisation and organizational transformation aren’t good friends. Rely on proven frameworks that safely guide the effort step by step; it’s the purpose of the IVC—it facilitates and accelerates the innovation strategy definition effort:

    The Innovation Virtuous Circle (IVC)

    The principle underneath the IVC is the notion that keeping customers loyal through innovation guarantees continuous revenue. The idea is, the more innovation, the more loyal customers and the more revenue.

    Put together your business and IT stakeholders to discuss the means by which customers will be kept loyal to ensure continuous revenue. Follow the steps suggested by the IVC:

    1. Clarify the agile processes and practices, the tools, skills and partners by which customer data will be captured and tracked for analytics purposes.
    2. Identify the agile analytics processes and practices, the tools, people, skills and partners that’ll help to spot innovative ideas, solutions and technologies.
    3. Clarify the agile processes and practices, the tools, skills and partners needed to ensure high frequency, high quality and speedy innovation delivery.
    4. Identify the agile processes and practices, the tools, people, skills and partners that’ll help to monitor customer satisfaction and improve customer experience.

    What you get out of this step is a comprehensive strategy including the targeted customers to keep loyal, the estimated expected revenue along with the organizational capability to achieve them.

    Reconfigure Your IT Value Stream with DevOps

    Once your innovation strategy is defined, the next step is to use the value stream framework to deploy it throughout your IT organization.

    The value stream represents the added-value interactions, people and skills, processes and practices and tools mobilized throughout your IT organization to deliver innovation:

    The Agile IT Value Stream

    It conceptually structures the IT organization’s value stream into a four-stage agile process. Each stage is associated with a specific goal and mobilizes specific elements of your innovation strategy.

    Again, put together your business and IT stakeholders to address the following:

    1. For Plan & Measure, discuss your future governance’s structure, members and roles, agenda along with the tools and infrastructure supporting your analytics-based innovations screening and prioritization and portfolio management processes.
    2. About Develop & Test, get a consensus on the staff to assign, the agile methodology along with the continuous testing and integration infrastructure that will support your innovation development processes.
    3. Regarding Release & Deploy, discuss the staff to assign, your release management and launching processes along with the continuous deployment infrastructure needed to support them.
    4. As for Monitor & Improve, discuss the staff to assign, your service continuous improvement processes, along with the analytics technologies intended to support them.

    What you get is a comprehensive and documented blueprint of your IT organization’s value stream transformed to DevOps. Use it as a baseline to hire the solution vendor and consulting firm that’ll concretely reconfigure your IT operational model to innovation.

     Wrapping up

    Using the concepts of IVC, Value Stream, and DevOps to establish IT operational models that boost innovation is a transformation approach we’ve been using to make businesses innovation champions.

    All of the companies that replicated the organizational transformation approach described in this article are:

    • Rolling out per year more than 20 services and products qualified as innovations
    • Either doubling or tripling their revenue
    • Keeping loyal 98 percent of their customers

    That’s the kind of contributions and impacts your business unit leaders expect from you as the CIO and your IT department.

    — Philippe Abdoulaye

  • 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.