Scaled Agile, Lean, and the Journey to Scaled DevOps
Scaled Agile, Lean, and the Journey to Scaled DevOps
Betty Zakheim from Tasktop provides insight into the journey toward scaled DevOps as a result of scaled agile and lean.
Join the DZone community and get the full member experience.Join For Free
With the influx of DevOps-related products and services on the market, today’s application delivery toolchain has become complex and fragmented. Watch Avoiding the DevOps Tax to learn best practices for integration and automation to realize a faster DevOps lifecycle.
This week, Tasktop announced its latest innovation in software lifecycle integration. We’ve added a whole new integration capability to our portfolio that enables DevOps practices to scale to the rest of the Connected Software Lifecycle. What this means to our customers is that they finally have the DevOps Integration Hub needed to scale DevOps transformations from a greenfield initiative to a cross-company standard.
The best way to explain why we did this is to take you on a little historical journey of how we got here.
Our first product, Tasktop Dev was introduced in 2009. It allows Eclipse and Microsoft Visual Studio IDE users seamless access to the artifacts in their ALM tools without having to leave their IDE. Tasktop Dev helped developers focus on their work and did wonders for individual developer productivity.
At the same time, our customers were embarking on Agile initiatives and quickly noted that while their teams needed more “connectedness” to be Agile, their tools were driving them apart. Developers and testers (in particular) needed to work more collaboratively than ever. Yet, their lifecycle management tools (like Agile planning, requirements management, test and defect management) didn’t interoperate, and actually slowed collaboration around artifacts such as defects and requirements.
So we quickly realized that team productivity would be enhanced dramatically if the ALM integrations were performed at the server-side, rather than “only” to the IDE. In this way, entire teams could reap the rewards of the information flowing from one system to the next. This lead to the development of Tasktop Sync.
When we introduced Sync in 2011, we concentrated on building a robust integration platform that would support the complexity of the work that the core Agile team needed: high fidelity, highly reliable synchronization of development and test artifacts… and their relationships. The relationships among these artifacts was important because it provides not only the context of the work (defects are related to tests, which are related to user stories), but also traceability.
Over time, our customers wanted to scale their Agile practices to drive collaboration beyond the core Agile development team, and we extended the breadth of the disciplines and tools we supported to include the PMO; many different styles of requirements management and elicitation; more tools for development and test; and even the service desk.
And once we did that, we realized that our system was integral to the flow of the work across the lifecycle and that our system was witness to a lot of the activity being performed. If we were able to record this activity in a central database, our customers would be able to collect the kind of metrics that they were unable to collect before, and they’d be able to create pan-lifecycle reports, dashboards and KPIs. And this lead to the development of Tasktop Data.
Now, our customers were able to use our products to scale their Agile practices and to get the kind of visibility into the work that allowed them to find and remove bottlenecks and waste, supporting their Lean transformations as well.
But what was missing? The key capability that was missing was excellent support of their DevOps initiatives!
The interesting thing about DevOps and IT automation is that their tools and artifacts are very different than the lifecycle management tools that we synchronize with Tasktop Sync.
Tasktop Sync, as its name implies, integrates development and delivery tools by synchronizing the artifacts in one system with other systems. When an artifact is created or modified in one system, it and its related artifacts, are mirrored in other systems and they remain synchronized over the lifecycle of that artifact. An integral aspect of these artifacts is that they actually have a lifecycle! They are created and modified over time, by practitioners, as they collaborate on their work.
But rather than having a lifecycle, the artifacts created by automation tools are based on an event occurring, but they don’t change over time. These kinds of artifacts include: changesets in version control systems, metadata for a build and vulnerabilities detected by a static code analysis tool.
These events are interesting and must be shared, but they are not modified by their stakeholders over time. So while synchronization is the perfect integration style for supporting an on-going conversation using artifacts with a rich lifecycle, for DevOps and automation tools, on-going synchronization really makes little sense.
What does make sense is that these events should trigger the creation or modification of artifacts in the lifecycle management tools (Tasktop Sync) and/or should be streamed to a reporting database (Tasktop Data).
- When an automated test runs (either because it was started manually, or as part of a Continuous Integration process), the fact that it ran successfully should be recorded by Tasktop Data for reporting purposes. But if it fails, it should also trigger the creation of a defect in the defect tracking system (Tasktop Sync). If that defect tracking system is also a test management system, there should be a relationship created between that defect and the test that uncovered it.
- Similarly, when code is in checked into a version control system, it creates a changeset with metadata about what code was changed, who made the change, etc. That changeset and all its information can be recorded by Tasktop Data, and Tasktop Sync can append that information to the user story or defect that instigated the change.
- When a build is created, its information can be related to the stories or defects implemented in that build.
- And so on…
This capability creates unprecedented connectedness between DevOps teams and their colleagues… and full traceability across the entire lifecycle.
By connecting DevOps methods with Scaled Agile practices, we’re enabling our customers to Scale DevOps to the rest of the lifecycle. And getting the industry further down the journey of a fully Connected Software Lifecycle.
Published at DZone with permission of Betty Zakheim , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.