Recently, I have had the chance to work closely with a number of projects that were not pure software. They all had some software or firmware component but they also included an electronics or even mechanical design aspect. Below are the top ten questions I recorded when working with these teams and the answers on how the teams effectively answered them.
1. Are Agile practices and processes effective when conducting non-software projects (firmware, electronic, mechanical, etc.)?
Absolutely. Some of the XP engineering practices are not directly applicable or need to be modified based upon industry or your particular situation. However, surprisingly minor adjustments are all that is necessary for the Scrum process framework to be highly effective… even compared to processes that evolved specifically for hardware.
2. What adjustments need to be made to make to the Scrum process framework work well for these projects?
Surprisingly few. The primary adjustments center around expectations in two general areas: (1) minimal marketable feature/emergent design/thin vertical slices, and (2) user stories.
3. What adjustments need to be made to our expectations around minimal marketable feature, emergent design, and thin vertical slices?
Focus on feedback. True, the break even point between thinking versus building encompasses more thinking for non-software projects. Even so, push to build something sooner and even when you are working on early design and infrastructure, get feedback on some “product” each iteration… and get that feedback from a source as close to the user as possible. In software, it’s almost always less expensive and more effective to build something rapidly, get feedback on it from an actual user, and change it, than it is to think longer about how to build it expecting to avoid later rework. This is the primary reason why Agile practices encourage you to break up the work into increments of minimal marketable features (MMF). Agile software projects try to build as little infrastructure as necessary to implement the current MMF and let the design emerge from those increments rather than nail down all the requirements and design up front. You are encouraged to build the system in thin vertical slices where all levels of the product experience changes with each increment.
When confronted with this idea, even software-only teams push back. Software teams want an architecturally sound base upon which to build their features. However, I have found that if the team thinks on it for a bit, they can often find a way to build usable features and start to get feedback much sooner than the team originally imagined. Those projects are able to deliver a marketable feature even in the first few iterations and they move rapidly to a mode where very little of each iteration is spent on infrastructure. The primary difference for hardware projects is that you have a different cost structure for manufacturing so the break even point for thinking versus building encompasses a bit more thinking. This means that it may take longer to get into the mode of designing several MMFs each iteration.
Remember, the primary benefit of this approach is to get the most valuable possible feedback as often as possible. So even when it is hard to use thin vertical slices to accomplish that, you should still seek out opportunities to enhance the richness and frequency of the feedback you receive by producing something to get feedback upon during EVERY iteration. The next step down from demonstrating an MMF is producing a prototype but even that can be hard to do every iteration of a hardware project. So when the thing you produce is only a document, a design, or an experiment, make an effort to maximize the value by choosing to get your feedback from a source as close to the customer as possible.
4. What adjustments to our expectations need to be made around user stories?
Understand that the “user” in user stories only hints at one of four good reasons to manage requirements with user stories… and it’s not the most important reason, “conversations.” Maybe they should be called “conversational stories.” The big hang-up of hardware teams managing requirements with user stories focuses around the word “users”. That’s unfortunate because I don’t think that is the most important benefit that Agile teams (even software teams) get from the practices surrounding user stories.
The benefits come from four aspect: (1) WHO, (2) WHAT, (3) WHY, and (4) conversations. This last one, conversations, is the most valuable so I’ll talk about it first.
Even when drafts of requirements documents are shared with the development team for early feedback, the development team doesn’t internalize them until they start working with them. By having the team size, and often write user stories, you force them to start this internalization much sooner. The early conversation between the development team and stake holders around the requirements allows for implementation costs to be factored into requirements tradeoff decisions. The ongoing conversation throughout the project lifecycle, provides a high-fidelity communication channel and continuous vision alignment.
Now, let’s address the other three beneficial aspects one at a time. The traditional user story format is, “As a WHO, I want to WHAT, so that I can WHY.” All three of these, WHO, WHAT and WHY, provide benefits. The tension of trying to always make the WHO be an end user is not unique to hardware. Even in the most Agile of software-only teams, there are times when the end user is only indirectly the beneficiary of a particular backlog item. For instance, the most direct beneficiary of a research activity, a mockup, or a prototype (collectively referred to as a “spike” in the agile world) is the development team and not the end-user. In those cases, specifying the WHO does not encourage you to think about the product from the end user’s perspective. If every user story were this way, then we wouldn’t call them “user stories”. The “user” is in the phrase to remind us to get the user perspective involved as often and as soon as possible but just like MMFs, this practice is harder to do as often especially early in a hardware project.
I will not dwell on the WHAT because this element is present in all approaches to requirements management, except to mention that it is important for the what to not drift over into the HOW so the development team has flexibility in how they meet the identified need. Note: The Rally tool’s entity for “user stories” is really more of a generic backlog item. There is nothing in the tool that enforces or even makes awkward, the use of this entity in a traditional work breakdown mode.
On the other hand, the WHY is somewhat unique to the practice of user stories and can be very valuable. Understanding why someone wants something empowers the development team to be creative about satisfying a need… sometimes even by explicitly not satisfying the WHAT of the user story. If a team is told that it must implement a data layer with sub-millisecond response, they may blindly go about accomplishing that… at great cost. My first response to a user story written like that is that it crossed the border from WHAT and into the realm of HOW. Nevertheless, even if you give a team a user story like that but you also tell them that the reason for this “requirement” is the responsiveness of the user interface, they may take steps to provide low latency to user input even when the data does not make it all the way to the data layer for a second or more… saving cost AND improving the product.
5. What about prioritizing user stories strictly by value to the end user?
Prioritize by overall business value, not end user value. Even in software-only projects, user stories should be prioritized by overall value to the business, not the end user. Often that is the same thing and certainly, the end user’s needs are the biggest factor in prioritizing any user story with an end-user as the WHO. However, a feature that is desirable to the end user but not saleable might not be valuable to your business. Similarly, valuable features that are too costly (either to produce or as tradeoff for against other desirable features) might not be good decisions.
Apple has been criticized for excluding multi-tasking from the iPhone. They realized that multi-tasking negatively impacted battery life and user interface responsiveness and explicitly left it out of product. They made a business decision that they could still sell the iPhone even without this high profile feature.
However, before they made this decision, they needed some information. How much did background tasks hurt battery life and responsiveness? How amenable will potential customers be to purchasing a product without it? Apple can easily justify investments in research to determine the extent of this impact on both the usability and marketability of the product. This information is of no direct benefit to the end-user but the work necessary to gather it, was of immense benefit to the business.
Development projects of all kinds benefit from good design and marketing decisions. Backlog items focused solely on these outcomes are of value to the business and should get appropriate prioritization. Similar to the above discussion on MMFs and the WHO in user stories, it just may be that non-software projects experience more of these tradeoff analysis backlog items early in the project and they keep seeing them longer into the development cycle.
6. Should user stories be our only tool for requirements management?
Not usually for hardware/mixed projects. There are many reasons why you might want some other mechanism to compliment your user story practice. For instance, the concept of abuse cases is often part of a larger security review. Safety reviews often have a parallel mechanism. Protocols and other interfaces are best defined by other means. Hardware typically have requirements associated with the operating environment. Etc.
7. But user stories are not even an official requirement of Scrum so why shouldn’t we just use our traditional requirements practices?
Consider alternatives but remember all four valuable aspects of user stories. It is true that the official definition of Scrum simply calls for there to exist a backlog of work. It only mentions user stories in a sidebar and even then, the sidebar also mentions other approaches like use cases. The essence of Agile is (1) self-organize, (2) do something, and (3) inspect and adapt. The definition of Scrum is just one step more detailed than this essential definition of Agile and is intentionally minimalistic so any iterative agile approach would fit.
User stories have emerged as a common and valuable practice because of the reasons mentioned above but it is not strictly required. Your team should feel empowered to consider alternatives.
However, if your team chooses another approach to doing requirements management, you should not deviate from the agile practice of allowing the development team to do the estimating. Also, I encourage you to think about the reasons the practices surrounding user stories are valuable (other than the emphasis on the user) as described above and enable as much of those reasons as possible, starting with the conversation aspect.
8. What about when we need to send a board (or prototype part) out for manufacturing and it will not be done within an iteration?
Push for rapid prototyping but adapt to your capability. This is a very specific question that comes up often when folks are told that they need to produce something upon which to get feedback during each iteration. What if the time it takes to get prototype parts back from manufacturing is longer than an iteration?
My first response is to ask yourself, “Is there ANYTHING that we can do so that we CAN produce a prototype in a iteration?“ The world of prototyping has attempted to keep up with the ever-increasing pace of change. There now exist component suppliers that allow you to upload a part design in the morning so that they can produce and ship it overnight. Those services are expensive but so is the time of your team. Failing some solution like that, “Is there a different way to produce something to get the answers and feedback we need for decisions within a single iteration?”
If you still cannot think of a way to produce it within one sprint, you can handle it by breaking the backlog item down. The first portion includes whatever work is necessary to place the order for the part. The later portion includes any evaluation activities. Collectively, they have value to the business.
9. What about dependencies and critical path analysis?
Supplement when needed but ask if it is really needed. Dependencies are considered by the product owner and the development team when choosing stories for a particular iteration. However, the consideration of dependencies is informal and not explicit like in a Gantt chart format (think Microsoft Project). I have worked with teams where explicitly and continuously conducting this sort of critical path analysis is…. well… critical to their success; but I have worked with many more teams where the use of a Gantt chart is merely the default and what they are used to. For those projects, the most important thing is for each team member to know what they should be working on right now and have a sense of urgency about getting it done-done! The mechanisms in the Scrum framework are highly effective at accomplishing this. If you do need to conduct critical path analysis at some point, I suggest that you do it only as needed.
Note: The Rally tool includes functionality for you to record dependencies so that they are readily available when you are making decisions about what to work on next.
10. Maybe we don’t need continuous critical path analysis, but we still have specialists that are not permanently dedicated to the team. How do we deal with that?
Favor cross-training and using generalist team members but fall-back to explicit allocation and coordination when necessary. The Agile approach is to fully dedicate as many of these specialists to the team as possible. Even when you know it’s not a full-time job for a particular specialty, it still might be better to supplement those specialists’ workloads with team tasks that are outside of their specialty. We find that becoming Agile tends to encourage more generalists (or at least multi-specialists) to emerge. This cross-training is generally positive on its own merit but double so when you factor in the cost of task switching and the productivity befits you get once a team learns how best to work together (think Forming-Storming-Norming-Performing).
Even so, there may still be some centralized functions that your teams will need to consult. It is often possible to handle these situations by leveraging the team’s approach to dealing with outside suppliers.
When you move the solid line from a functional manager to a team lead and make the functional manager the dotted line, it will bring up many issues like personnel reviews and career counseling. The coaches at Rally have experience with companies making these transitions and can help you with those tough issues but you will have to work through them. “Agile is easy. Implementing Agile is a bit more difficult.”