I went back and looked at some DevOps predictions from last year around the same time. I had given a quote to DevOps Digest, predicting that DevOps would grow closer to the heart of the business in 2017. I saw then that KPIs, metrics and data would become more of a focal point for organizations moving forward with DevOps initiatives.
VP of Product Management and Strategy at CollabNet, Eric Robertson, predicted in an article in the DevOps Summit Journal that analytics would play a bigger role in DevOps tool integration and that these two, along with early testing, would be significant points of discussion for IT leaders in 2017.
As we look back on the year — the unique opportunities it presented, the challenges we faced and the decisions we made as a company — CollabNet learned a thing or two (or a dozen) about DevOps. And though some things change—and we are always learning—some things stay the same. Which is why this year, when I made predictions about priorities for DevOps in 2018, my thinking wasn’t revolutionary.
Some of the trends we talked about at the beginning of 2017, like measuring DevOps success, have grown in importance over the past year. The hunches Eric and I had at the end of 2016 were confirmed as we sat in conversations with company after company that needed a way to connect and measure the new efforts and tools it had adopted.
In fact, the needs we have seen in the software delivery industry for the last decade have not changed significantly. What has changed are people’s attitudes and folks’ willingness to change a company culture, adopt new ideas and evolve their organizations — and that makes me excited for 2018.
In 2018, I see three major pillars for DevOps success. These will be three main themes of discussion. Organizations who pay attention in all three of these areas are going to see software development and delivery blossom in a new way as they strive to modernize processes and practices with Agile and DevOps.
This image illustrates the SAFe Continuous Delivery Pipeline. The pipeline begins with continuous exploration – the process of going through and understanding what we should build and why we should build it. In the middle is continuous integration. SAFe will have a deeper focus on CI which has historically been relegated to the process of making sure code gets into the baseline. The final two pieces are continuous deployment and release on demand.
This continuous delivery pipeline highlights that you want a continuous flow of value as the features are being ideated. You want to have releases ready to deploy but you want to choose when it is that you do your releases.
SAFe Epics & the Lean Startup Build-Measure-Learn Cycle
The Lean Startup focuses on building systems that people haven’t used yet. SAFe will start managing epics through the Lean Startup Build-Measure-Learn cycle. Epics generally involve building systems that people haven’t used yet.
SAFe will begin approaching epics a little differently than we have traditionally with just breaking into features. It is more beneficial to talk about the MVP of epics and then go through the process of evaluating that MVP through the Lean Startup continuous feedback loop.
SAFe & Lean UX
Lean UX is not about pixel perfect designs that navigate well and follow style guides. Lean UX is about hypothesis driven development. And as soon as you say hypothesis, either In the context of Lean Startup at the epic level, or Lean UX, the feature level, it changes the expectations.
Because if we’re talking to our executives and managers, customers and key stakeholders and we say we’ve got a feature, and it has a hypothesis, well that automatically communicates the fact that there’s no guarantee that what we’re about to do is the right thing.
Melding these Lean Startup and Lean UX principles together gives us a stronger view of scope management, and it simply assumes scope management instead of assuming that everything you build is the right thing from the get go.
And that means that our feature definitions need to change. Each feature in SAFe should have an outcome hypothesis. For example, your goal maybe to reduce downtime 80%. Now we know what success looks like, not just what done looks like. It’s not a matter of that we did it, it’s a matter of we delivered the value that we intended to deliver.
Avoid the Branch and Merge Problem
SAFe will start taking a higher level view of continuous integration. We’re not talking strictly about how my code gets in the baseline. We’re talking about how features leave the program backlog and make their way into continuous integration.
What you see in the image above is a mainline that’s continually growing value. That means that every team is working from the latest revision of all the work. This avoids the branches and the branch and merge problem. Now we have a way to think about feature level CI, not just code level CI. Features are driven by an MVP implemented with an outcome hypothesis.
New Two Week System Increment
SAFe will have a system increment every two weeks. We have to be careful how these features move into a more continuous delivery environment. In order to evaluate your system increment and run the system demo, you’ve got to make sure that those features work or are toggled out so they don’t disrupt the existing functionality.
We can’t deploy a bunch of functionality and then hope in a month or two it works. We’re going to bring that integration back together every two weeks and we continually verify it via acceptance test and NFR testing.
CI at the Value Stream Level
The entire solution needs to be integrated at the value stream level for organizations running multiple ARCs (Agile Release Trains). Above you see how during each increment we build the small pieces value and then at the solution level each arc contributes its stuff again to the mainline.
A CALMR approach to DevOps
There was a period of time which DevOps was described as CAM; culture, automation and measurement. Scaled Agile Inc. is extending that to CALMR; culture, automation, Lean flow, measurement, and recovery.
DevOps is a CULTURAL shift first
It is no secret that DevOps is a cultural shift. In the enterprise there are VPs of Dev and VPs of IT service management who have different plans, responsibilities, cultures, and backgrounds. With DevOps these teams have to work together. So we need a culture of shared responsibility.
We can’t look down the DevOps with the assumption that nothing will fail. That requires shifting operations responsibility upstream. At the same time, operations responsibility follows the work from upstream.
AUTOMATE the deployment process
Why is automation so important? It’s the same story we had with testing. If you can’t automate testing, you can’t do agile. How come? Well because in agile we create a small incremental system and in order to know the system works, we have to test it. Manual testing isn’t efficient, so we automatically run a batch of tests. In a similar manner, we need to automate the pipeline.
Enable LEAN Flow
We want to run the smallest economic batch. Reducing batch size is the goal of almost all of our processes. It increases predictability and reduces re-work. The notion of batch size and lean flow is absolutely integral to DevOps.
Build for RECOVERY
DevOps measures everything. You move from asking what’s important to measure, to measuring every function point in the system. You can easily have application telemetry that reports thousands and thousands of data points in the combine system. That’s okay, it’s all automated and we only need that data, right, when something goes wrong.
Architect for Release-ability
The average DevOps conversation is a discussion about deployment automation. But that DevOps conversation needs to be elevated to what happens when something goes wrong.
Visibility is Key
You can’t manage what you can’t see. As we start to think about moving our features through to production we have to start thinking about not just the descriptive elements of how the system is supposed to behave, but how that gets converted to the packages that we actually release.
Kanban for DevOps
Lean, DevOps, and Kanban fit well together. If you want to measure and understand what’s flowing through the system you’ve got to know what’s important to you. So, above you see our default Kanban, this will appear as a new default program Kanban in SAFe sometime soon.
Release On Demand
What does release on demand mean? It doesn’t mean release all the code you have to the user whether they want it or not. Releasing is not a monolithic practice. Develop multiple cadences to release on demand.
It’s not the full system that gets released. You want to start architecting the system in such a way that you can do what you need to independently of everything else. So In the same way that we can release independently over time, we can release independently of each other. We can start thinking about much smaller value streams, value streamlets, that are the things that become the target of your DevOps function.
This overview is just a portion of the guidance provided in our recent webinar. Check out the full webinar on demand to get practical guidance on scaling DevOps with SAFe.
How well do your DevOps metrics provide insight into the speed, risk, and quality of software delivery? Watch this video to learn the four most critical measures of DevOps performance.
4 DevOps Metrics to Improve Delivery Performance - YouTube
In the video I talk about how at VersionOne we put a lot of thought in what it takes to create a data-driven devops organization and it starts with flow metrics.
We have a challenge in devops. The minute we convert backlog items into source code and then convert that source code into binary artifacts, we lose all visibility into flow. It’s very difficult to track a specific backlog item in the form of a binary artifact as it moves through every single stage of our value stream.
Visualizing Delivery Flow
Creating the capability to track backlog items through delivery is the first step to solving this challenge. We call that affiliation. It’s the ability to affiliate a specific backlog item with specific code and then connect that code to specific artifacts to be able to track those artifacts as they move from phase to phase to phase, and therefore the story moves from phase to phase to phase.
Visualizing Portfolio Delivery Flow
Tracking the flow of backlog items across each step in your value stream map is important, but often what people really care about are combinations of backlog items, like features and epics. A product owner might have a question about what’s the distribution of this epic across my value stream map right now, or how much of this epic has already been delivered to my end users? It would be great to understand if every single backlog item in a feature made it to a specific stage in your value stream map. Having that kind of visibility is really important.
The next step in creating a data-driven organization is to take this real-time visibility and start to convert it into flow metrics that provide objective measurements of how your value stream is performing.
The first flow metric that we have to consider is lead time. That’s how long it is taking for the average work item to travel from development all the way to the end user.
Delivery Work In Progress
The next set of metrics that we have to track are work in progress (WIP). We do a really good job of understanding work in progress through development, but the minute we start converting backlog items into code and then convert that code into artifacts and binary objects, it becomes really difficult to track work in progress as those binary artifacts move through each phase of delivery.
Touch Time & Wait Time
Being able to understand and visualize work in progress, even after stories get coded into binary artifacts and understand exactly how much value we have stacking up at every phase of delivery. For example, how much work in progress do we have in staging right now?
The next set of metrics that I think are really important and really helpful. Some other concepts that we borrowed from Lean are the notion of touch time versus wait time. Where touch time is the amount of time we actually spend adding value to a user story or defect, and wait time is the amount of time it’s been stationery waiting for some next step, some next activity.
If you can calculate touch time, if you can calculate the wait time, at a work item level, that starts to provide some really powerful information. If you know the cycle time through a particular phase of delivery, so for example through the quality assurance phase. If I can express my touch time and my wait time, I can now start to look at:
How efficient is this phase?
What’s the ratio of touch time over the overall cycle time of that phase?
That starts to show us where the waste is, where the friction and where the opportunities are to start streamlining flow.
It’s good to understand over the course of a release for example, what percentage of work has been introduced into this release that can’t be tied back to specific business value. What’s the percentage of rogue commits for example?
In addition to simple risk measures like the percentage of rogue commits in a code base, we’re starting to imagine some real innovative and exciting ways to think about risk as backlog items move through our value stream maps.
One of the ones that I find most exciting, is cyclomatic complexity or fragility. We’ve been able to measure the cyclomatic complexity and fragility of our code base for years and we’ve got great tools to help us do that, but what we haven’t been able to do until now is start to measure the cyclomatic complexity or the fragility of specific backlog items. For example:
Specific user stories
Specific features for example
Or, answer questions like, what’s the relative fragility of release A compared to release B or release C.
Rate of Change
One last class of metrics that I think is interesting with regard to risk is change visibility. We can now track how dynamic our code base is through various stages of our value stream. We would expect our code base to be very dynamic in early stages of our devops value stream, but as we get through closer to quality assurance or certainly beyond the definition of done or beyond code complete, we would expect that code base to be very stable.
Being able to understand the rate of change and how dynamic our code base is, as we approach various stages of delivery, is important because the more change we have later in the value stream, the more risk that we have. I think there’s a lot of study and research around the risk in late stage change, but providing that visibility to all stakeholders and being able to measure that objectively, is really important.
We’ve talked about some flow metrics, and some risk metrics. These are just a couple of examples of how you can begin to build a data-driven devops organization and ultimately help you get good at getting better.
DevOps is bringing about unprecedented changes in the way that organizations are solving problems and breaking down silos. Organizations are empowering their employees to automate expensive manual processes and utilize the power of cross-functional teams to improve the entire organization’s agility. DevOps is helping to bridge a culture gap and focuses on providing shorter feedback loops and more responsiveness to failure.
But what if we are missing something else here? Do we really know how much all of these process and automation improvements cost? Do we really know if we are improving our products, processes, organizations and DevOps as a whole?
In this talk, you will see why we need to know that we are providing more value, can make good decisions based on risk and are actually improving the quality of our systems. You will see how we should do this and why it will be great for DevOps continuous improvement!
[IGNITE] Measuring DevOps To Provide Objective Continuous Improvement In Your Org - Logan Daigle - YouTube
This talk was presented at DevOpsDays Charltotte 2017. DevOpsDays is at the forefront of shared knowledge, collaboration, culture and inclusion of developers, operations and anyone involved with technology.
Are you considering or currently practicing the Scaled Agile Framework® (SAFe®)? Learn how leading software organizations succeed with SAFe and the VersionOne Enterprise Agile Platform in this overview of our webinar, SAFe Made Simple with VersionOne.
The VersionOne Enterprise Agile platforms supports SAFe and allows organizations to:
Quickly set up your SAFe Portfolio structure
Align strategy with delivery using Strategic Themes and Budgets
Plan and track progress at all levels of the portfolio using multi-level Kanbans
Ensure cross-team alignment during PI Planning with the Program Board
Establish PI Objectives, assess business value achieved, and track team PI performance and program predictability
Include Scrum and Kanban teams in the same program
Track SAFe metrics
Sustain collaboration and continuity across your organization with communities of practice
Seamlessly incorporate DevOps and maintain visibility of business value all the way to your customer
Enable SAFe Across the Enterprise
VersionOne provides a centralized environment that simplifies your adoption and implementation of SAFe, supporting SAFe’s constructs, practices, and metrics. This includes communities of practice and DevOps.
We frequently collaborate with Dean Leffingwell and Scaled Agile Inc. to ensure that the VersionOne platform provides strong support of SAFe as it evolves. You can always feel confident that as SAFe delivers new constructs, practices, and metrics, VersionOne will be enabling you to support them.
Managing Value Streams
In the top-right corner of the SAFe diagram, you can see SAFe’s primary construct, the value stream. Success with SAFe depends on organizing around value streams as opposed to individual projects.
Identify Value Stream Inefficiencies
The value stream construct is a Lean concept that can be traced back to the Toyota Production System, Deming, and even is referenced in a 1918 book by Charles E. Knoeppel entitled Installing Efficiency Methods. The essential activity of value stream management is to identify your value stream’s delays and waste. Addressing those delays enables you to improve overall value stream lead time.
Value Stream Visibility Challenges
In most software organizations, the measurement and improvement of the value stream is limited to the value creation portion of the stream. This is the part of the value stream that includes planning and development. It ends when the user stories are done.
Losing Business Value
This is a challenge because our value stream hasn’t actually realized value until something has been delivered to the customer. This is the value delivery portion of the stream. In most enterprise organizations, this part of the value stream is a black box — except to the people whose job it is to package and deploy software.
This means that the people involved in planning and development lose sight of the value they’ve created once it gets handed over for packaging and deployment. It also means that the people packaging and deploying code are in the dark as to what business value is being delivered.
In other words, the business value visibility, which should be continuous throughout the entire value stream, goes dark as you cross over into the delivery part of the value stream.
Why Tracking Business Value Through Delivery is Important for SAFe
1. Delivery and DevOps are going to receive much more emphasis in the SAFe this year.
2. VersionOne maintains business visibility across the value stream, measures DevOps performance, and improves enterprise agility.
I hope this overview helps you better understand SAFe value streams. This was just a portion of the guidance provided in our recent webinar. Check out the full webinar on-demand to get practical guidance on simplifying SAFe with VersionOne.
Here’s a list of agile and DevOps influencers that you should be following in 2017. Improving enterprise agility by truly unifying agile and DevOps is a huge trend for 2017 and these influencers can help you ensure that your organization is successful making that transformation.
Influencers are in alphabetical order by last name.
Scott Ambler is the Senior Consulting Partner of Scott Ambler + Associates, working with organizations around the world to help them to improve their software processes. He provides training, coaching, and mentoring in disciplined agile and lean strategies at both the project and organizational level.
Sanjiv Augustine is the president of LitheSpeed, an agile consulting, training, and product development company. With 25+ years in the industry, Sanjiv has managed agile projects from five to more than 100 people, trained thousands of agile practitioners through workshops and conference presentations, and coached numerous project teams.
Sally Elatta is the creator of AgilityHealth, a comprehensive Agile assessment and organizational growth tool developed for organizations that have adopted or scaled Agile and want visibility into the performance and health of their teams. She is passionate about helping teams and organizations do what they do better using Agile, Lean, Scrum, Servant Leadership, Collaboration Skills and other tools.
Joshua Kerievsky is leading an effort to modernize Agile by removing outdated practices and leveraging the best of what the software community and other industries have learned about achieving awesome results. Joshua is the author of the best-selling, Jolt Cola-award-winning book, Refactoring to Patterns, and was the keynote speaker at Agile2016.
Gene Kim the author of The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win and The Visible Ops Handbook, a researcher, and founder and former CTO of Tripwire.He is frequently a keynote and speaker at DevOps conferences and a producer of the DevOps Enterprise Summit.
Dean Leffingwell is Chief Methodologist at Scaled Agile, Inc., arguably one of the fastest growing agile methodologies. He is an author, multi-entrepreneur, consultant and executive, he has founded multiple software companies, including Requisite, Inc., makers of RequisitePro, which was purchased by Rational Software and then IBM.
Tim Reaves helps enterprises access their ability to deliver software by helping them to plan and implement desired organizational and technical changes to support their business goals. He is Eliassen Group’s Agile Practice Enterprise Delivery & Technical Consultant. Tim is passionate about all things Agile and DevOps.
2017 has been an exciting and eventful year for VersionOne Products! We’ve released many new features and enhancements over the past year to further our mission to help you accelerate software delivery and increase enterprise agility. Looking back, a few items hit our Top 10 favorites list for the VersionOne product in 2017.
1. Portfolio Item Dependencies
This new feature in Lifecycle allows product teams to identify feature dependencies earlier in the planning process when they are planning for future PI or product releases with the new Portfolio Item Dependency Relationship. You can now set the dependencies directly between portfolio items avoiding the extra step of creating user stories and linking them to the portfolio item. The dependencies can be set at any level in the Portfolio Item hierarchy, which enables you and your users to create dependencies between Capabilities, Epics, Initiatives, or any level in the hierarchy.
2. Team Process
Team Process empower teams by allowing team autonomy and self-organization with greater flexibility. Your teams can now define their own WIP limits, Cycle Time, and Cycle Time Threshold within Lifecycle. When defined, values are used on the Storyboard in Team-specific TeamRooms and on the Iteration Tracking Storyboard when filtered to the Team.
3. Filtering + Inline Asset Editing
The filtering capabilities released throughout the year in Lifecycle provide a new streamlined filtering experience for our grid views. The filter interface gives you the ability to quickly perform advanced field selections and includes multiple values for each field of data specific to your needs.The relationship filters enable you to search between assets such as “created by” to easily look for backlog groups in the Portfolio Tree.You can also perform filter searches on tags created for the Portfolio Items, Stories, Defects and Test Sets so teams can quickly identify items and streamline workflows. Administrators can also apply filters to merge, clean-up or delete tags for clean consistent data within the platform. Also, with the new grid and board filters, you have more options, such as a date, numbers and true/false fields. You can use the comparison functions for dates and numbers, such as “equal to”, “greater than”, or “less than”.
In addition to the improved filtering experience, we have provided more direct and intuitive edits for you with enhanced inline editing. Immediate changes to any attribute on a page are quick and easy and automatically saved – no extra clicks or redirects. More asset types, such as Team and Member are now directly editable and numerous usability improvements have been made such as an “unsaved change” warning plus a better editing experience for rich text.
Lifecycle users can add tags on Portfolio Items, Stories, Defects and Test Sets, including managing tags. Managing tags is easy and provides you and your teams greater flexibility with organizing your backlogs using tags that are relevant to your perspective. Project Leads or System Administrators now have visibility into where there may be multiple instances of a tag that has been used throughout the system, for example, “admin”, “admin1”, or “admin2”. They can easily merge or edit the text to say “admin” on all records without having to use the API or manually update each asset.
Administrators can also view all assets that have a tag, the total number of tags within a category including tags that are being used outside of their scope of work. This provides insight into other teams who are using the same tags; allowing teams and leads to make informed decisions before changing or merging tags.
5. VersionOne Lifecycle + CollabNet TeamForge SCM
Lifecycle’s native version control system integration, CommitStream, now supports TeamForge SCM. All our Lifecycle users can now track code commits right within Lifecycle workitems and TeamRooms. We’ve made it easy for our users who operate in more regulated industries and need more options with their source control management such as preventing the deletion of code, history protection, and code reviews
6. New Continuum Dashboards: Flow, Risk, Environments
Continuum Flow, Risk, and Environments Dashboards provide visibility into the performance of your DevOps delivery processes. Measuring delivery process performance and risk metrics allow you to identify areas for improvement across your workflow and accelerate the delivery of quality software. Flow Dashboards provide insights into your workload distribution across your phases, lead times, and workflow efficiency. Risk Dashboards help you analyze your commit distribution, rogue commit percentages and risk averages across your value stream.
The Environments Dashboard allows your developers, testers and product managers to immediately view and identify “what’s deployed where”. This enables them to easily access the environments that contain the code they’re looking for while managing many concurrent projects and deployments.
7. Continuum Complexity Ranking
The new Complexity Ranking in Continuum enables you to have full visibility into the complexity of individual workitems and defects to make informed decisions in real-time, easy to read metrics. It also allows you and your teams to build confidence in their feature code before deployment.
8. VersionOne Continuum + CollabNet TeamForge
Continuum supports TeamForge SCM for Git and Subversion repositories allowing teams who use TeamForge SCM (17.11 and up) to take advantage of all the benefits offered by Continuum. This allows you to gain complete visibility into the flow of your TeamForge artifacts through the various phases of development as well as metrics, automation, and much more.
9. Lifecycle and Continuum New Modern UI
The value stream navigation within Lifecycle – Portfolio, Product, Release, and Team – has a new streamlined modern menu. Plus, the project scope selector has been strengthened as the primary navigation focus with descriptive icons for secondary areas enabling you to get where you need to go faster.
We’ve also included an updated navigation interface within Continuum to enable an easier transition between Lifecycle and Continuum, streamlining the navigation to key areas within Continuum itself.
10. VersionOne VS
VersionOne VS was announced with the Summer Release and is an offering that uniquely integrates the entire software delivery value stream from Strategic Planning, Budgeting, Roadmapping, Release, and Iteration Planning all the way to Release Automation and Orchestration. By connecting historically fragmented tooling and processes into an integrated solution, your organization is empowered with real-time, data-driven insight to track and improve the speed and quality of your entire software delivery cycle.
Phew, it’s been a busy year! But perhaps the most exciting thing to happen for everyone at VersionOne is our merger with CollabNet. The combined organizations, operating under the CollabNet name, now offer the industry’s most complete Enterprise Agile, ALM Collaboration, Version Control and DevOps solutions that power application development and delivery for many of the world’s leading businesses and government institutions – helping you to deliver software faster with confidence!
We are excited to announce the 2018 Winter VersionOne Product Release. With this release, VersionOne launches new capabilities that provide teams with greater flexibility for planning and managing software delivery with confidence. Additional improvements in VersionOne’s enterprise platform include:
VersionOne Lifecycle for Agile ALM
VersionOne Lifecycle for agile ALM provides end-to-end enterprise agile lifecycle management that enables your teams at all levels – enterprise, portfolio, program, and team — to collaborate, develop, and deliver software faster. The 2018 Winter Product Release includes the following new features and enhancements:
Key dates are captured and communicated throughout your organization so your planning and delivery teams understand interim targets, sync times and important events. With Milestones, it is easy to keep key dates such as industry events or sync points during a PI cadence, visible in your planning process views. You can also create and view milestones in your roadmap and see them in high-level planning views such as the Program Board and Solution Board helping to impact what you plan in the way you plan.
Saved Views for Grids (My Views)
The complex filters you have created on your grid views can now be saved with “My Views”. It is easy to save and recall customized filters on the grid, visible columns, editable fields, page sorts, and a number of items per page with the “My Views” button. For example, product owners and project managers can now streamline their backlog to easily queue views based on their teams and projects. You also have the option to save your current project scope selection into your “My Views”. Being able to easily call up multiple critical items within several projects is one example of the streamlined execution of “My Views”.
We continue to empower teams by allowing team autonomy and self-organization with greater flexibility in Team Transitions. At the team level, teams now can define transitions, an automatic status change to a story, such as a quick close.
VersionOne Continuum for DevOps
VersionOne Continuum™ is an enterprise-scale continuous delivery solution for accelerating the speed, reducing the risk, and ensuring the quality of complex software deployments. Our 2018 Winter Product Release includes the following new feature and enhancements:
CollabNet TeamForge SCM
Continuum users now have a richer integration with TeamForge SCM to take advantage of a more streamlined interaction from Continuum to their code repositories. You will benefit from the new functionality such as add comment to artifact, change artifact status, update artifact, get artifact and much more with the TeamForge plugin.
Insights Dashboard is a new functionality that provides a centralized location for all your development data. If you are a release and development manager, you now have complete visibility into how changes, over time, impact deliverables. Plus, you can identify areas of opportunity. As a product manager, you will be able to see the total number of jobs and failures, including activities, pipeline runs, tasks broken down by category, deliveries, and targets release dates for complete visibility into your deliverables.
Managing many concurrent projects and deployments is a challenging task for anyone. Now with the enhanced Environment Dashboard, developers, testers, and product managers can now view package revisions on the environment dashboard providing more insight into “what’s deployed where”. You can now remove environments cards from the dashboard after the environment has reached its end of life, providing real-time visibility into all your deployments.
Enhanced Encrypted Plugin Data
Now all your passwords for your plugins are encrypted at rest, providing more security to your configuration data on the server.
2018 Winter VersionOne Product Update Schedule
Lifecycle Team and Catalyst editions will be updated on January 27, 2018. Lifecycle Enterprise and Ultimate editions will be updated on February 3, 2018.
VersionOne products continue to lead the market with our enterprise-class software planning and delivery platform that unifies Agile, DevOps, and Version Control lifecycle management. Check out the VersionOne Product Release page to learn more.
The decision of your organization to adopt enterprise Git as a corporate source code management (SCM) standard is not merely a technical concern. It also has a major impact on the business performance of your organization. To effectively address the challenges of enterprise Git adoption, organizations should set the bar high by handling Git as a strategic investment.
In order to be successful with implementing Git in the enterprise, be sure to select an Enterprise Version Control (EVC) platform for centralized, distributed and hybrid development environments. This platform must also integrate with existing development tools enabling Continuous Integration (CI) and Continuous Delivery (CD).
Here are the top 4 challenges of Enterprise Git adoption:
(1) Insufficient native access and audit controls in Git
Git was designed for the needs of open source projects, specifically Linux. It can reliably track who authored a change and who can add changes to a repository. While sufficient for most open source projects, this design consideration left out many of the inherent security controls of centralized version control tools, such as Subversion (SVN), which is currently used by the enterprise. This realization often comes as a shock to security and compliance officers in large companies once they discover the risks associated with migration from centralized legacy SCM to Git.
(2) Heterogeneity of modern enterprise development infrastructure
As long as hybrid SCM is still the norm, there is a need to manage Git and SVN simultaneously—not only within the enterprise but also at the individual project level. However, most Git solutions in the market today ignore this need completely and do not provide any management or governance for anything except Git itself. As a result, organizations often experience difficulties articulating their SVN/Git infrastructure coexistence strategy or face an “all or nothing” migration dilemma.
(3) Avoiding disruption of existing business processes
Large companies are very sensitive to “deregulation” permitted by Git’s powerful branching capabilities as it potentially may cause a lot of changes in the company’s existing software delivery lifecycle management processes, causing disruption to automated integration, build, and delivery infrastructure investments. These concerns are legitimate, and stakeholders across the organizations need to have a means to preserve existing investments and replicating the company’s current business processes.
(4) Need to maintain highly distributed, federated repositories
While the use of a central master repository (also referred to as a “golden,” “canonical,” or “blessed” repository) is easier to manage, Git does not mandate this approach. For the enterprise, however, federated deployments pose a serious risk of intellectual property or data loss. With dozens or hundreds of servers, it becomes challenging to locate code or enforce strategies for backup, disaster recovery, or failover.
Interested in learning how CollabNet can help you be successful implementing Git in the enterprise?
Try CollabNet’s TeamForge SCM solution free for 30 days! TeamForge SCM is an Enterprise Version Control platform that gives organizations the advantages of distributed (Git) or centralized (SVN) version control systems, while ensuring compliance, governance, and IP security across all source code-related activities.
Today more than ever, organizations are hyper focused on their agile process to ensure alignment with strategy and manage the delivery of value with cost and time constraints… almost too much so! Having worked with many different organizations over the last few years on their agile process to facilitate the delivery of value, I’ve noticed a common theme — the hyper focus on agile process impedes the delivery of value. The “key” is having the right balance.
A good friend and colleague of mine, David Hussman, calls this out by citing his very own “Dudes Law” (Value = Why/How). This basically translates to … “The more you focus on ‘The How’ the less value you get. Use ‘The How’ (ie. your process) as a tool to facilitate the delivery of value. Don’t treat it as if it were the Law of the Land.” So, what David is really saying here is, “focus on ‘The Why’”! Meaning… understand why you are doing what you are doing. Connecting with “The Why” allows teams to be more innovative in their approach. This is what we want folks… You did not hire people to just “follow a process” … You hired innovators, and engineers! “The Why” as David so eloquently puts it, is best known in the agile world as “Epics, Capabilities, Features, etc”… ie. “The Big Rocks”, ideas, initiatives, or in VersionOne… Portfolio items, that we break down into stories that live in a backlog. In a traditional sense, these are also “Projects” that teams work on in support of a given strategy.
A Balancing Act
Having a solid understanding of “why you are doing, what you are doing”, and balancing that with the team process to deliver on that value is key! The key word here is “balance” … Most organizations only focus their process around team delivery at the backlog level. Applying the same agile/lean practices at the program and portfolio levels is needed to achieve “the right balance” to keep value flowing and to answer the two questions that everybody need answered:
When will this be done?
Are we working on the right things?
An organizations ability to manage their portfolio of projects is no small task. Its not uncommon to see teams working multiple projects at once — even though that may not be the intent. What I mean is… I’ve seen, in many cases, teams focused on a prioritized project, then some other “high priority” project comes into play and traction is lost on the original project they were focusing on — so much so that it ends up sitting in a half-baked state for months! Then, once revisiting, teams are having to re-learn, and re-calibrate on what was done prior, let alone what needs to be done. Sound familiar?
For an organization to manage their portfolio of work successfully, they should do what they coach their teams to do. Teams manage delivery of value, in a disciplined way, by incorporating agile & lean practices that chips away at the prioritized backlog of work that’s on their plate.
At the very core, teams apply lean principles to value delivery. After all, lean is the very reason why agile works, right? (Thank John Little for that!)
Limit their focus (i.e. WIP – work in progress)
Optimize cycle and lead times
Why can’t these lean practices be applied to the portfolio of projects? Let’s look at each one of the above mentioned “rules” for applying lean.
Seems like everything do in life involves a queue, right? Going to work in traffic – that’s a queue. Going to the grocery store — in a queue. Well, projects in an organization are in queue just like backlog items.
Here are a few tips to get you started on keeping “The Right Focus”:
Tip 1: Timebox your backlog
Timebox your backlog to control the focus. For backlog items, I like to timebox it to 90 days or less. For your portfolio items, double, or triple that. If a project doesn’t fit into the timebox, don’t put it there! Doing this alone, will afford teams “The Right Focus” when viewing/managing “what’s on their plate” so they can set realistic expectations. Having a manageable backlog allows for a percentage of time spent each sprint/week to look ahead, prototype, investigate, and tee things up.
Tip 2: Set WIP for active work
For backlog items and story boards, I typically start off with 1.5 * # team members. For portfolio items, I typically use # teams — but, it’s up to you, based on the number of team members, and focus they have.
What I’ve noticed to be most helpful, is the use of planning rooms in VersionOne to create views that are consumable and relatable to folks at different levels in the organization. For example, Senior level execs aren’t really concerned with the low tasks that a developer is doing. They care about their initiatives or “Epics”, and if the teams working on them are “moving the needle” or not. Program teams, take the “Epic” work and decompose into two or more “Features” that follow a different, more refined workflow, and manage to completion to deliver on the “Epics”. They work with the delivery teams to bridge the gap between the stories they are committing to in a backlog that derive from the “Features”. See below for a visual of what this looks like.
Here’s another example below from the context of a Planning Room in VersionOne. This illustrates two different perspectives of how an organization is delivering on its strategy. On the left, you have an “Epic” workflow at the portfolio level. On the right, you have a “Feature” workflow at the program level that also shows the relationship to the parent “Epic” it derives from.
Here is a view from the agile team level detailing the stories committed to, the feature they derive from, and the progress on each as effort is tracked and tasks are completed.
With this view, anyone in the organization can see the things they are responsible for in addition to how that same work contributes to the bigger picture.
Optimize Cycle & Lead Times
Use Cumulative Flow and Cycle time reports to validate how the “flow” rate of your portfolio work, identify bottlenecks, establish a cadence of delivery, and calibrate estimation.
In the portfolio item cumulative flow chart below, you can see many opportunities to improve upon. Specifically, with respect to ensuring that the average rate in which work enters a status is equal to the average rate in which it leaves that status — implementation and testing is stalled at various points. A portfolio cycle time trend provides an opportunity to improve upon estimates, or what I like to say… provides a way to have “validated learning” — comparing estimates on portfolio work to cycle times. So, be sure to keep the “right” perspective and always keep a hyper focus on “The Why”, using “The How” as a tool to deliver. This will help you maintain a balance to keep value flowing!