Presto-Bingo, You’re Agile!
Agile for Hardware Discussion Panel Recap
On Tuesday July 28th, we hosted and participated in a virtual executive discussion panel on the topic of the cost of a defect in hardware. The focus of the conversations were around how the cost of a defect can have a significant impact on organizations as it pertains to hardware development. It was a lively conversation with key insights into how to leverage lean-agile approaches across the organization to help mitigate many of the traditional pitfalls that risk measures have attempted to prevent. You can watch a recording of the event here: Executive Panel Discussion on the Real Cost of a Defect in Hardware.
During the event a final question was asked but the panel was out of time to respond to. We wanted to take the time to address this question. The question was “What do you think about some agilists and advocates of the “Sprint Zero” or hardening sprints for those teams building complex systems (basically “waterfalling” within whatever their cadence is for those HW teams)? Is it a good practice for HW that is different from SW?”
This is an interesting question because it alludes to several topics covered by the panel that we’ll go into a little more depth on here, starting with the most basic part of the answer.
While a specific answer cannot be provided without more context and an understanding of the timeline of progress towards agility, these types of questions may point to a common anti-pattern in thinking of polar opposites (agile “purists” vs. the “wild, wild, west).
Sprint Zero
The words “Sprint” and teams, indicate the question is focused at the team level. The answer to the question has to be more broad and take the entire system into consideration. First, why would anyone advocate for a Sprint Zero? There are a ton of great reasons why Sprint Zero’s are great, however that answer is in a bit of a vacuum in that it makes some significant assumptions.
Let’s talk team. In Agile terms, a team is 7 +/- 2 people who work together long term; they persist longer than a project; in fact projects should take on different meanings as an organization moves towards agility. A team in this context is typically different from a work group of people brought together for a project. Sprint Zero serves many purposes, one of which is to set the groundwork for how this group of people choose to work together; what is the flow of work for the team, what are the steps it takes to get a Story to Done, lay out teaming agreements, cadence, etc. If the “team” only exists for a project (even if a long project), they will not be allowed to fully mature through the Tuckman stages, thus it is highly unlikely they will be able to achieve the benefits that many associate with a move to agility. So if the organization has committed to long lived teams, decentralized decision making, and changing from bringing people to projects, to bringing work to teams, then a Sprint Zero for new team formation makes perfect sense and will help get them off to a great start. If on the other hand, people are being brought together for a project (maybe they are working on multiple projects), then the typical activities conducted during Sprint Zero, offer much less benefit. The way to think about a Sprint Zero is for the benefit of a new team, not for kicking off a new project.
A quick note on work groups and teams. There is a great wealth of research that shows long-lived teams outperform shorter (project) based teams. The word team is often used to mean short and long term groups of people. If you think of a sports team, although a few members may change on a yearly basis, the team stays fairly consistent for long periods of time. When a college football team has a majority of seniors who are starters, we often see lower performance the next year, as an example. In business we see the same type of performance. We can summarize this performance using the Tuckman stages. If we would like our teams to become high performers, we have to let them gel long enough to get there, meaning typically beyond the life of a project. Bringing work to teams will, according to the research, consistently result in higher performance than when people are brought to work (projects).
Hardening Sprints
In the old days we used hardening sprints as a way of doing a few different things. We used them for “ility” testing (non-functional), refactoring and other stuff we knew we needed to do, so we allotted specific time to do them differently from the time of creating new cool stuff.
This was during a period of time where we saw a lot of thought leaders working on the problem of how to scale agile. I use that term loosely, meaning answering the question “how do we coordinate, collaborate and achieve those same desirable outcomes we got out of a single product team for a product that takes hundreds of people across multiple disciplines?
Today, hardening sprints are more of a holdover and can sometimes indicate other areas that need improvement. That said, as an organization transitions, some practices may be useful to bridge a gap during the journey. For instance, no one can expect a team, program, value stream, organization to change overnight. Change takes time and will require effort and maybe a little discomfort. Use patterns like hardening sprints because it makes sense for a specific point in time. It is important to address the underlying things that led to the need for a hardening sprint. Once those underlying issues are addressed, the hardening sprint is rarely needed.
Hardware Rarely Involves One Team
The premise of the question was focused on a team. In the hardware arena, it is almost never the case that a single team can bring a product from concept to cash. System thinking rules the day in the journey to agility, even in IT software, but in particular when it comes to large complex hard products.
What we often see is that there is too much focus at the team level. In system thinking, we understand that to optimize the whole, some subsystems may need to be sub-optimized. If we focus on the team and don’t fix the system in which they have to work, they will eventually end up running up against a wall that is the system in which they have to operate.
Governance, process, accounting, policies, etc. can all have a dramatic impact on an organization’s move to agility. And they very much need to be a part of the change. System thinking applies here just as much.
Large moving systems of people collaborating to bring awesome products and services to reality in a way that also aligns with organizational goals (meeting market demand, time to market, usefulness, customer and employee satisfaction scores, etc.) is exactly what a lean-agile mindset can help you achieve. Agile can be thought of as a mindset, but not the goal. Organizational goals are typically aligned with business, industry, segment, product desirable outcomes. We can leverage lean-agile approaches, patterns, practices, techniques etc. to help achieve those goals. Teams are just one part of a much larger system of interconnected moving parts.
Iterative Waterfall
Waterfalling was a term used in the question that rears its ugly head quite often. Waterfall as a delivery approach is a useful approach under certain circumstances. I rarely see those criteria being met though.
It is very easy to embrace iterative-waterfall. Take a bunch of people. Align them to projects. Make sure different people are on different projects, with a few that overlap. Make sure the projects are well defined, or at least you think they are. Make sure that 100% of people’s capacity is spread across those projects and don’t take context-switching into consideration. Then, have them “switch” to Scrum (for every project). Presto-bingo you’re Agile!
Okay, sarcasm aside. You either identify with that last paragraph or you inherently understand that approach is basically the antithesis of the whole concept of agility.
An iterative approach to delivery is only one of many things (methods, approaches, frameworks, etc.) that often benefit today’s product delivery. It’s not the end-all be-all either though. Scrum is often conflated with Agile. Scrum is just one of many different frameworks out there. Frameworks consist of many different practices. One of the keys in adopting a lean-agile mindset is recognizing that these practices and frameworks are the “doing side” of agility, you also have to take care of the “being side”..
The “being side” is grounded in values and principles. Only when you understand and embrace the values and principles behind these practices and frameworks, does it start to make sense which to leverage and how you make adjustments that make sense in terms of moving towards achieving business agility.
The question posed the conundrum of why some agile approaches have a hard time in hardware product environments. It’s pretty hard to plan in multi-week increments when you have a month long wait time for a supplier to return a board so that you can start testing the actual integration (just as an example). Does iterative work in hardware? Yes – and. Yes it can, and often we find that a flow approach works even better. This is where understanding the values and principles works to your advantage. Understanding concepts like why holding cost versus transaction cost matters. Embracing concepts like batch size, and limiting work in progress are so important. Another thing to consider is that different product areas may need different approaches.
Beware of the iterative waterfall. Remember, the goals of the business are not to install an agile framework or a bunch of agile practices; goals should be tied to business outcomes. As we go about changing how people work, we always have to make sure that the desired outcomes are what are being achieved.
It’s Okay to be Different
Building on the concept of different approaches, it is okay to be different. Adopting and adapting to Agility does not have to mean that all teams have to take one approach or another, often it is a blending of approaches and cadences. Often this can mean that one area (let’s say hardware fabrication) might have longer wait times than other areas such as runtime software.
We often find three different cadences within a single hardware program. One is typically focused on fixed or long wait times; one is typically focused on flow; and one is typically iterating to get early feedback.
The challenge then becomes being transparent across those areas, enabling collaboration, managing risk and embedding governance. Approaches such as big room planning can help; built in quality (into the process at each step of the way); meaningful metrics such as defect phase containment, etc. all go into creating more visibility, faster feedback loops, decentralized decision making and adding safety nets such that teams have the ability to make more local on-demand decisions.
What Agile Does Best
The move to agility does one thing particularly well. That one thing is what often causes organizations (especially leaders – don’t shoot the messenger) to struggle. The move to agility shines a really bright light on what is already not working. It won’t though, as some may suggest, fix them. Agile is not the/a solution. Agile is often a victim of its own bright light. I have heard things like “agile didn’t work in our environment”, or “agile wasn’t flexible enough”, etc. The move to agility will point out challenges, situations, practices, behaviors that you might not like – don’t approach these as though agile needs to conform to that “thing”, each is an open opportunity to change something that isn’t working. If you tailor an agile practice to something that isn’t working, it still won’t work. Fix the thing that isn’t working, but do it with a lean-agile mindset.
Wrap-Up
Thank you for the excellent question. Thank you to all those who participated in our panel discussion. We’ve also hosted a much larger webinar on a related topic: Download the Webinar on Demand: How to Mitigate the Risks of “Push to Get Things Done” with Agile Hardware Development.
Agile In Hardware
Learn more about Agile in Hardware here.
