Key Insights from SAFe 4.0

I’m a big fan of Dean Leffingwell and his work on the Scaled Agile Framework (SAFe). He’s been bringing lean thinking to software development for some time now. I work in a massive IT organization that has identified SAFe as how we’d like to develop software going forward.

Listen for these key concepts in the video below.

  • The Customer and the Value Stream are key to the framework
  • Value streams are the central organizing construct for SAFe.
  • SAFe as a model, organizes around value, and this helps speed delivery
  • Funding value streams vs. funding Agile Release Trains (ARTs)
  • When Requirements are needed vs. the concept of Solution Intent
  • General purpose solutions vs. ‘bespoke’ solutions

Over the past few years, I have heard many software development professionals say things like, “It’s a pretty good concept, but it doesn’t work in the real world.” or “SAFe doesn’t account for Architecture or other enablers.” 

If you are in IT, you owe it to yourself to get up to speed not just on SAFe, but on the underlying lean thinking concepts that are driving it. If you don’t, you risk getting left behind both organizationally, and in your IT career.

Bob H – April 28, 2017


Key Links

Scaled Agile Framework home: http://www.scaledagileframework.com/

Lean-Agile Mindset Abstract: http://www.scaledagileframework.com/lean-agile-mindset/

Value Streams Abstract: http://www.scaledagileframework.com/value-streams/

Team Kanban Abstract: http://www.scaledagileframework.com/team-kanban/

 

Agile Software Framework

Goal-driven software development schema
Goal Driven Software Development Schema (Image via Wikipedia)

 

For the last half of 2010, I conducted an “Introduction to Lean IT” class for new hires into AT&T’s IT group. In every class I taught, someone asked about “Agile” and if Lean IT is the same thing as Agile. While Agile is not lean per se, there are many similarities. Here’s a pretty good overview of the framework from http://www.paradigmaseminar.org/

What is the Agile software framework?

Agile software development embodies methodologies and practices that facilitate an evolutionary approach to software development. Agile also advocates developing software in shot time periods, i.e. 4 to 6 week cycles. In addition a face to face communication model is also advocated by Agile. Although there is nothing new in these methods the Agile Manifesto seeks to bring together all of the best practices that create software:-

  • Lighter.
  • Faster.
  • In a more people-centric way.
  • The Agile Manifesto is based on a set of principles that include:-

  • Customer satisfaction by rapid, continuous delivery of useful software
  • Working software is delivered frequently (weeks rather than months)
  • Working software is the principal measure of progress
  • Even late changes in requirements are welcomed
  • Close, daily, cooperation between business people and developers
  • Face-to-face conversation is the best form of communication
  • Projects are built around motivated individuals, who should be trusted
  • Continuous attention to technical excellence and good design
  • Simplicity
  • Self-organizing teams
  • Regular adaptation to changing circumstances

    What is new about Agile?

    In practice there is little new in the components that make up Agile, many of the principles are embodied in previously defined Joint Application Development (JAD) and Rapid Application Development (RAD) techniques. What Agile brings is a consolidation and discussion around those tools and techniques that advocate a leaner more iterative software development process that does not rely on a complete set of requirements being produced at the beginning of the cycle. In addition Agile, as a discussion forum, positions some of the newer software methods within this leaner\faster environment. These newer development methods include:-

  • Extreme Programming
  • Scrum
  • Adaptive Software Development
  • Feature Driven Development
  • Pragmatic programming
  • The definitions of the above can be found on the web, but the point of the list (which is not complete) is to convey the fact that there are many evolving software development techniques that seek to address the essential difficulties of the software medium (that is software is not tangible and is defined as abstract models).Agile is best thought of as a mindset or forum under which certain methods and techniques are understood in relation to each other and in relation to solving the problems of software development.Agile is not a cure all or one size fits all and at some level it is easy to criticize. At the very least, however, Agile brings a fresh look at the software development process and is a positive forum for software process improvement discussions.

    Where does Agile work well?

    One area where Agile methods work well is User interface design. It is very difficult to sit down with a user and produce screen shots or Mock ups that depict the final software product in a way that the user can make a judgment as to the usefulness of the screens (interface). A working prototype, of just the user interface (i.e. no functionality behind it), has proved to be the best way of obtaining what the user really wants in terms of screen design. In short the user is saying I can’t tell you exactly what I want but when I see it I will know. This approach to software requirements works well when there is flexibility within the solution, or when there are a large number of alternative solutions to the requirement.

    Where does Agile not work well?

    Consider a financial application that has to satisfy some legal accounting requirements or a stock control system that needs to calculate re-order levels in a prescribed manner. Software applications that require certain functionality to be implemented may be able to use some Agile methods but they will require the specification to be produced in full before the design and coding can start. For these kinds of applications the functionality of the software needs to be fully documented and understood by the developers prior to any coding. An iterative approach to implementation will work but only if the whole system functionality is specified otherwise the structure of the system would be evolving as the requirements where fully understood. In short Agile works best when there is choice over the solution or when a non-functional requirement (i.e. usability) is difficult to document.

    No guarantee (or claim) is made regarding the accuracy of this information.

    Lean Software Development Podcasts

    This is a great series of podcasts on Lean Software Development. 

    Listen to the webinar audio Chapter 1: A Developer’s Guide to Lean Software Development 

    This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott.  

    This show focuses on Chapter 1, A Developers Guide ot Lean Software Development. We start to answer the question, if Lean’s goal is to focus on speed, quality, and low cost. How do you do it? 

     In the past, the approach has been to try to make every step and every person as efficient as possible. THat doesn’t work. Instead, you have to look at optimizing the whole process. It is different than efficiency and cost; in fact, lowering cost can increase speed to market and lower quality. 

    Lean says the better approach is to focus on removing delays. 

    Full article: http://www.netobjectives.com/blogs/lean-agile-software-development-chapter1 


     Listen to the webinar audio Chapter 2: The Business Case for Agility 

    This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott.  

    This show focuses on Chapter 2, The Business Case for Agility. We cover the five most important reasons for going Agile and how it is that understanding the whys of Agile helps you with this transition. 

    It is important to understand the reasons for going Agile. Perhaps as important is understanding the whys of Agile: It helps you navigate your journey as you make the transition. Here are five of the most important reasons for going Agile: 

    1. Deliver value quicker.
      Getting to market quicker is good. It is often possible to deliver some important features in stages. It allows faster return with less investment and that is always good!
    2. Helping customers discover what it is they need.
      Agile is best understood as a process that helps customers and developers discover in stages what it is that software should do. It helps customers focus on specifying what they know and avoid having to guess about requirements that they are not yet sure of. The most important book that covers this is Software by Numbers by Denne and Clelland-Huang.
    3. Better project management.
      Waterfall tends to steer projects based on milestones, which is an inaccurate guide about where a project really is. Agile steers based on working code which is much more accurate.
    4. Improving process faster.
      It would be better if teams learned continually but at least Lean-Agile has them learn after each iteration. Short iterations let teams learn quickly what is working and what is not. It is much better to learn lessons after two weeks rather than after two months! 
    5. Letting your design emerge based on what you are learning.
      While it is often ignored, there is also a technical reason for going Agile. With some discipline and appropriate tools (automated regression testing), it is possible to avoid up front design (almost always wrong or incomplete) and allow design to emerge based on what the team is discovering. This is powerful. There are two good books that describe why this is so: 

    Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain

    Agile Software Development, Principles, Patterns, and Practices by Bob Martin

    Full article: http://www.netobjectives.com/blogs/lean-agile-software-development-chapter2-business-case-for-agility

    Listen to the webinar audio Chapter 3: The Big Picture

    This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott. 

    This show focuses on Chapter 3, The Big Picture. We talk about why, if you want to see improvements in throughput in product development, it is vital to focus on the entire value stream, the entire process from when an idea is formed until it reaches the user or customer. In fact, a transition to Lean-Agile involves agility in at least four areas.

    It is not enough just to focus on helping developers. In order to see improvements in the throughput for product development, you have to look at the whole value stream: the entire process from when an idea is formed until it reaches the user or customer. You want to focus not on where you are spending your money but where you are spending your time. And this means looking at the time you spend waiting as well. Keeping people busy can be counter-productive if it keeps them from being available on the most important things. Think of it this way: What is the impact if projects are having to wait on the most productive, highest value people just because they are working on too many things?

    Agile coaches often have a technical background. This means that too often, Agile deployments focus chiefly on helping developers. This is good and necessary but it is not sufficient. If delays are being caused elsewhere, then improving development will only offer marginal gains. When you are transitioning, you have to look at improving agility in four areas:

    • Team agility
    • Technical agility
    • Management agility
    • Business agility

    Of course, where to start depends on your situation.

    Read more: http://www.netobjectives.com/blogs/lean-agile-software-development-chapter3-big-picture

     Listen to the webinar audio Chapter 4: Lean Portfolio Management

    This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott. 

    This show focuses on Chapter 4, Lean Portfolio Management. The premise is that managing the work you are feeding the team is more important than how well the team works.

    What you want is for the business to drive small increments, giving the development team just enough to get value out at a sustainable pace. It is possible to do a better job planning! There are many techniques and that is the subject of another book. However, just knowing about shorter planning increments does help. Smaller, well-defined things running through the pipeline is better than big batches that clog things up.

    There is another benefit. We build these big project plans and even though we know they won’t work as laid out, they seem to take a life of their own. If someone proposes a change request, it is a huge effort because those plans are so cumbersome. Lean portfolio management cuts through all of this! Since we are planning in shorter cycles, if a new change comes through, we just compare it with all of the other requirements in the next cycle and insert it if has higher business value. Those change boards – so bedeviling – become a thing of the past.

    Read more: http://www.netobjectives.com/blogs/lean-agile-software-development-chapter4-lean-portfolio-management 

    Listen to the webinar audio Introducing Kanban for Software

    Phil Cave is a new consultant with Net Objectives. Phil has a long history with Lean, XP, Scrum, and Kanban. He has worked at all levels: developer, lead, manager, division manager, vice-president, Lean coach.  Phil just got back from Krackow, teaching our Lean Software Development course. Half of this course involved helping them integrate the Kanban technique into their Lean-Agile software methodology. Kanban is gaining ground as an important technique for Lean-Agile groups because it is widely applicable in both process-oriented and specialty-oriented shops. It does not require fundamental shifts in work (unlike other Agile methods) if that is not appropriate for you. It is something we need to learn more about.

    Here at the end of the year, I want to express how grateful I am for you. I hope you have a blessed holiday and a warm new year. I look forward to being with you again in January.

    Recommendations


    Links above are from the Net Objectives website at:  http://www.netobjectives.com/

    The Three M’s – The Lean Triad

    Posted by Roman Pichler on Feb 27, 2008 @ http://www.infoq.com/

    The discussion of applying lean principles to software development has largely focused on identifying and eliminating waste (in Japanese: muda). Lean Thinking equally aims to remove overburden (Japanese: muri) and unnecessary variation (Japanese: mura). Muda, muri and mura are called “the three M’s.” Together they form a dissonant triad. All three M’s must be eliminated to create a sustainable lean process. This article discusses the relationship between the three M’s and argues that the elimination of overburden should be the first step for software development organizations in order to create a lean process.

    (see the complete article: http://www.infoq.com/articles/lean-muda-muri-mura)

    bh

    Kanban

    Kanban is a lean approach to agile software development.

    ­­Actually, Kanban means many things. Literally, Kanban is a Japanese word that means “visual card”. At Toyota, Kanban is the term used for the visual & physical signaling system that ties together the whole Lean Production system.

    Most agile methods such as Scrum and XP are already well aligned with lean principles. In 2004, however, David Anderson pioneered a more direct implementation of Lean Thinking and Theory of Constraints to software development. Under the guidance of experts such as Don Reinertsen, this evolved into what David called a “Kanban system for software development”, and which most people now simply refer to as “Kanban”.

    ­So while Kanban as applied to software development is new, Kanban as used in Lean Production is over a half century old.

    Does Kanban matter to me?

    Do any of these sound familiar?

    • “We’ve done Scrum for a long time now and our process improvement has levelled off. How can we take our process to the next level?”
    • “Our needs and priorities shift on a daily basis”
    • “We don’t like fixed-length, fixed-commitment iterations”
    • “We are spending too much time planning and estimating”

    If so, read on. Along with Scrum and XP, Kanban should be part of the process toolkit of any agile company. The choice of where & when to use it can only be made by you though.

    How does Kanban work?

    There are many flavors, but the core of Kanban means:

    1. Visualize the workflow
      • Split the work into pieces, write each item on a card and put on the wall.
      • Use named columns to illustrate where each item is in the workflow.
    2. Limit WIP (work in progress) – assign explicit limits to how many items may be in progress at each workflow state.
    3. Measure the lead time (average time to complete one item, sometimes called “cycle time”), optimize the process to make lead time as small and predictable as possible.

    This is a direct implementation of a lean pull scheduling system.

    Here’s an example of a simple Kanban board, with WIP limits in red.

    Here’s a more complex one (see Kanban kick-start example for a closer look & description)

    Kanban board ­

    What are the benefits of Kanban?

    Some commonly observed benefits are:

    • Bottlenecks become clearly visible in real-time. This leads people to collaborate to optimize the whole value chain rather than just their part.
    • Provides a more gradual evolution path from waterfall to agile software development, thereby helping companies that previously have been unable or unwilling to try agile methods.
    • Provides a way to do agile software development without necessarily having to use time-boxed fixed-commitment iterations such as Scrum sprints. Useful for situations where sprints don’t make much sends, such as operations and support teams with a high rate of uncertainty and variabilty.
    • Tends to naturally spread throughout the organization to other departments such as HR and sales, thereby increasing visibility of everything that is going on the company.

    Can I combine Kanban with my current process?

    Yes. In fact, you should combine it.

    In Kanban the first step is to visualize your current process, just as it is, in order to see where the bottlenecks are. Then you introduce WIP limits and start a path of evolution that may or may not modify or replace your current process over time.

    See “Kanban & Scrum – making the most of both”, where Henrik Kniberg and Mattias Skarin illustrate how Kanban and Scrum relate to each other.

    Where is Kanban used?

    Our coaches at Crisp have helped several clients use Kanban to improve their process. In fact, a surprising number of our clients have found that Kanban is an extremely useful complement (or sometimes even a replacement) to other popular agile methods such as Scrum. Typical manager comment: “It really helps us visualize our projects and situation”.

    There is also an increasing number of case studies available at www.limitedwipsociety.org.  Here are a few examples:

    Common misunderstandings about Kanban

    • Myth: With Kanban you don’t use iterations
    • Fact: With Kanban iterations are optional. Do it only if you have a need for it in your context.
    • Myth: With Kanban you don’t estimate
    • Fact: With Kanban estimation is optional. Do it only if you have a need for it in your context.
    • Myth: Kanban is better than Scrum/XP/RUP/whatever
    • Fact: Kanban is just a process tool, and there is no such thing as a universally good or bad tool. It all depends on your context
    • Myth: Kanban is a drop-in replacement to Scrum/XP/RUP/whatever
    • Fact: Kanban is just about managing workflow. It hardly replaces anything. What it does do, however, is drive change. In Kanban you start with whatever process you have, visualize it, introduce WIP limits, and then evolve from there.

    Further reading