I understand the power Agile has on delivering software and the vital role rapid prototyping plays in product development (for physical things.) So when I came across a chance to learn about lean planning for the design and construction industries, I was predictably excited and intrigued.
The hands-on workshop was presented by the Lean Construction Institute and facilitated by Dan Fauchier. The majority of participants were architects, designers, and builders. I have to admit that I only heard of lean planning about three weeks ago, and I’ve never used it in practice, so unlike with Agile software development, I cannot profess any deep understanding or expertise. However, I felt like the workshop did a good job of demonstrating the tool and the technique of applying it. And I was immediately struck by some important similarities and differences.
The superficial, obvious similarity is the use of post-it notes. I pulled the images above from a simple web search on “last planner” and “agile software” respectively. While I don’t actually know that the images are what the report to be, I can certify that the pattern of post-its in the last planner workshop and pattern of post-its during a software sprint were very similar. But the foundational similarities and differences are far more interesting than the superficial similarity.
In considering the similarities and differences, I looked at five aspects of both systems:
- Communication and collaboration
- Team composition
- Notion of scope
- Medium and accessibility
- Flow of information
1. Communication & Collaboration
In both Agile software development and lean planning, the process and tool serves as a stimulant to foster communication and collaboration between team members – and in this way the two are very similar. In both cases, a wall covered in post-it notes has an ongoing, living role in the project, but a primary role is in unearthing information and forcing that information to surface to the group in a useful manner. To a large degree in both systems, the conversations fostered by the post-it notes are the main objective, and the artifact of the post-its on the wall are secondary. This is extremely important because no one person has all the answers, so communication is essential. As conveyed so beautifully in the 1958 essay, “I, Pencil,” things are created by a complex web of human interactions, and none of us alone knows all the steps to produce a moderately complicated thing. Indeed, we form teams to bring together the requisite set of skills, corporations to formally share the risks and rewards of our joint efforts, and partnerships to join the broader flow of value between industries. Collaboration is the hallmark of a team, and conversely, a team that does not collaborate is no team at all.
2. Team Composition
One of the early breakthroughs in Agile software development was establishing a cross-functional team at the beginning of the project – incorporating not just the software engineers, but also the voice of the customer (in the Product Owner) and designers to create a better UI and a better user experience. So too with lean planning, having all parties, across all disciplines, seems to be the best practice. One interesting note here is that with a building, there is a ‘real,’ actual client, who is brought into the planning process. Of course, in product management, we use personas and scenarios to bring to life for the team an idealized target customer and that customer’s desired experience. From some comments in the session on lean planning, I might even guess that a fictional, idealized customer in Agile is less likely to disrupt a project than an actual client by changing his or her mind part way through the sprint/project. And in Agile software accommodating such changes through the prioritization of the backlog is not just doable, but expected.
3. Notion of Scope
How scope is managed in construction and (agile) software is very different. In construction there is a fixed and defined scope, which is usually codified in drawings and contracts. There is not an opportunity to not finish the scope, so for example, leaving off the roof, or leaving out doors or sinks would be intolerable – and would preclude the client from occupying the building. In contrast, in software the scope is always changing, and it is said that “software is never finished.” In addition, it is frequently the case that partially developed but ‘incomplete’ software is useful nonetheless and can be released to the market with known deficiencies. In Agile these useful units are grouped together in releases and planned on a product road map.
These differences in how scope is handled lead to profound differences in how Agile operates versus lean planning. Consider the admittedly simplified equation:
Resources X Time = Output
In construction, output is fixed, so attention is focused on the efficient deployment of resources over time. The lean planning system focuses on establishing a network of “Reliable Promises” to create a project plan is both highly reliable and efficient. Each post-it represents a promise to deliver something to another person – given time and resources.
In Agile software development, the sprint duration is fixed, and in most cases, the team composition is more fixed than variable, leaving the output as the main variable. Consider our equation again, but substitute [Quality X Scope] for [Output.] Why do this? In Agile, there is the notion of maintaining working code at all times, and therefore having a zero tolerance for bugs. So we can break the project ‘output’ into the objective (absence of bugs) and the subjective (features, usability) – OR quality and scope. So within the Agile software development paradigm, resources, time, and quality are all fixed, leaving only scope as the variable. Agile focuses on establishing prioritized features to ensure that the highest value items consistently receive the investment of resources. Each post-it represents a “User Story,” which is a brief description of a user need. And at any time, it is very likely that there is a long backlog of user stories that will not be finished in the current sprint.
4. Medium and Accessibility
Both lean planning and Agile use color-coded post-it notes. That the patterns of post-its are similar is not particularly interesting to me, but the choice of media is. There is something magic about scrawling on a post-it note. The medium suggests that the content is ephemeral and subject to change. What’s more, the post-it is not the end, but rather a mere pointer or shortcut to the real idea. This unlocks our brains to operate without fear. We can begin to think and act and write, knowing that revisions are welcome. This is important because having an open mind and trying to be “right” often seem to be at odds. Whether negotiating a Reliable Promise or unpacking a User Story, it’s hard to get too attached to – or defensive about – a post-it note. Post-it notes stimulate discussions between team members; spreadsheets and PowerPoint presentations – not so much.
In addition, like many other lean production systems, in both Agile software and lean planning the information is public and visual. By making the information publicly viewable, the individual team members are more likely to keep commitments to one another. In addition, the visual nature allows the system to be understood at multiple levels – so that multiple audiences can derive value from examining the tool. For example, in lean planning, a supervision could see by the density of a certain color of post-its, where a certain trade will be critical while a particular contractor can see his particular dependencies.
5. Flow of Information
Consistent with lean production methods, both Agile and lean planning ‘pull’ information through the system. In the case of lean planning, the plan is generated by starting from the ultimate deliverable and working backwards to highlight all the interim items that necessarily must be produced to finish the project. Similarly, in Agile the highest value customer needs are identified to drive which features are developed first. Essentially, the customer pulls features through development. In both cases, pull prevents waste by making it less likely that unnecessary tasks are performed.
In both Agile and lean planning, pulling information requires breaking it down into its smallest logical, identifiable units – “Reliable Promises” in lean planning and “User Stories” in Agile. Dealing with the smallest possible unit benefits both systems by unlocking value sooner. In Agile, as soon as a User Story is complete, it is part of a candidate release, and as mentioned before, there are many cases where partially developed software is still very useful to the market. In lean planning, the earlier a promise to another can be fulfilled, the more likely it is that productive work dependent on that item can continue and the schedule can be met.
Final Observations and Future Discussions
Time is scarce. Always and everywhere. Period. So it’s not surprising that both Agile and lean planning formally deal with the issue of time, even if in very different ways.
In lean planning, creating a network of Reliable Promises creates a high fidelity schedule – one that is better understood by the entire team and less likely to contain nasty surprises. In lean planning, time is the scare resource that is explicitly planned and managed through the lean planning process. Accordingly, one of the KPIs in lean planning is PPC, which I believe stands for ‘percent of promises completed.’
In stark contrast, in Agile time is used like the beat of a song or a coxswain on a boat – providing the rhythm and motivating the team to keep a winning pace. As mentioned above, software is never finished, but there are still key dates and deadlines. So how does a team achieve a high sustained pace? The answer is the Sprint – a fixed duration work effort that typically lasts between two and four weeks, and results in working code. One of the KPIs is Velocity, which is a measure of the team’s throughput, and is typically measured in sprint points completed.
We get better. In the simple equation [Time X Resources = Output] I’ve neglected efficiency, and the equation – still simplified – could be written at [Time X Resources X Efficiency = Output.] The efficiency of a team is an important variable in determining its output. (Brilliant, I know…) I bring this up because in my experience efficiency is not fixed in Agile software development, and it improves with time as teams become more familiar with the process and more familiar with one another. Typically in Agile, the Velocity of the team improves over time – and I would expect a similar improvement to manifest itself for teams employing lean planning.
Talk to me. I believe that exposing oneself to diverse disciplines in work is beneficial – whether finding common patters across industries or seeing ways to introduce a tool from one industry to another. Despite finding some key differences, the similarities between Agile software development and lean planning stand out. Both systems…
- Seek to stimulate collaboration between team members early in the process
- Insist on having all relevant parties included, and teams are comprised of individuals with different backgrounds, experience, and skills
- Are flexible, informal, and publicly accessible
- Pull information from those most likely to have it
It makes me wonder where I else I might find systems that stimulate cross-functional collaboration, use visual, public information, and pull information. If you know of any other such system, I would love to hear about it.