Another wonderful bit of wisdom from Lean Agile thought leader, Al Shalloway. In my experience, no matter what the organizational problem, the solution is always better leadership.
Lean Leadership and Systems Thinking
Agile has somewhat left out management. While acknowledging the need for business stakeholders to get involved and leadership at all levels, management is not mentioned even once in the manifesto. But both the role of leadership and management is essential. Agile’s focus on the individual has had us take the focus off where it needs to be – on the organization in which the individual can or doesn’t thrive.
We don’t need to focus on people, they are already good & motivated. but management’s role is to provide them a place within which to shine. This is the essence of Lean-Management. Focus on the workflow and the environment in which people can work better. In other words, create an environment within which teams can work autonomously toward the common goal of realizing business value quickly.
Lean-Thinking is based on leadership and systems-thinking.
The following is a paraphrase of Russell Ackoff from Creating the Corporate Future: Plan or be Planned For
Systems Thinking is a mode of thought that begins with SYNTHESIS before ANALYSIS:
Identify the containing whole(system) of which the thing to be explained is part.
Explain the behavior or properties of the containing whole
Now, explain the behavior or properties of the thing to be explained in terms of its role(s) or function(s) within its containing whole.
Al Shalloway is an acknowledged thought leader in how we design and develop software. In this post, he begins the conversation about where we are headed next. It seems that everyone is in software development these days and most agree that we need to improve. Al notes that the original manifesto mentions the Agile Manifesto mentions “the team 17 times, the customer 3 times, business twice and management not at all.” But rather than impaling the sacred Agile Manifesto cow, he offers us a place to start the conversation with his personal manifesto.
I think this is a wonderful place to start a conversation about where we go from here. If you have an opinion about how the software business needs to change, I encourage you to read this post.
Background and the Agile Manifesto.I have been asked several times to help in the rewrite of an Agile Manifesto. After having been involved in Snowbird 10 (the reunion of some of the original Agile Manifesto authors along with some others from the Lean/Kanban community) I realized there is no “Agile” community. Rather we have many sub-communities that are so diverse it is hard to think of them as being under one umbrella. click here for more…
Source: A Personal Manifesto | Net Objectives blog
A user story represents a small piece of business value that a team can deliver in an iteration. While traditional requirements (like use cases) try to be as detailed as possible, a user story is defined incrementally, in three stages:
The brief description of the need
The conversations that happen during backlog grooming and iteration planning to solidify the details
The tests that confirm the story’s satisfactory completion
Well-formed stories will meet the criteria of Bill Wake’s INVEST acronym:
We want to be able to develop in any sequence.
Avoid too much detail; keep them flexible so the team can adjust how much of the story to implement.
Users or customers get some value from the story.
The team must be able to use them for planning.
Large stories are harder to estimate and plan. By the time of iteration planning, the story should be able to be designed, coded, and tested within the iteration.
Document acceptance criteria, or the definition of done for the story, which lead to test cases.
Why use user stories?
Keep yourself expressing business value
Avoid introducing detail too early that would prevent design options and inappropriately lock developers into one solution
Avoid the appearance of false completeness and clarity
Get to small enough chunks that invite negotiation and movement in the backlog
Leave the technical functions to the architect, developers, testers, and so on
How do I write user stories?
When getting started with stories, a template can help ensure that you don’t inadvertently start writing technical tasks:
As a <user type>, I want to <function> so that <benefit> .
As a consumer, I want shopping cart functionality to easily purchase items online.
As an executive, I want to generate a report to understand which departments need to improve their productivity.
Try to avoid the generic role of User when writing user stories. User stories are about all of the role who interact with the system or who realize some value or benefit from the system. Not all actors are end users. For example, a role could be another system or someone who wants certain functionality in order to buy your product but will never actually use the product. It may be useful to create aggregate roles (such as consumer) and specialized roles (such as browser or frequent shopper).
In Rally, this template should be entered at the top of the Description field. This sets the tone for the details and acceptance criteria, which will be entered below.
I became an advocate for continuous improvement when I discovered that when we improve processes, we also improve people’s lives. Bruce Feiler’s TED Talk on agile families is well worth your time. I regret that I did not use these techniques when my daughters were younger, but I can certainly spread the message, starting NOW!
Bruce Feiler has a radical idea: To deal with the stress of modern family life, go agile. Inspired by agile software programming, Feiler introduces family practices which encourage flexibility, bottom-up idea flow, constant feedback and accountability. One surprising feature: Kids pick their own punishments.
If you have been here before, you know I’m a huge fan of Dean Leffingwell and his work on Agile. It seems that the mainstream business community is finally catching up. This is a great article by Jason Bloomberg for Forbes.
Scaling Agile Software Development for Digital Transformation
True digital transformation initiatives require change at multiple levels of the organization. Revamping the customer experience with digital technologies is never a superficial change, as it requires better, more flexible software as well as a dynamic, agile organization to drive innovation and to respond to marketplace changes.
Agile software methodologies like Scrum and Extreme Programming (XP) are now established approaches for building software in dynamic environments. Agile approaches don’t solve every software problem, however, as they typically work best with relatively small, self-organizing teams.
Scaling Agile to the enterprise level is a challenge that The Scaled Agile Framework® (also known as SAFe™) means to address, as it combines Agile approaches with more enterprise-centric organizational practices. Yet, while SAFe has led to several dramatic successes, challenges still remain, especially as enterprises undergo the broader organizational change necessary for digital transformation success.
Success with SAFe™
SAFe is an interactive knowledge base for implementing Agile practices at enterprise scale, according to its Web site. This enterprise-driven approach is largely the brainchild of Dean Leffingwell, Director and Chief Methodologist at Scaled Agile, Inc. Leffingwell has been a leader in the software development industry for decades, having founded Requisite, Inc., the makers of the RequisitePro requirements management tool, now part of IBMs Rational division.
According to Leffingwell, Agile methodologies alone do not address top-down questions of business strategy, as Agile teams work bottom-up. “You can’t add up opinions of people to come up with the business strategy,” explains Leffingwell. “Some things require centralized decision making.”
SAFE, therefore, provides the organizational structure for top-down, centralized decision making that works in conjunction with self-organizing Agile teams. “SAFe promotes the core values of empowerment and decentralization of control, but not the decentralization of everything,” says Leffingwell. “Cascading centralization and decentralization leaves empowerment to the troops.”
In fact, neither top-down nor bottom-up adequately describe SAFe, according to Leffingwell. “Program execution happens at the program and team levels,” he explains. “The traditional models of centralized program planning and micro-technical-management are a thing of the past with SAFe. That is empowering.”
This balance of top-down control and bottom-up empowerment has shown notable success at several enterprises. “We’ve seen extraordinary work,” Leffingwell says. “30-50% improvement in productivity and quality, as well as a 2X – 3X improvement in time to market.” Furthermore, many SAFe success stories had little or no Agile to begin with. “BMC Software, John Deere & Co, Discount Tire – none had real Agile at the start, or maybe just a few Scrum teams.”
John Deere, in fact, is one of SAFe’s most notable success stories. “We knew we needed to increase our speed to market while keeping our budget and resources static,” said Steve Harty, former Agile Release Train Manager at John Deere. “Moving our team to Scrum was scary, challenging, and liberating, all at the same time. Scrum was ‘our little secret’ that helped move our delivery time timeframe from 12-18 months to 2-4 weeks. Plus, our engineering teams were happier and customer satisfaction went up.”
Alex Yakyma is a thought leader in the SAFe community and this is a great article on the how’s and why’s related to kanban within the Scaled Agile Framework (SAFe).
Kanban for SAFe Teams
By Alex Yakyma
The use of Kanban techniques for managing workflow is growing in software, as well as in other industries. Originally a technique derived from lean manufacturing, Kanban is a lightweight way of visualizing and managing work of any kind. It’s easy to adopt and provides sophisticated constructs for continuing improvement as teams master the method.
While not a software-specific method by original intent, its application in software development can be quite useful. It provides a more granular view of the flow of work through the team, illustrates bottlenecks and delays to be addressed, and increases flow by application of work-in-process limits. Properly used, Kanban provides a powerful set of constructs that every software enterprise should be able to apply in the scaled systems context. This article describes how Kanban can used by SAFe Teams in the content of their Agile Release Train.
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 Ohno, W. 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.
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.