I coded, or at least tried to code, my first program in 1978 in junior high school on a VAX mini using punch cards. That was followed by my first personal computer – an Atari 800 with a 14.4k modem and a cassette player for storage. I’ve been involved in software development on a small and big scale ever since.
Computer hardware has come a long way since those punch cards in 1978 with quantum leaps in performance with simultaneous reductions in price.
In 1984, when the world was watching the launch of the original Apple Macintosh during Super Bowl XIX I was selling Atari ST computers from my fraternity house. It was the first computer to break the $1000 per megabyte of memory price barrier. Today I can buy 8 GB of memory for under $40 on Amazon.
Software development, on the other hand, has not improved as dramatically, not even close. While there are IDEs today that make the act of coding and compiling much more efficient than the days of machine language coding, the complexity of software development on the medium to large scale has become dramatically greater. Today, it’s not uncommon for software development efforts to consume the talents of hundreds, if not thousands of software professionals, often distributed in teams around the globe.
Adding to the challenge, the rate of change in the market, technology, and customer demands is constantly accelerating while most large organizations are still using a project management methodology for software development that is based in the slow change days of the 1970s. I’ve personally suffered through years of waterfall development only to see software delivered over-budget with less functionality than planned at a human cost that was unacceptably steep.
The Challenge of Agile at Scale
Today, a lot of things have changed. Agile software development is the new standard, with development cycles averaging two weeks, not the 12 – 18 months of waterfall. Teams using agile are incredibly productive and deliver software the market wants because they work with a product owner daily. The product owner represents the business and customer.
The challenge with agile development is that it wasn’t designed for large groups, let alone global companies with thousands of developers. The illusion of waterfall was that by planning a huge system in advance, we could somehow limit the scope creep and control our destiny. Agile embraces change through its rapid fire development cycles, but has serious challenges scaling past four or five teams of five to nine team members.
This is the challenge the Scaled Agile Framework (SAFe) solves for, how to maintain the innovation and power of agile at the team level while simultaneously allowing for the planning and coordination needed across huge development efforts. SAFe has evolved since its launch in 2011 into the defacto standard for large-scale software development.
The just-launched SAFe 4.0 is an exciting milestone in the evolution of developing software at scale. It solves for so many of the painful issues I’ve run into over the last two decades, from balancing necessary planning with adapting to market change to how to lead globe-spanning teams of motivated individuals in pursuit of the same goal.
What I love about SAFe 4.0
What I find really exciting about SAFe 4.0 is that it is principles-based and therefore adaptable to each organization’s needs. Unlike more prescriptive methodologies that focus on methods and techniques, SAFe 4.0 is based on a body of profound knowledge coming from such disciplines as lean, systems thinking, systems engineering, and theory of constraints; as well as the latest developments in agile software development and devops. Repeatable patterns of success emerge from this body of profound knowledge that can be applied to any agile at scale implementation, whereas techniques that were successful in a single organization are often not useful or repeatable outside the unique context of the organization in question. In my own experience I’ve found organizations that focus on principles and patterns of success are more innovative and adapt more quickly than organizations that a more hierarchical and prescriptive in culture. When I see thick, prescriptive policy and procedure manuals I’ve found it’s best to run in the other direction.
SAFe 4.0 further defines, refines, and gives greater weight to value streams than in version 3.0. While the Value Stream Level is optional as a distinct level, every organization would benefit from understanding what operational value streams are and how to best utilize them as a bridge between the business and the development group. Value streams are, fundamentally, the essence of why any organization exists (even a hot dog stand has a value stream, albeit a simple one); they describe the value added by the organization to earn a profit and to earn the right to continue to exist. Without at least one value stream of some sort, there would be no reason for the organization to exist. One of the challenges I’ve faced throughout my career is acting as a bridge between business and technologists, because the two groups think in such different terms and have different priorities; therefore, for me, the benefit of the Value Stream in SAFe is that it allows the business to provide the context to the development group of why they are building what they are building and for the business to make better strategic decisions around budget allocation and product development.
SAFe 4.0 also includes an enhancement that may be overlooked by many and seen as a step back by some, but in the end is a simple acceptance of the world we live in. What is that enhancement? It is the inclusion of the Supplier in the Value Stream level. Why could it wrongly be seen as a step back? Because SAFE 4.0 acknowledges and deals with the reality that many suppliers to lean-agile organizations may still use traditional waterfall methodologies and methods are needed, such as milestones, to sync up the lean-agile release trains with a waterfall supplier. This is a reality in a large number of organizations today; in fact, many organizations contain a mix of lean-agile groups and waterfall groups internally. The same approach defined for working with waterfall suppliers can also be used for syncing agile release trains with waterfall groups.
In my experience I have yet to see a large, long-established company in any industry that is 100% agile. Most of them are still running large traditional PMP PMO shops with traditional waterfall projects often consuming 80%+ of the development budgets, assets, and people. The other 20% of the IT organization is running agile or some other iterative development methodology. The great thing about SAFe is that it can be adapted to work in these environments, as I’ve personally experienced as an agile coach with several large client organizations.
There are many other aspects of SAFe 4.0 (like requirements frameworks, finances, and built-in-quality) that, as they are adopted by large organizations, have the potential to greatly improve the endeavor 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.
How does AgileCraft optimize SAFe 4.0 practices? Check out my next post – Why I Love SAFe 4.0 Part II.