As I shared in Part I of this post, “Why I love SAFe V4.0,” I’ve been involved in software development since 1978. During this time, I’ve worked for or consulted to organizations spanning in size from 50-75 people to multi-national firms, using a range of methodologies from ad hoc through waterfall and on to iterative and agile.
Along the way I’ve used a wide variety of application lifecycle management (ALM) software, both Agile ALMs and traditional ALMs. AgileCraft™ is unique as an ALM in that it is bimodal – it supports both agile and traditional development methodologies and tools, while fully supporting SAFe 4.0, a proven, methodology for developing at scale that embraces and enables all three elements (autonomy, mastery, and purpose) of Daniel Pink’s Motivation 3.0, organizational change, and agile/lean/technical best practices.
Agile on a small scale, at the team level or group of a few teams, can be successful without an Agile ALM, because Post-It Notes and conversation can keep small teams in sync (assuming they are all collocated). They would still benefit from a team-level tool, but they don’t need one to be successful. An analogy to this is an Amish barn raising where a group of Amish men work together in harmony to build a barn in a day. (Note: The fact is that using an Agile ALM like AgileCraft™ at the team level provides a lot of benefits such as automated reporting, dependency management, and historical data capture, just to name few.)
Agile (or traditional development) on a medium to large scale is a different matter. Attempting to make several hundred people develop a complex software system without the proper support platforms such as an Agile ALM like AgileCraft™ would definitely serve as one of Dante’s Nine Circles of Hell, yet many of us have lived it. While small team agile development is akin to an Amish barn raising, medium or large scale agile development is more akin to building a skyscraper. Clearly, it would be insanity to even attempt to design a skyscraper without a tested methodology and all the necessary support systems and tools, yet we do it all the time in the software world.
SAFE 4.0 is the proven methodology for developing at scale, akin to the set of meta-skills of how to develop blueprints, get through the inspection and permitting process, and converge on a set of unified standards. AgileCraft™ is an enterprise software platform encompassing all the tools of the trades needed to plan, track, and manage the creation, construction and delivery of value. Just as people in the construction industry need both the proper meta-skills and the proper tools to plan, design, and build a skyscraper, so too do software groups benefit from SAFe 4.0 and AgileCraft™. Both will increase the probability for success, and the two work extremely well together because AgileCraft fully supports all of the improvements in SAFe 4.0 (such as Value Streams as a distinct level, Kanban at all levels, the updated SAFe Requirements Model, and lean-agile budgeting), from the team level up to the enterprise level.
AgileCraft™, the platform, is capable of playing well with all of the major agile tools, as well as any of the major waterfall tools, with data from both sides rolled up into meaningful common views that support decision making at all four levels (enterprise, portfolio, program, and team). Being both an MBA and a Computer Scientist, I love how AgileCraft™ seamlessly takes things from the 5 millimeter level of detail up the 50,000-foot strategic level, and then back down again.
AgileCraft™ and SAFe 4.0
Here are some of the ways that AgileCraft™ supports SAFe 4.0 in both a pure agile and bi-modal environment:
SAFe 4.0 added considerable emphasis to the existing concepts of lean-agile leaders and developing a lean-agile mindset. The challenge is that while lean-agile leadership and a lean-agile mindset are powerful, they require high levels of trust and pushing decision-making to the lowest possible level. In order to develop trust in subordinates and be comfortable releasing control, executives and managers need the ability, as our 40th President once famously said, to “Trust, but verify.”
- AgileCraft™ enables the executive/manager with full transparency from the enterprise level to the team level, giving them the ability to drill all the way down to the task level, if they so choose. With this transparency and the dashboard capabilities in AgileCraft™ control-driven mindsets can be comfortable knowing they can take a trust, but verify approach.
- AgileCraft™ enables this level of transparency and connectedness allowing an organization to demonstrate the value of a lean-agile value delivery mindset vs. the traditional project delivery mindset. When people see the value, to them, they will make the change willingly.
SAFe 4.0 added a new Value Stream Level, including new roles such as Value Stream Engineer, activities, and artifacts such as Capabilities. This level is optional and is designed for use by those organizations building extremely large systems, although any organization will benefit by incorporating value stream concepts into their decision making.
- AgileCraft™ enables value streams as an optional level by providing the ability to show or hide our value stream functionality at the customer’s discretion. We support both operational and developmental value streams through a fully expandable and configurable value stream process tool that allows you to define one or more value streams for each portfolio. These value streams tie directly to the related capabilities and enablers (formerly known as architectural epics/features/stories).
SAFe 4.0 added, as part of the Value Stream Level, a detailed Economic Framework, that in effect throws the gauntlet down against traditional project cost accounting and budgeting.
- AgileCraft™ enables lean-agile budgeting and epic light-weight business cases with support at various levels, including the ability to estimate budgets by average cost per story point.
- AgileCraft™ enables traditional project cost accounting by supporting budgeting by cost center, hours worked on an effort (via the integrated time tracking module), as well as OpEx and CapEx considerations for both traditional and agile efforts.
SAFe 4.0 added the concept of Suppliers to the Value Stream Level, and addresses the issue of Suppliers who operate in a waterfall fashion by introducing the concept of milestones. The same approach defined for working with waterfall suppliers can also be used for syncing agile release trains with waterfall groups.
- AgileCraft™ fully supports this concept with target dates and milestones, as well as methods to cross-link waterfall project teams with agile teams, in addition to Suppliers.
SAFe 4.0 continues to emphasis the importance of dependency management.
- AgileCraft™ supports this concept with the most robust dependency management capability I’ve seen in any of the Agile ALMs I’ve worked with. In other ALMs dependencies are a characteristic or trait of an epic, feature, or story (or a simple relationship between two of the same type). In AgileCraft™, the dependency is an object in its own right, which leads to the richest variety of dependency visualizations. My favorite is the dependency donut (official name – Dependency Map (Circle)).
To step back and give a bit of perspective, I’d like to share a recent professional experience. I started coaching full-time in a SAFe3.0 environment back early last year. It was a bi-modal environment with 80% of the teams running traditional/waterfall and the other 20% of the teams running agile; even in this environment the power of SAFe was apparent. The challenge was we didn’t have an enterprise-level platform like AgileCraft™ that could support both agile and waterfall teams and roll-up into a set of common view that allowed for enterprise, portfolio and program-level decision-making. Instead, we attempted to achieve some semblance of this at the program level by requiring the waterfall projects to create epics, features, and dummy stories in the program/team-level Agile AML tool we were using. It was a valiant attempt to get some meaningful data for decision-making, but in the end it was less than we hoped. With AgileCraft we would have had the solution we needed.
In a future post we will delve into the SAFe 4.0 Economic Framework construct of Lean-Agile Budgeting that is inherently at odds with traditional project-based cost accounting, and how AgileCraft™ supports both. While many organizations have regulatory or other reasons for continuing (at least in the short term) with traditional project accounting, as lean-agile budgeting is adopted by large organizations, it has the potential of greatly rationalizing the funding and budgeting of building software at scale. I look forward to not only seeing the adoption of SAFe 4.0 by the organizations I work with at AgileCraft™, but to seeing how they impact the art of building software.