Agile Goes Big Using SAFe

This week I had the opportunity to meet and hear Dean Leffingwell talk on Scaled Agile Framework (SAFe) and its history. It was fascinating to hear him recount the early days of Agile, and how the SAFe came into existence. What impressed me most was how he continually tied Agile and SAFe back to the teachings of Taiichi OhnoW. Edwards Deming, and to the Lean concepts underpinning Agile. I am a late arrival on the software development scene, and I was working to improve First Call Resolution in an airline call center while people like Dean, Al Shalloway, and Mary and Tom Poppendieck were figuring out how to apply Jim Womack’s  “lean thinking” to software development. It was a great presentation and while I have many more questions than answers, I am sold on the concept that Agile can scale effectively.

The Scaled Agile Framework (SAFe) is a proven knowledge base for implementing agile practices at enterprise scale. SAFe’s primary user interface is a “Big Picture” graphic (http://scaledagileframework.com/) which highlights the individual roles, teams, activities and artifacts necessary to scale agile from the team, to teams of teams, to the enterprise level. (The image at the top right is literally just one corner.) If you are serious about process improvement in the IT space, I strongly recommend you check this out.

(http://scaledagileframework.com/)

Image-Detail of the Scaled Agile Framework (SAFe) Big Picture.

The Scaled Agile Framework is a proven knowledge base for implementing agile practices at enterprise scale. Its primary user interface is a “Big Picture” graphic which highlights the individual roles, teams, activities and artifacts necessary to scale agile from the team, to teams of teams, to the enterprise level.

The Big Picture describes three levels of scale:
Team, Program and Portfolio. Each of these scales the essential agile elements of Value (requirements and backlogs) Teams (from development team through portfolio) and Timebox (iteration, PSI, budget cycle). This model of agile adoption has been elaborated primarily in Dean Leffingwell’s books Agile Software Requirements: Lean Requirements for Teams Programs and the Enterprise (2011) and Scaling Software Agility: Best Practices for Large Enterprises, (2007) and his scalingsoftwareagility blog.


Further Reading

Leffingwell, Dean (2011).
Agile Software Requirements, Lean Requirements Practices for Teams, Programs, and the Enterprise,
Addison-Wesley Professional, ISBN 978-0321635846.

Leffingwell, Dean (2007).
Scaling Software Agility, Best Practices for Large Enterprises,
Addison-Wesley Professional, ISBN 978-0321458193.

 

Bob Hubbard, July 2013

Can Software Development Be Agile & Autonomous?

Those of us who work in the software development world are familiar with the term ‘agile’. But for us, this term is related to the Agile Manifesto. In Vijay Kuman’s TED talk, he speaks about ‘agile autonomous’ robots. He shows that decentralized control, local information, and anonymity work in this physical world. I wonder if we could use the same principles. He notes that the larger you make the quadrotor copter, the more inertia you have and the less agile it is.  Hmmm… that sounds awfully familiar.

About this video: In his lab at Penn, Vijay Kumar and his team build flying quadrotors, small, agile robots that swarm, sense each other, and form ad hoc teams — for construction, surveying disasters and far more. At the University of Pennsylvania, Vijay Kumar studies the control and coordination of multi-robot formations.

Essence of Agile from Henrik Kniberg

I love Henrik’s agile slides. His work is quick and to the point, and visual enough to keep you interested and occasionally make you laugh.
Bob H

Mapping a Value Stream to a Kanban Board

Lean Leaders: I’ve attached a link to a video from Alan Shalloway at NetObjectives. In this video, Alan Shalloway describes the process of mapping a value stream to a Kanban board and why both are important in improving business-driven software development… and he accomplishes all that in 15 minutes.

Kanban Distilled for Managers

This is a repost from kanbandistilled.com/ . Their website reports that they will be back soon… but until then, here is a great explaniation of how a kanban can work in software development. If you’re interested, click here for a Lean Glossary (adapted from Richard Durnall’s blog).
 
Bob Hubbard, Atlanta Georgia USA

Kanban is a technique for managing a software development process in a highly efficient way. Kanban underpins Toyota’s “just-in-time” (JIT) production system. Although producing software is a creative activity and therefore different to mass-producing cars, the underlying mechanism for managing the production line can still be applied.A software development process can be thought of as a pipeline with feature requests entering one end and improved software emerging from the other end.

Software Pipeline

Inside the pipeline, there will be some kind of process which could range from an informal ad hoc process to a highly formal phased process. In this article, we’ll assume a simple phased process of: (1) analyse the requirements, (2) develop the code, and (3) test it works.

The Effect of Bottlenecks

A bottleneck in a pipeline restricts flow. The throughput of the pipeline as a whole is limited to the throughput of the bottleneck.

Using our development pipeline as an example: if the testers are only able to test 5 features per week whereas the developers and analysts have the capacity to produce 10 features per week, the throughput of the pipeline as a whole will only be 5 features per week because the testers are acting as a bottleneck.

Effect of Bottlenecks

If the analysts and developers aren’t aware that the testers are the bottleneck, then a backlog of work will begin to pile up in front of the testers.

The effect is that lead times go up. And, like warehouse stock, work sitting in the pipeline ties up investment, creates distance from the market, and drops in value as time goes by.

Inevitably, quality suffers. To keep up, the testers start to cut corners. The resulting bugs released into production cause problems for the users and waste future pipeline capacity.

If, on the other hand, we knew where the bottleneck was, we could redeploy resources to help relieve it. For example, the analysts could help with testing and the developers could work on test automation.

But how do we know where the bottleneck is in any given process? And what happens when it moves?

Kanban reveals bottlenecks dynamically

Kanban is incredibly simple, but at the same time incredibly powerful. In its simplest incarnation, a kanban system consists of a big board on the wall with cards or sticky notes placed in columns with numbers at the top.

Limiting work-in-progress reveals the bottlenecks so you can address them.

The cards represent work items as they flow through the development process represented by the columns. The numbers at the top of each column are limits on the number of cards allowed in each column.

The limits are the critical difference between a kanban board and any other visual storyboard. Limiting the amount of work-in-progress (WIP), at each step in the process, prevents overproduction and reveals bottlenecks dynamically so that you can address them before they get out of hand.

Worked Example

The board below shows a situation where the developers and analysts are being prevented from taking on any more work until the testers free up a slot and pull in the next work item. At this point the developers and analysts should be looking at ways they can help relieve the burden on the testers.

Notice that we’ve split some of the columns in two, to indicate items being worked on and those finished and ready to be pulled by the downsteam process. There are several different ways you can layout out the board. This is a fairly simple way. The limits at the top of the split columns cover both the “doing” and “done” columns.

Once the testers have finished testing a feature, they move the card and free up a slot in the “Test” column.

Now the empty slot in the “Test” column can be filled by one of the cards in the development “done” column. That frees up a slot under “Development” and the next card can be pulled from the “Analysis” column and so on.

Next steps

How to get started with Kanban…

  1. Map your value stream (your development process).
    Where do feature ideas come from? What are all the steps that the idea goes through until it’s sitting in the hands of the end-user?
  2. Define the start and end points for the Kanban system.
    These should preferably be where you have political control. Don’t worry too much about starting with a narrow focus, as people outside the span will soon ask to join in.
  3. Agree:
    • Initial WIP limits and policies for changing or temporarily breaking them
    • Process for prioritising and selecting features
    • Policies for different classes of service (e.g. “standard”, “expedite”, “fixed delivery date”). Are estimates needed? When choosing work, which will be selected first?
    • Frequency of reviews
  4. Draw up a Kanban board.
    All you need is a whiteboard and some Post-It™ notes. Don’t spend too much time making it look beautiful because it will almost certainly evolve.
  5. Start using it.
  6. Empirically adjust.

from kanbandistilled.com/

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.