Scaling Agile Across the Enterprise: An Interview with Kelley Blue Book

At Agile 2015, we had the opportunity to interview Stacy Lin, senior director of product intelligence at Kelley Blue Book, to find out how their organization is using VersionOne to successfully scale agile project management.

In the video below, Stacy talks about Kelley Blue Book’s positive relationship with VersionOne. As their agile needs have grown, VersionOne has been with them every step of the way.

Highlights

  • Kelley Blue Book’s transition proved successful and now VersionOne is implemented across many Cox Automotive business units
  • VersionOne offers a single, common platform to manage and prioritize work
  • Kelley Blue Book benefited from flexibility to meet the needs of Scrum and Kanban teams
  • Cox Automotive now has the opportunity to build an agile community of knowledge within the organization

Challenges

Kelley Blue Book, the only vehicle valuation and information source trusted and relied upon by both consumers and the automotive industry, started implementing agile in 2005. Initially, the teams began with sticky  notes to manage their backlog, stories and tasks. However, as the organization scaled agile in 2007, they realized they needed an online solution that could help them efficiently manage complex projects. Particularly when it came to reporting on the velocity and other metrics, they needed an alternative to the manual effort of entering data into Excel and SharePoint.

Solution

After an extensive evaluation of several agile lifecycle management solutions, Kelley Blue Book selected VersionOne because of its usability. They had a pilot for eight weeks with two teams – one on-shore and one off-shore. The teams not only found the solution easy to use, but they also increased productivity.  As a result, the management team decided to roll VersionOne out to all of Kelley Blue Book.  Since then, VersionOne has scaled with Kelley Blue Book’s agile adoption and now has more than 250 users on the platform. The use of VersionOne has been so successful, that the solution been implemented in many of the business units throughout Cox Automotive, Kelley Blue Book’s parent company.

Benefits

According to Stacy, “Kelley Blue Book and VersionOne have been very good partners for more than eight years. As agile adoption in the software development industry has grown, VersionOne  has continued to add new functionality to support the needs of enterprises that are scaling Agile. VersionOne has been a great support in our Agile journey.”

Now Kelley Blue Book and the other Cox Automotive business units have a common platform and a consistent language to easily manage their Agile initiatives. For example, when it comes to managing its top-rated website (KBB.com), an extremely large and complex website, the product managers and Scrum teams have the platform to efficiently manage their work at all levels. In addition, the Portfolio Kanban Board in VersionOne provides one clear view of where all the epics and portfolio items are in flight, so the leadership can see progress at-a-glance and make sure that teams are aligned with business priorities.

While the organization’s agile transformation started with just Scrum teams, over time there were teams that preferred Kanban. The inherent flexibility with VersionOne allows teams to use different methodologies and still provide an integrated view of all  agile initiatives in one platform.

Now that VersionOne has been implemented across Cox Automotive, the organization can share and start to build a community of knowledge. For instance, at the annual Cox Automotive Agile Open, all of the business units get together to talk about their agile practices and learn from each other.

Please visit VersionOne’s YouTube page for more video interviews.

 

Posted in Agile Project Management | Leave a comment

4X Faster Time to Market: An Interview with Autotrader

4X Faster Time to Market: An Interview with Autotrader

We recently had the opportunity to interview Nick Park, director of experience delivery, and Sherolyn Sellers, manager, process delivery at Autotrader, to find out how their organization is using VersionOne to successfully scale agile.

In the video below, Park talks about how the structure and flexibility of the VersionOne Enterprise Agile Platform is helping teams produce great working software significantly faster.

Highlights

  • Time-to-market four times faster
  • Visibility into key performance metrics to ensure business alignment
  • Flexibility to support different methodologies – Scrum, Kanban and SAFe
  • Easy to adopt and implement
  • Excellent support

Challenges

Autotrader, a leading online resource for car shoppers and sellers, is part of Cox Automotive. The entire organization was committed to the idea of agile at scale from the start, so instead of just focusing on agile as a technology team transformation, they looked at the positive impact that agile could have across all the disciplines within the company.

Solution

Autotrader started their agile implementation with a small pilot program with cross-functional team. The team decided to use VersionOne to give them a structure to get started with agile processes and their transformation.

After the initial pilot, other teams started asking to get into the system, so the organization selected VersionOne because of its ease-of-use, simple implementation and excellent support. It was very important to get team members up and running with the system quickly.

Autotrader took a planned approach to their implementation to make sure that they were setting up the structures of the actual work, matching it to all the portfolios, and adding team members as it made sense. The progress of adding new users has climbed steadily as they have added teams, and now they have more than 200 users on VersionOne.

Benefits

With the kick start from working with VersionOne, Autotrader has seen immediate results. The teams were using VersionOne to establish their agile processes and make changes to adapt to their business along the way. After three months, the teams were building momentum and producing working software.

In fact, Autotrader is introducing new releases at least four times faster than before implementing VersionOne now that they have the structure, processes and the visibility to more efficiently manage the work. In addition, defects are decreasing and product quality is increasing because of the level of detail that the teams can capture in the solution.

Stakeholder satisfaction is extremely positive now that the organization has the visibility to manage team velocity, project burndown, and other key performance metrics to make sure they are on track with the goals of the business. Now executives have easy access to the data they need to see progress and make more informed decisions on the prioritization and sequencing of projects. In addition, since Autotrader is part of Cox Automotive, they are adding new procedures and processes so they can start to visualize how projects are aligning with the corporation’s strategic view.

As Autotrader has grown, the fact that they have been using VersionOne since the beginning has allowed them to scale agile without that ever being a concern. Currently the organization has more than 20 Scrum teams and is managing projects at multiple tiers. Autotrader managers are able to use the epic board to see how work is flowing through the system, understand how expectations are being met, and identify any roadblocks or dependencies that need to be resolved. VersionOne has become a critically important system of record.

It has also been important that the inherent flexibility in the VersionOne platform was able to support different roles and methodologies. Autotrader has Scrum and Kanban teams and they are also using the Scaled Agile Framework® (SAFe®). Even though the teams leverage VersionOne in different ways, they have a common platform for overall reporting to make sure there is alignment with the portfolio and initial investments from their leadership.  In addition, the ScrumMasters and Kanban leads have the platform to start building their own community of practice.

According to Sellers, “Hands down, the teams love VersionOne. I have implemented several solutions throughout my career and this is one of the easiest for the users to adopt and use right away. In addition, the support has been great. There’s not a single time that I felt like I was ‘on an island’ and couldn’t get answers to our questions in a very timely manner.”

Please visit VersionOne’s YouTube page for more video interviews.

Posted in Agile Project Management | Leave a comment

Faster Time to Market: An Interview with Cerner

At Agile 2015, we had the opportunity to interview Matt Anderson, director, Cerner Technology Services, to find out how their organization is using VersionOne to accelerate speed to market and increase throughput to stay competitive in a rapidly changing industry.

In the video below, Matt talks about the organization’s partnership with VersionOne has helped them align its people, processes and technology to realize significant results from agile over the past seven years.

Highlights

  • Time to market reduced by 75%
  • Productivity increased by 24%
  • Development costs reduced by 14%
  • Turnaround time for resolving critical defects reduced by 50%

Challenges

In 2009, it was typically taking Cerner’s development teams about 30 months – from concept to client adoption – to introduce major innovations. Cerner knew it had to accelerate its products’ time to market to help clients navigate health care reform and to stay competitive in the rapidly changing industry.

To achieve this, Cerner’s developers needed more agility in their software development processes. The solution was the adoption of agile practices across the enterprise. Matt Anderson, director, Cerner Technology Services and Cerner’s leading agile champion, calls the company’s approach “pragmatic agile.” In other words, the enterprise focuses on ensuring that agile principles and values are followed and the teams decide the agile approach they will take.

Successful organizational change must simultaneously incorporate people, process and tools. While Cerner had a great team who was committed to agile processes, they needed an enterprise agile application lifecycle management (agile ALM) platform that would enable the people and processes to succeed. After reviewing several options, they selected VersionOne as their primary tooling partner.

Solution

Cerner has more than 3,000 developers, with teams having different needs, different markets, and different preferences in the way they work. Scrum works best for most of their teams, while other teams prefer Kanban, XP, Lean or other variations.

The company selected the VersionOne agile ALM platform because it had the flexibility to accommodate the various agile methodologies being implemented. In addition, they found the platform intuitive and easy to use. “People can focus on doing the real work of software development,” explains Anderson.

Benefits

For Cerner, success was about having more time to focus on adopting the agile framework rather than adopting a tool. The VersionOne platform’s inherent ease of adoption enabled Cerner to quickly start seeing the benefits of agile – in this case, a 75% reduction in time to market. Other measurable improvements include:

  • Productivity increased by 24%
  • Development costs reduced by 14%
  • Quality improved by 6% based on internal KPIs
  • Turnaround time for resolving critical defects reduced by 50%

In addition, by choosing VersionOne, Cerner development teams can estimate software delivery more accurately, allowing them to forecast and consistently meet their commitments to stakeholders. Developers can identify problems earlier and make midstream adjustments very quickly. And teams can innovate and test prototypes because VersionOne is adaptable enough to support changes to the underlying process.

The flexibility of the VersionOne ALM platform promotes a proactive approach to problem solving across the enterprise. Instead of reacting to issues, Cerner can develop solutions that prevent issues from arising. The flexibility also allows teams to try different things. If the experiment works, Cerner teams incorporate it as a part of their process. If the experiment doesn’t work, they just throw it out and try something else. As Anderson says, “That’s the true spirit of retrospectives.”

Another key benefit of VersionOne is the ease of creating roll-up reports with the ability to drill down from big picture into what teams are doing. With VersionOne, Cerner’s leadership can get a one click view of a release at any point in time. They no longer needed to deal with project management via spreadsheets or Visio, which often contained outdated information and rarely provided the needed level of detail.

“VersionOne is a great partner,” said Anderson. “The company continues to innovate to meet the needs of the agile marketplace. They are justifiably one of the top agile ALM vendors.”

Please visit VersionOne’s YouTube page for more video interviews.

Posted in Agile Project Management | Leave a comment

Happy Holidays from the VersionOne Team!

Happy Holidays from everyone at VersionOne! We hope your holidays will be filled with joy and laughter through the New Year. We’re so grateful for our amazing customers, partners, and friends in the growing agile community.  So we wanted to share our seasons’ greetings in a video featuring the people that power VersionOne. Have fun watching and let us know what you think!

Posted in agile | 8 Comments

7 Ways to Get Started with DevOps Today

DevOps_7_Ways_General_500x250
Transitioning to a DevOps approach can be a confusing and daunting prospect. Looking at organizations that practice DevOps, we may see a completely foreign landscape with a different organizational structure, practices, and an array of new DevOps tools for us to learn.

It’s easy to forget that those companies took a long time to get where they are and that they started with much smaller, much simpler steps. One of the challenges organizations face is that they think the smallest first steps take months and loads of training. In this article, I’m going to discuss seven very small steps that you can start today. Many of these don’t require you to buy new DevOps automation tools or make changes to your organization. They can be done by the CTO or by an interested developer or system administrator. Most importantly, they can be done today; between meetings, during lunch, or on a train ride home.

1)  Invite Your Operations Team Into Your Development Process

Though it may seem obvious, this small change is one of the most often overlooked. This doesn’t need to be a big organizational change. Having an operations team member attend the development team’s standup meeting or a developer sit in with the operations team while they conduct a deployment is a great way to start. The whole purpose of DevOps is to bring these two groups together and the best place to start is small interactions with the members of both teams.

2) Visualize the Work Together

This goes hand-in-hand with bringing operations into your development process. If you’ve got a Scrum board or Kanban board, add a few columns to the end of it – even if it’s as simple as “Waiting for Deployment” and “Deployed.”  It’s a small change, but it sends a clear message that the work isn’t done until it is deployed and usable. After all, that amazing feature doesn’t help anyone while it’s sitting in the code repository.

3) Automate Your Test/Build Process

OK, this one definitely involves solutions, but it isn’t as difficult as you might think. VersionOne offers demonstrations of its new Continuum™ for DevOps solution, while other free continuous integration tools exist. Grab a copy and run it on your local machine. Within an hour or so, you can have yourself set up to check out the code from source control, build the project, and run the unit tests. Once that’s working, you can set it to run each time code is checked in to the repository. Congratulations! You now have information about how often your check-ins build and run all tests successfully. You can even set it to send a notification when it fails and provide fast feedback to your whole team. You aren’t quite at continuous integration yet, but it’s a big step in the right direction.

4) Create a Deployment Plan

Does your company set aside nights or even whole weekends for deployments? Do unexpected problems always crop up resulting in a mad dash to get the system live before your maintenance window runs out? If so, don’t worry; you’re not alone. Many applications and systems evolve over time and maybe you don’t have a good understanding of what libraries got installed to make it work or what system configurations got changed. If you had to deploy your application from scratch, what would you do? This question may lead you to many other people and departments. Once you’ve got a plan, try it out. You may find some holes in your plan. You may also find that there are some complexities in your current environment that don’t need to be there.

5) Identify Fragile Systems

Are any steps in your plan or systems in your deployment problematic? Most application environments have at least one system or component that they would consider fragile. Perhaps it’s an old web server that never quite deploys correctly or a script that works fine until you try to change something. These will be prime candidates for your DevOps efforts. Creating transparency and DevOps automation around these items will make your deployment process faster and easier.

6) Smooth Out Wait States

If fragile components are the biggest pain point in the deployment process, wait states are a close second. Most processes have more time built into them just waiting for people than they have time with actual work being done.  Try thinking through your process and identifying where these wait states are occurring. Then share this with your development and operations teams. See if there are a few wait states you can smooth out.

7) Link Your Work to Your Value

Most of the points I’ve discussed are technical, but remember what’s driving DevOps. The reason we follow our process through deployment is because our hard work isn’t producing value until it’s in front of a user. The closer we get to the code and configuration, the more our language starts to focus on commits, builds, and artifacts. Try using business language like features and functionality in your deployment plans. Not only will this connect you more to the value your work is delivering, but it will also keep you thinking about what else needs to make it through the deployment process. Maybe this feature isn’t available until the server upgrade happens. Was that worked into your deployment process? What about the important configuration change?

Then What?

If you take these small steps, you’ll already be well on your way to a strong DevOps culture. But what about all those solutions you hear about? As you expand your DevOps effort, you’ll find that many of them are indispensible. The question is: which ones? Going through these initial steps can give you an understanding of how your team operates and gets its work in front of users. Once you know that, you’ll really be able to get the most out of those solutions. So learn more about how your team works, then dive into all of the amazing solutions out there to help you work better.

Posted in DevOps | 2 Comments

Better Visibility of Complex Agile Projects: An Interview with CareerBuilder

At an Agile Day Atlanta event, we had the opportunity to interview Andy Krupit, the manager, agile development, and Thomas Connell, the team lead, corporate applications support team, at CareerBuilder about why they selected VersionOne Ultimate edition.

In the video below, Krupit talks about how they significantly improved tracking and reporting of complex projects for a global organization which helped them decrease defects by 25%.

Here are some key takeaways from the videos:

Highlights

  • Improved visibility into projects
  • Enhanced tracking of key metrics
  • Decreased defects 25%

Challenges

CareerBuilder has the largest online job site in the U.S. and the global leader in human capital solutions and has agile teams around the world. Initially CareerBuilder’s agile teams were using whiteboards and post-it notes to manage projects. The CIO saw the success of these teams and decided to scale agile across the entire IT organization.  This created a lot of remote teams and the whiteboards and post-it notes just weren’t working anymore. They tried to use some non-agile project management tools they already had in place, but nothing replicated the success they had using whiteboards and post-it notes. They needed an online solution that reproduced the visual and tactile benefits of physically moving cards across a whiteboard in front of their teams.

 Solution

After an extensive evaluation of several leading agile lifecycle management solutions, CareerBuilder was confident that VersionOne provided the best combination of online boards, custom workflows and access to the data. The online boards and custom workflows enabled the remote teams to replicate the success they had with colocated teams and the data allowed them to track progress in ways they couldn’t with whiteboards and post-it notes.

Benefits

“VersionOne provides everyone, from executives to developers, visibility into how we are progressing toward our business goals,” says Krupit. “Before VersionOne they could not efficiently track metrics, but now CareerBuilder is able to help individual teams continually improve quality. In fact, since CareerBuilder implemented VersionOne, defects have decreased 25%.”

Please visit VersionOne’s YouTube page for more video interviews.

Posted in Agile Project Management | Leave a comment

Improving Product Quality with Agile: An Interview with ABB Enterprise Software

At an Agile On Deck event, we had the opportunity to interview Scott Madden, senior director, product operations at ABB Enterprise Software, to find out why the organization selected VersionOne Ultimate edition.

In the video below, Scott talks about how they increased on-time delivery to 91%, decreased the defect backlog 40%, and decreased defects released to the customers 30%.

Highlights

  • ABB transitioned 800 team members to a single enterprise agile platform and agile methodology in seven weeks
  • On-time delivery has increased to 91%
  • Defect backlog has decreased 40%
  • Defects released to customers has decreased 30%

Challenges

ABB is a world leader in electrical engineering comprised of nine separate business units. Each of ABB’s business units was run by a product manager who had their own processes, architecture, and tools. Management was manually collecting and consolidating spreadsheets from disparate teams all around the world. In addition, ABB’s siloed product management organizations made visibility into the progress of the entire enterprise portfolio extremely difficult. The senior leadership team recognized that they needed more visibility across the nine business units to improve on-time delivery and product quality.

Solution

ABB transitioned 800 team members from using different tools and development processes to using a single enterprise agile platform and agile methodology in seven weeks. After an extensive evaluation of several leading agile solutions, ABB was confident that VersionOne provided the best combination of enterprise agile software and guidance from enterprise agile transformation experts to help them go from multiple teams with different methodologies and ways of reporting to a single system that brought them all together.

Benefits

Since ABB implemented VersionOne, the defect backlog has decreased 40%, defects released to customers have decreased 30%, and on-time delivery has increased to 91%. VersionOne gives the ABB leadership team get greater visibility to see how individual teams are progressing. Before implementing VersionOne, it was nearly impossible to track quality on a team-by-team basis. But now ABB is able to help individual teams continually improve quality and accelerate delivery within the context of the enterprise portfolio.

According to Madden, “VersionOne is not just a vendor. They are a partner. From implementation all the way through the life of our relationship with VersionOne, I believe it will be a world-class experience.”

Please visit VersionOne’s YouTube page for more video interviews.

Posted in Agile Project Management | Leave a comment

DevOps Trends: Adoption Expanding in Enterprises

During a recent webinar series on “Building a DevOps Culture & Infrastructure for Success,” we asked the audience to rate their confidence with knowing what features and/or fixes are in any given release. We were surprised to find out that only 12% were really sure that they could describe the functional changes within any given release with precision.

To help us further understand and overcome the barriers to realizing the vision of DevOps, we recently surveyed enterprise IT leaders to get their insights on DevOps adoption.

Here are the DevOps Adoption Survey results:DevOps Adoption Rates

DevOps Adoption Moving Into the Mainstream

Approximately 73% of the respondents are currently using DevOps for production systems, pilot programs, or they plan to adopt DevOps in the next 24 months.

 

#1 Driver for DevOps – Improve Quality, Consistency & Repeatability

DriversHistorically, the need to increase deployment frequency has been cited as the primary factor driving DevOps initiatives. However, this seems to be changing. In our survey, the desire to improve quality, consistency and repeatability was the highest rated DevOps driver (88%). The need to increase deployment frequency has dropped to the second most common driver (62%) followed by the need to reduce failure rate of new releases (57%). As DevOps practices move further into the enterprise, increasing the overall quality of software delivery may be overshadowing the need for speed.

DevOps Success RatesDevOps Adoption Increasing, But We’re Still in the Early Learning Stages

Only 33% of the respondents said that DevOps has been successful, while 54% said that DevOps has been moderately successful, and 13% said that it has not been successful.

 

 

DevOps_Efficiencies

Need to Improve Ability to Track the Flow of Business Value

Perhaps one of the biggest takeaways from our DevOps survey was the need to increase the overall organizational proficiency of tracking the flow of business value – from idea to production.  Approximately 88% of the respondents gave their organization a moderate or low efficiency rating for their ability to track and manage features and/or fixes.

Number of SystemsThe Number of Systems Are Part of the Problem

Part of the challenge may be the number of systems that need to be accessed in order efficiently manage and track features and/or fixes. Nearly 85% of the respondents are reconciling multiple systems to identify the business work items included within a specific environment or release at any given point in time.

Cumbersome Manual Processes Add Extra Effort

DevOps ProcessesIn addition, 87% said that pulling a list of features and/or fixes is manual – either very manual with spreadsheets, etc. (29%) or partially manual by combining and/or aggregating data generated by automated tools (58%).

 

 

 

Challenges Due to Disconnected and Fragmented Delivery Tools

So what are some of the challenges that organizations have experienced due to the disconnected and fragmented delivery tools? Here are some of the specific quotes from the survey respondents:

“Missed priorities, missed opportunities and rework”

“Delayed delivery and compromised quality”

“Bad code, bad data, no change management, lack of understanding”

“No traceability and no one knows what is in given releases, raising necessary questions”

“Manual deployment of the features has a high margin of error”

“Unknown and untested code making it to production. Incomplete functionality being delivered.”

“Re-work, extra effort, release delivery risks”

“System in off line for many minutes”

“Functional outages and degraded performance due to not deploying an integrated set of changes – code, database, and configurations – with specific features”

“Conflicts between delivery teams working on related (known or unknown) systems”

“Lack of confidence about possible errors”

Introducing Unified Software Development and Delivery

In my last blog post, I explained that while propagating the vision of DevOps has been a success, executing against it often remains challenging – especially in the enterprise. I believe that successfully unifying plan, develop, validate, deploy and run workflows is still challenging for two fundamental reasons:

  1. Plan and develop work items (features, fixes, stories, etc.) are not directly linked to operational outputs (builds, artifacts, environments, etc.)
  2. Lots of fragmented automation make it difficult to orchestrate and creates many pockets of siloed data.

In order to make the vision of DevOps a reality, a truly unified platform that supports the end-to-end delivery stream – from idea to production – is a primary requirement. The VersionOne® Continuum for DevOps solution is one example of this type of platform.  For more information, visit https://www.versionone.com/product/devops/

Posted in DevOps | Leave a comment

How Unified Software Development and Delivery Makes the Vision of DevOps a Reality

2 Barriers to Unifying Dev and Ops

What are the two barriers to unifying Development and Operations?

Are you finding that DevOps is more vision than reality? Here’s how you can unify the systems that DevOps workflows depend upon to help make your DevOps vision a reality.

DevOps Can Be More Vision Than Reality

The DevOps movement has provided organizations building software with a vision of increased deployment frequency, product quality and mean time to recovery gained from improved collaboration and automation.

While propagating that vision has been a success, executing against it often remains challenging – especially in the enterprise. Ultimately the DevOps movement seeks to tightly unify Dev and Ops workflows, but so far two systemic barriers have kept these functions from becoming truly unified.

2 Barriers to Unifying Dev and Ops

I believe successfully unifying plan, develop, validate, deploy and run workflows is still challenging for two fundamental reasons:

  1. Plan and develop work items (features, fixes, stories, etc.) are not directly linked to operational outputs (builds, artifacts, environments, etc.)
  2. Lots of fragmented automation make it difficult to orchestrate and creates many pockets of siloed data.

1. Development Workitems Are Not Directly Linked to Operational Outputs

devops-part-1-500

 

 

 

 

 

 

 

In any software delivery process, there is an inherent disconnect between development workitems and delivery outputs. The image above highlights a common pattern that organizations adopting DevOps face regardless of their level of DevOps maturity. This platform disconnect between functional workitems and delivery outputs makes it very difficult to truly unify development and operations.

Starting with the green box on the left, you have a simple representation of the agile development process. The main units of flow moving through the development organization’s storyboards have traditionally been workitems such as features, fixes, stories, epics, etc… However, once these development initiatives get converted into builds or artifacts and deployed into environments, the linkage gets muddy. At that point, “release” or “deployment” units of flow are only loosely affiliated with their corresponding workitems back in the agile storyboard on the left.

Feature attributes such as cycle time and current status can be tracked accurately while moving within context of the development storyboard, but manual updates to that data are required during downstream delivery. This creates a very weak understanding of the real-time flow of value once you get beyond the planning tool and into the downstream and more “operational” software delivery process.

According to a recent DevOps Survey conducted by VersionOne, more than 87 percent of respondents indicated that multiple systems are required to manually cross-reference features and fixes with their corresponding builds, artifacts and environments. This problem then gets magnified as functional changes “queue up” in later stage environments between release events. This lack of automated manifest reporting makes it increasingly difficult to express with certainty which workitems are included within specific artifacts and deployed into specific environments at any given point in time.

Here are a few questions that are typically difficult to answer with absolute certainty:

questions-500



 

 

 

 

It will continue to be difficult for all stakeholders across the end-to-end delivery pipeline to collaborate at the highest level if Dev and Ops platforms are not truly unified. Building DevOps maturity mandates a tight linkage between functional workitems and corresponding delivery outputs to streamline the flow of value and simplify cross functional collaboration.

2. Automation Processes and Tools Are Fragmented

fragmented-500

 

 

 

 

 

 

 

 

A clear and positive outcome of the DevOps movement is the emergence of a plethora of point process automation tools. These tools have been important enablers of DevOps practices and have dramatically reduced the amount of time required to validate, deliver and manage new software. However, the primary data models of these DevOps automation tools are wholly unaware of concepts such as features and fixes. Since these workitems represent the actual “content” flowing thru automation, visibility and traceability at the feature/fix level is critical to driving efficiency in a DevOps setting.

The image above depicts the fragmented delivery environment that frustrates our ability to link delivery outputs with functional workitems. This graphic was shared with me recently by an organization trying to enhance their ability to track the flow of value, in real-time, thru their delivery pipelines. If DevOps is a priority at your organization, this example is probably similar to what you have now or what you will have in the not too distant future.

As this very busy diagram indicates, the DevOps automation tools we depend upon to move value from the initial commit all the way out to production are continuously generating important audit, test and deployment data at every stop across the delivery pipelines. However, this data is often under-leveraged and buried deep inside tools completely unaware of the features and fixes flowing thru them.

Because of this fragmentation and lack of context, it is very difficult to provide critical status and audit data back to DevOps stakeholders. Without a unified development and delivery platform, correlating data generated through delivery pipelines back to specific features and fixes will continue to be a largely manual, error prone and time-consuming process.

4 Costs of Dev and Ops Not Sharing a Unified Platform

The costs of development and delivery not being unified is a missed opportunity. While small and incremental gains toward end-to-end unification have yielded progress, the reality is that most enterprise software development organizations are still struggling to improve:

value-stream1. Value Stream Efficiency

Because of the units of flow problem, stakeholders don’t have automated visibility into the status or and/or deployed location of the features and fixes flowing thru a delivery pipeline. As a result, manual effort is required to perform continuous business-to-operational cross-reference reporting and analysis that introduces material and unnecessary overhead into the software delivery value stream.

continuous-improvement2. Opportunities for Continuous Improvement

The plethora of fragmented point automation generates siloed data that is difficult to access and correlate back to a discrete set of features and fixes without significant human intervention. This fragmentation makes it difficult to collect meaningful statistics that can identify bottlenecks across the entire software delivery chain. This data is the crucial fuel required to drive the kind of continuous process improvements needed to materially increase delivery frequency and shorten time to market.

software-quality3. Software Quality & Failure Rate of New Releases

The lack of end-to-end visibility into the entire value stream makes it difficult to know with absolute precision which functional changes have been included in any given build or artifact. This reconciliation process is almost always manual and is susceptible to errors that increase the odds of deploying unstable or incomplete “work-in-progress” into critical environments.

meantime-recovery4. Mean Time to Recovery & Slower Analysis

The lack of detailed end-to-end delivery accounting and audit history, at the business level, frustrates the ability to find root cause and issue repairs for issues and defects once uncovered. Additionally, this un-correlated data makes it difficult to perform the detailed analysis needed to identify system or process failures that caused the introduction of critical production defects in the first place.

What Is a Unified Software Delivery Platform?

devops-part-2-500

 

 

 

 

 

 

In order to make the vision of DevOps a reality, a truly unified platform that supports the end-to-end delivery stream – from idea to production is a primary requirement.  A crucial capability to achieve platform unification is the ability to link together all of the data generated throughout the delivery process. If data can be gathered and correlated at the time of creation, a comprehensive dashboard can be created that supports real-time collaboration across stakeholders.

Most organizations that have multiple agile teams are already using some sort of agile lifecycle management platform to manage priorities and coordinate development activities. By reimagining our storyboards as development, validation, and deployment orchestration hubs, we can unify the planning and development platforms with the infrastructure required to support downstream automation – without ripping out or replacing any of the tools and technology you’ve already implemented.

By leveraging centralized pipeline orchestration, you can better track work items as they move from one stage to the next in your storyboard. Because the orchestration layer understands automation in context of the features and fixes flowing thru it, stories can now be directly associated with the artifacts, builds, config files or deployments, linking these two traditionally decoupled platforms.

When your storyboard is linked with all the DevOps automation tools that move changes from the first commit all the way out to production you can begin to capture and associate the important audit, test and deployment data generated at each and every point within your delivery pipelines.This is the type of unified software delivery platform that can help make the vision of DevOps a reality.

screenshot

 

 

 

 

 


Here are a few characteristics of a Unified Software Development and Delivery Platform:

  • Unified DevOps repository that can support robust cross-referencing between business value (features/fixes) and operational objects (builds, artifacts, deployments).
  • Ability to visualize, measure and optimize the journey of features and fixes from idea all the way to production deployment.
  • Robust pipeline orchestration that leverages existing DevOps automation and eliminates or minimizes the need for manual handoffs.

The 5 Benefits of Unified Software Development and Delivery

increased-collaboration1. Increased Collaboration Across All Disciplines

Product Owners, Project Managers, Developers, Testers, and Ops team members can more easily collaborate because business work items are linked to delivery outputs providing visibility, traceability and clarity across the entire value stream.

increased-automation2. Increased Automation and Streamlined Value Streams

The plethora of fragmented point DevOps automation tools are now orchestrated by the unified DevOps orchestration engine, reducing the need for human intervention.


increased-deployment3. Increased Deployment Frequency & Shorter Time to Market

With clear visibility of the entire value stream it is much easier to make the continuous process improvements that can increase delivery frequency and time to market.

improve-software4. Improved Software Quality & Reduce Failure Rate for New Releases

The ability to automatically cross-reference any build or binary to the features and fixes included within – with absolute precision – greatly reduces the chances of testing in the wrong environment, accidently promoting works in progress or items with unmet dependencies. This capability results in higher release quality with less wasted manual effort.

shorter-meantime5. Shorter Mean Time to Recovery & Faster Analysis

Unified audit and traceability throughout the entire software delivery process – from idea to production – will make it much easier to uncover issues prior to deployment. When defects do reach end-users, post-mortem root cause analysis can occur in minutes instead of weeks, uncovering root cause and prevent issues from recurring.

Conclusion

The independent evolution of planning platforms, build automation, testing and release management tools has created a profound and systematic data division between Dev planning platforms and Ops automation. As long as these disconnects persist, achieving the key DevOps ideal of cross functional collaboration and streamlined process flow is challenged.

Unified Software Development and Delivery is the process of merging these two universes to provide a comprehensive and end-to-end value stream that documents the flow of business value from idea to production. The VersionOne® Continuum™ for DevOps solution is one example of this type of platform.  For more information, visit https://www.versionone.com/product/devops/

Posted in Continuous Delivery, continuous improvement, Continuous Integration, DevOps | Leave a comment

“When will it be done?”

Sometime last year, I started working with a Fortune 100 company on a large, distributed product development effort. There were many “refactoring opportunities” – a term a friend once used to describe my code. Like many large efforts spread across locations, there were many constraints.

One day, towards the beginning of the engagement, we were pragmatically introducing agile practices and principles when one of the executives decided to pay us a visit. After a few friendly greetings, he walked up to me and said “So you’re the agile guy,” using a tone which sort of left me feeling like a suspect who has just been targeted and painted with lasers. He then asked the question in the forefront of his mind “When will it be done?”

For the first time, I suddenly realized the power of “It.” Without much thought, I quickly replied with the facts: “From what I know, no one has done a good job answering that to date.” Not knowing much about the project, but wanting to provide context, I followed up by saying “Agile methods will help us be able to tell you what is done which is the strongest evidence we might have to when it will be done.”

From Project to Product

For years, I have been helping leaders understand how to use agile methods by reframing the discussion. In this case, I might defend this executive by guessing that “When will it be done?” was the only question he felt he could ask. It could be that he had no other questions in mind, or it could be that past progress data has been so weak or non-existent, that all or nothing investigation was the path of least resistance with the best results to date. It could also be that the question comes from the years of conditioning around asking “When will it be done?”

All or nothing thinking is deep in the ethos of many companies. It may be that this is merely an organizational, or industry, norm that is well established. If, like me, you’ve been in the game for a bit, there is an interesting and unnamed progression that contains the agile movement and provides a challenge for its future.

If the 1990s were the decade of project (on time, on budget and within budget) then the 2000s could be viewed as the decade of process (or progress). The rebels who spawn the various methodologies later branded as “agile.” were frustrated by a lack of real progress. You could think of this progress as moving from 60% of 100% in the 1990s to 100% of 20% in the 2000s.

continuum

 

 

 

 

This change is so much more important than “Who is agile and who is waterfall?” This change allows for investors to use the whole product (100% of x%) as a way to validate or invalidate their investment, and possibly choosing to change their overall portfolio investments. Or put another way, it allows for a shift from “on budget” to “is valuable.”

What’s the next best investment?

Often overlooked and under discussed, agile practices have provided a way to shift toward questioning investments based on incremental evidence of completion. Teams who are in earnest embracing and practicing agile methods often move toward progress as more of a constant. With less worry about “What will we get done?” the new, and more ambiguous question, becomes “What should we get done?”

Scan the figure from left to right again, and you’ll see a progression of certainty. As cycle times for learning decreases, in the form of iterative product increments, we are able to more quickly assess how wrong we were. Using an analogy, if your car is (or was) an unreliable piece of junk, you head out on a journey wondering if you will make it to your destination. If your car is a trusted delivery vehicle, you are freer to wonder about other questions like “Do we still want to go there?” or “How are the passengers doing?” or other more valuable, non-progress based questions.

Refactoring Our Rhetoric

Changing the dialog from “When will it be done?” to “What is done?” provides an alternative question and new perspective. It challenges both investors (the executive) and producers (the teams) to shift towards validating products and user experiences that are “good enough.”

Concretely, let’s explore a few refactorings that surface when you make the switch to 100% of x%:

  • Planning for complete user experiences supports customer empathy as a guiding force
  • Validation over completion introduces a sort of test driven product which routes out waste
  • 100% of x% injects the idea of evaluating value returned for product increment investment

While there are many others, let’s explore these three, starting with customer empathy. Thinking in chunks of product, like user experiences, and the validation of each chunk tends to more quickly surface “the who” aspect of product development.

Customer Empathy: The product community in this example was building a game. Games provide a nice basis for validation because play is part of the product. Being overly certain about who might like what is a great way to build the wrong game. Simple tools like pragmatic personas now become powerful validators that can stop the building of the wrong thing simply by challenging the experience a player might have.

Incremental Validation: There are more companies than I’d like to admit who are working hard to build the wrong thing faster. Or put another way, they are so overly certain that they need to “get it done” that they fail to validate it until there is a ton of it in play. Moving away from it and towards incremental validation of a meaningful user experience, helps learning happen sooner. It’s not mutually exclusive with agile practices, but learning from meaningful user experience does not simply happen just because you are working sprints.

Iterative Evaluation: The best way to measure (evaluate) is to test in the market. This is easier for some products than others. For example, it’s easier to deploy and validate a mobile ready web app than it is to do the same for a pace maker. As these are obvious extremes, your product most like sits on a continuum between the two. Ask yourself what you could do to slide towards faster market validation, sooner, is a strong, simple take away that you can reflect on immediately.

More pragmatically, when you shift toward 100% of 8% (as an example), you can then ask, “If the first 8% was a poor return, should we still do the other 92%?” Or, you might find that by simply asking how you are going to evaluate that first 8%, you step into a deeper level of early product validation thinking that is often missed when people over focus on “How much can we get done in this sprint?” or as was the case with the executive in my experience, staying stuck in the land of “When will it be done?”

But so many people are all about “It”?

After reading this, you’ll find your awareness of “It” as a singular measure is more prevalent than you knew. Most common “Its” live in larger planning where investors are not aware of the power of incremental validation, or eco-systems where all the investors hear is agile speak instead of product speak or validation language.

If you are an executive, an influencer, or a big boss type, I challenge you to refactor the “its” you hear towards smaller chunks of meaningful investments. If the word smaller vexes you, then shift to an investment mindset: assuming that some investments pay more return than others, what is the right place to invest just enough to learn where you should invest next?

If deep in your brain, you are still thinking about building software like buying bonds, you need to refactor that metaphor towards hedge fund trading, where a series of small failures are wildly overwhelmed by the large returns around them. If you knew what stocks to buy, you would. Since you don’t you are forced to engage investments with a measure of certainty or an awareness of uncertainty and an eye toward measuring and adjusting based on the evidence and your experience.

If none of that works, buy a copy of Antifragile by Nassim Taleb. He seems to know more about agility that most coaches I know. I mean, look at the title, it contains both fragile and agile in one word.

 

 

Posted in Agile Analytics, Agile Project Management | Leave a comment