Lean Transformation Predictions for 2016
Lean Transformation Predictions for 2016
Predictions include the waning of SDLC, agile thriving, and DevOps and dev tools driving disruption in the industry.
Join the DZone community and get the full member experience.Join For Free
Over the course of 2015 I got exposed to many companies going through Lean software delivery transformations — some very successful, but many less so. Tasktop’s customer base grew dramatically in 2014 and that growth accelerated in 2015. So I decided to put conference presentations on pause and instead spend more of 2015 on the road meeting with Tasktop’s customers to better understand their transformations. The tally for the year was 180 customer meetings spanning 100 flight segments, with some amazing conversations that were all about some of the largest and most interesting lean, agile and DevOps transformations happening in the world’s largest organizations.
Over the course of this year I plan to publish more on what I’ve learned, since getting this in-depth visibility into the software lifecycle architecture of such a broad range of the world’s leading organizations was so eye opening. Most leading IT organizations are going through some kind of lean transformation. The ones that succeed in accelerating software delivery will thrive. Those who fail will fall behind. And those who take no action, but continue down the complacent road of delivering software in the slow ways of yesteryear will be displaced by their nimbler enterprise counterparts, or by startups. This will happen much more quickly than they realize. One of the most interesting things I learned was just how fast the return on investment from a successful transformation is, which spells market-changing dynamics for the Have and Have Nots of software delivery transformations in 2016 and 2017.
But for now, let’s take a quick look at the trends that drove change in 2015, and map that out a few of the factors that will help drive success in 2016, illustrating the points with a couple of Google Trends charts.
ALM and SDLC are Being Displaced By DevOps
In tech startup circles DevOps became a hot topic three years ago, to the point where not having DevOps automation in place seemed as silly a not having a version control system. A startup would have no hope of competing against others who have put this kind of automation in place, so there is no question of whether or not you’re doing DevOps, just of how. What struck me over the course of 2015 is how many of Tasktop’s very large new customers purchased our product as part of a centralized DevOps integration initiative. So while sitting in a talk at this year’s DevOps Enterprise Summit, I became curious about the use of the term and fired up Google Trends. I was happy to see that in the last quarter of 2015 DevOps surpassed the SDLC and Application Lifecycle Management terms (as well as variants like ALM and ADLM).
There is a very good reason for this. Just as version control and continuous integration systems forced us to automate builds, DevOps is forcing us to automate how we manage software software delivery. This is the obvious and critical next step in the end-to-end automation that’s needed for a Lean software lifecycle. Organizations that succeed in their DevOps transformations in 2016 will outperform those who don’t. Organizations that ignore DevOps in 2016 will have a hard time catching up with their competition in 2017.
What’s most critical about the DevOps transformations is not the name it falls under, but the act of automating all aspects of work intake and delivery. Some of Tasktop’s biggest customers are doing this transformation under a “Lean SDLC” initiative, which can smell just as sweet.
Stakeholder-specific Tools are Driving Transformations
This next chart highlights another key trend: tools are driving transformations. Atlassian’s JIRA tool is nearly as popular a term as “Agile software development” itself. And the Git version control system blows everything else away. These trends are indicative of what’s happening across the industry. Agile has come of age and as a methodology, has matured. This has made it possible for all of the Agile tool vendors to capture Agile practices and processes within a similar feature set. The result is an ongoing standardization of Agile tooling and tailoring to various types and scales of delivery. In 2013 we would often hear of leading organizations doing an Agile transformation. Now we’re as likely to hear that an organization is adopting one or more of Git, JIRA, TFS, Jenkins, Puppet, Chef, uDeploy, Selenium, Sonar, and ServiceNow, along with a list of very special-purpose tools that just keeps growing.
This trend is indicative of shift in that for many organizations the bottoms-up adoption of dev tools is driving change at an even faster rate than the top-down introduction of new development methodologies. Those that have had the pleasure of reading Gene Kim’s Phoenix Project will recall the emphasis on the “Four Types of Work” (Business Projects, Internal IT Projects, Changes, and Unplanned or recovery work). The trends that we’ve seen in tooling represent the burning need of organizations to explicitly track all work intake that drives changes to the software that drives the business. The rapid rise and IPOs of companies such as Atlassian and ServiceNow happened because these tools started out by being very good at tracking a particular kind of work (eg, JIRA for development and ServiceNow for IT project management). Adoption of this new generation of working tracking and collaboration tools is driving change in large organizations at an increasingly rapid pace.
While some IT organizations are rightly concerned about this kind of unorchesterated bottoms up change introduced by the dev tool flavor of the day, what I’ve noticed from the most successful organizations is that they have embraced this disruption. They acknowledge the bottoms-up pull from their staff and provide them with modern tracking systems for capturing all work. The fact that there are systems in place for tracking all work is more important than what the tools are. For example, in the top 10 most successful transformations that I’m aware of, the systems in use for tracking Agile development include Atlassian JIRA, IBM Rational Team Concert, Microsoft Team Foundation Server, Rally (now known as CA Agile Central), and VersionOne — and more often than not a combination of those and others. These companies are not successful because of the system they selected, but because they have ensured that all work is tracked. Tracking and prioritizing all work intake is as important a pillar for transformation as automation is.
Putting It All Together
Connecting the dots in the trends discussed above implies that the key to a successful transformation is to automate everything and to capture all work in tracking systems. DevOps transformations require a level of automation and organizational responsiveness that’s disruptive to the old way of doing things, but critical to delivering value at the pace that customers now demand. The new generation of tracking tools is the only way to manage and prioritize work with the new pace and volume of delivery.
But ending up with a bunch of automated and tracked organizational siloes is not enough. In 2016 the most successful organizations will use scaled Agile, DevOps and integration to connect software delivery in a Lean value stream. Scaled Agile processes that span work tracking tools will connect the business to development, while a DevOps transformation that spans Dev and IT will connect delivery. The need for an Agile and DevOps integration hub has emerged as the fabric that connects every person in the organization not just to their team, but to the entire value stream. The end result is an integrated Lean software value stream that will provide a 10x improvement in the speed and quality of delivering business value for the organizations that adopt it. I very much look forward to working on that with our customers over the coming year, and helping drive the economic impact that will come from transforming how enterprise software is built.
Published at DZone with permission of David Shepherd , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.