How to Achieve Shared Understanding When Scaling Agile
Last Updated on Wednesday, 12 February 2014 04:43 Written by Dennis Stevens Wednesday, 18 December 2013 07:00
Agile practices as described in the literature are suitable for small co-located teams focused on a single product. These small co-located teams quickly and efficiently establish a shared understanding of a project, the customer and the architecture within which they are working. As organizations scale Agile, teams aren’t working in the same room, they are sometimes working on multiple products, and it becomes very difficult to establish a shared understanding. But you don’t have to sacrifice shared understanding for growth. Leveraging visual specifications will help large, distributed, scaling organizations achieve a shared understanding more quickly and more effectively.
Visual Specification (n): a picture, graphic or display used to illustrate or accompany the description or identification of a requirement.
Agile & Shared Understanding
A small agile team typically has everyone sitting in the same room collaborating together. They end up with a very clear understanding of the product that they’re building and the problem they’re trying to solve. They’re all familiar with the architecture. There is a shared understanding that’s established within that small agile team.
In a larger, more complex organization, teams are supporting multiple products. They are not in the same room. They aren’t familiar with the complex architectures and the needs of the end users. Before Agile we attempted to use formal specifications to build this shared understanding. Many organizations use some form of Software Requirements Specification (SRS) as defined in IEEE 29148:2011. Other organizations attempt to use Unified Modelling Language (UML), a formal set of graphic notation techniques, to create visual models. Both of these approaches support complex multi-faceted views of what the technology looks like, the problem we’re trying to solve, and the underlying structure we need to support.
But in Agile, the specification is thrown out. It’s too much upfront. It’s too much detail and it doesn’t get used. But the teams aren’t small and co-located and they don’t have a systematic way to establish the shared understanding needed on agile teams. This is where it starts breaking down for organizations scaling Agile. They start operating from assumptions and build more than is required. They don’t have a way to coordinate complex features that cross teams. They don’t understand the outcome that is really needed and miss the mark.
But, We Already Have an SRS
We recently worked with a financial services company that had historically used formal specifications. They had started moving to Agile so they took their detailed SRS and started writing a lot of detailed stories. The stories looked a lot like the line items in their old SRS.
It was clear to us that the stories lacked context about why the stories were important and what problems they solved. It was difficult to understand the relationships among the stories. Without that context they were going to struggle to get clarity on what actually needed to be built, with coordination across teams, and to create options and be adaptable as the project progressed. We asked them to develop some visual specifications to create context to support shared understanding on the project.
A visual specification is a picture, graphic or display used to illustrate or accompany the description or identification of a requirement. It should be simple and fit on one page for the most part. It should include words as necessary to accompany the picture. In this case we wanted them to define agile personas for key roles, draw high-level process flows for the significant new features, and draw a simple architecture diagram to show how the various parts of the system fit together. This didn’t need to be formal. They should fit on one page and have sufficient information to tell the story.
They felt the visual specification was a waste of time. They already had the SRS and everything was already very clear to everyone involved. They had the old and architecture documents to fall back on if there were any questions. They were agile now and needed to get into the details as quickly as possible.
We pointed out how a few personas and a few pictures would help them identify and clarify any of the exceptions and edge cases across which they were going to run. They actually felt that an hour was too much since it was so clear to everyone on the project. After some discussion they agreed to spend an hour at the front of a release planning workshop developing some rapid visual specifications.
Four hours into the meeting, they were still arguing about what’s important, how the pieces fit together and where they were going to make changes. In the room, they had technical people, product people and people representing the end users. For the first time it became evident to all that they all had extremely different perspectives on the problem and solution.
Despite having a signed contract, a detailed software requirements specification and architecture documents that had been approved by the architecture group, they couldn’t get 15 minutes into a shared conversation to agree on the visual specification before communication broke down.
Viable, Valuable and Possible
There’s something between conversations in an informal meeting and formal specifications that is needed for scaled agile teams. Visual specifications are an important practice for organizations scaling Agile to incorporate. They provide structure for the team to collaborate around to develop shared understanding around what’s technically viable, what’s valuable to the business, the users and the customer, and what’s possible given the available capacity and capabilities. Visual specifications help close the gap between informal conversations and formal specifications.
We typically advise organizations scaling Agile to create visual specifications at the feature level. They will use these during release planning to write the appropriate stories to support the feature. They will use them identify risks to manage. They will use them to coordinate dependencies and stories across teams. Importantly, they will use them later to communicate and maintain the context of the features for the teams delivering the stories.
Not every feature needs the same amount of visual specification. Some may not need much at all. Often visual specifications can be re-used over time – so you don’t have to create them all the time. For example, personas tend to be used throughout the life of a product. When you’re in a planning meeting and sense there’s a disagreement, or it seems like people are having three different conversations about the same subject, then have someone draw a picture.
There’s a lot of work that’s been done in this space by people like Dan Roam and David Sibbet. They have conducted research around how the IQ in the room goes up by 70% when we use pictures to support our conversations. They also found the ability to remember what was talked about increases four times. We also are much more effective in sharing with others what was discussed when we use pictures.
Visual specifications tend to combine pictures and words so they appeal to the part of our brain that likes visuals as well as the part of our brain that likes language. They can support what’s valuable around the product – personas, product briefs, screenshots or business model canvases. They can support what is viable to build – logical architecture views, interaction diagrams, deployment models, process flows or user journey maps. They can support what’s possible – release road-maps and timelines. In fact, these visual specifications can support conversations that support all three.
Visual specifications don’t need great granular detail, but just enough to facilitate the conversation. These are high-signal and low-effort tools. They can be supported with data-driven examples as well. The data-driven examples can be elaborated in more detail as the project evolves. They may be developed at different times during the project and serve multiple purposes throughout the project.
Visual specifications support release planning. They support product owners and the business as they are slicing work up to create options. They help teams become very clear around the most important things to build and the options available. They help teams budget for how long the features are going to take to build. These visual specifications supported by data-driven examples create the context for sequencing the work and clearly coordinating work between teams to minimize or eliminate the dependencies that exist on complex projects.
Visual Specification in Practice
When teams are preparing for release planning, members can walk in with supporting pictures already prepared. As questions arise, the team may draw some pictures in the room. When drawing pictures in the room, take a snapshot of what’s drawn and store that as part of the specification. Capture the risks, assumptions and some data-driven examples and add some words to the picture.
Visual specification is useful to align QA. Combining a technical picture to describe how things fit together, a process or user experience-type picture and data-driven examples at the feature level communicate clearly to QA how to test at the feature level. Using the visual specifications to support story splitting help provide clarity on how to test stories in a way that complements feature-level testing.
We were recently working with a company that had over one hundred teams supporting a vast e-commerce platform. They were struggling with clarity on what work to do and how to write effective stories, and were being hindered by cross-team dependencies. They weren’t going to get one thousand people in the room for release planning. It wasn’t possible to put an Inventory Service developer on one hundred teams. They weren’t going to self-organize their way through the dependencies that would arise within the release. The release was broken into a set of Epics or business goals. Small groups that incorporated product managers, architecture and technical leads, QA and project managers used visual specifications and data-driven examples to gain clarity around the features needed to deliver those Epics. They also identified the cross-delivery team dependencies. They used this to coordinate the complex release across the delivery organization – dramatically reducing the number of features that got blocked. They used the visual specification to communicate to the individual teams just what was needed to deliver in the next release – quickly and efficiently getting shared understanding across the teams, including QA.
We recently worked with a small agile team that had been growing rapidly and had been bringing in new teams, including some offshore teams. They had been working very effectively as a small group. As they started to scale and add more teams, they reached the point where they simply could not scale the conversations. They weren’t able to have all the right people in the room. They were really struggling with this and we introduced the concept of visual specifications. We told them that if someone has to start waving their hands to describe a feature or draw on the white board to describe it, they needed to produce a visual specification. Drawing the picture would create shared understanding in the room and capture the part of the conversation that wasn’t clear to the people not in the room. This simple practice dramatically increased the productivity of new teams. It led to a lot of mixed conversations and shared understanding of the context of the problems they were addressing with their project. They also found that the personas that they drew as they were talking were long-lived. They used them again and again and actually started referring to them as they discussed their product.
Leveraging Visual Specification to Support Agile at Scale
As you’re incorporating visual specifications, make sure not to over think them. It’s not as formal and detailed as UML. It doesn’t have to follow any precise guidelines, as long as it captures the context of the conversation. Use them to communicate about the product and features across teams, to somebody who’s not in the room during the initial conversation or who joins the team later, or to go back re-establish shared understanding. Try to find the point where you produce sufficient specifications to support planning, shared understanding, sequencing of work and effective testing. But don’t produce reams of unused documents.
Stop Writing Code You Can’t Yet Test
Last Updated on Monday, 24 March 2014 02:38 Written by Dennis Stevens Wednesday, 4 September 2013 06:10
Most of the organizations we engage with have more work to do than they can possibly get done. So, developers are writing code as fast as they can to get done trying to maximize their capacity. Typically, we see developers running way ahead of testing. Often, testing is still working on the prior release while development is running off on the next release – and testing just can’t ever catch up. This inventory of untested code shows up as long lists of defects, lots of code branches, untestable features, and products that can’t be integrated or regression tested until just before the next release. This vicious cycle of long bug lists, painful regression testing, and production defects colliding with the next release continues to grow.
The goal is not to write code faster. The goal is to produce valuable, working, testing, remediated code faster. The most expensive thing developers can do is write code that doesn’t produce something needed by anyone (product, learning, etc). The second most expensive thing developers can do is write code that can’t be tested right away. Recently, LeadingAgile’s Derek Huether wrote about Getting Teams to Deliver Predictably (http://www.leadingagile.com/2013/05/getting-teams-to-deliver-predictably/). He shows how having more work in the queue than can be performed slows down throughput. Pretty quickly, everything gets congested and things back up, building up latency and uncertainty in flow.
So, we understand that it is not a good economic investment for developers to write code that can’t be tested. It isn’t getting done faster – and it’s increasing the cost of all the work in process. Even people that understand this push back, however. We hear developers have to be busy – that not writing code is not a good economic option.
There are at least six things that developers can work on that are better economic investments than writing untested code.
- Get ready for upcoming work – In complex products, not being able to make and keep commitments creates delays that are very costly. Rather, than writing code that can’t be tested in the sprint developers should be figuring what they need to understand for the next (or future) sprint(s). They are going to have to figure it out at some point, anyway. Figuring it out ahead of the sprint improves the ability to make commitments, so it is a better choice than figuring it out in the sprint.
- Help finish work in progress – Developers can (and should) pair with testers to find and fix bugs, or pair with developers to finish other work that the team committed in the sprint.
- Expand capability and future capacity – There are often scarce skills or knowledge sets that only a few people on a team can do. Rather than writing code that can’t be tested, developers can pair with someone to develop team capability and capacity. Even if the new person isn’t as productive as the old person at this scarce skill or knowledge set it is still, a better economic investment than writing code that can’t be tested.
- Increase testing capacity – Leveraging their unique skills, developers can dramatically increase testing capacity by improving test automation, establishing test data management tools, working on build automation or cleaning up environments. When testing is the constraint – this is a great investment for the team. It can create permanent capacity increases by raising throughput at the constraint.
- Refactoring difficult code – If there are sections of code that are tricky to work on or are frequently the source of unintended errors, developers can work to refactor this untested code. It might make sense to combine this effort with increasing the ability to test the code being refactored. Refactoring is particularly compelling when focused on a section of code related to work the team is getting ready to do.
- Practice - Increase the capacity and capability of the team by practicing new skills using code katas. There is a craft to being a productive developer. The body of knowledge is large, including patterns, new features of programming languages, new testing and development techniques, and the API’s or interfaces that developers work with. Finding the time to practice new skills on code that will never go into production is valuable when it results in improved capability of the developers.
We need to focus on improving the economic return of developers. Writing code that isn’t needed is not a good economic investment. Writing code that can’t be tested is not a good economic investment. Not writing any code is actually a better economic investment than writing unneeded code or code that can’t be tested. Remember, the goal is not for developers to write code faster. The goal is for the organization to produce valuable, working, tested, remediated product faster. These two items often collide. Make the best economic decisions – and writing code that can’t be tested is typically not the best economic decision.Learn More
Agile vs. Waterfall
Last Updated on Wednesday, 16 April 2014 04:09 Written by Dennis Stevens Tuesday, 27 August 2013 04:35
Agile versus Waterfall
These words have become completely overloaded when discussing product development. Lots of conversations about helping organizations improve their product development processes go sideways based on individual perspectives about the meaning of Waterfall and Agile. At this point these words don’t provide a distinction that is helpful when we are trying to figure out how to build products in organizations. It’s a red-herring contradiction. When I hear someone say “we need to do that Waterfall” or “that wouldn’t work in Agile” or “we can use Agile for that project” then I want to stop and ask “what does Agile mean to you?” or “what do you mean by Waterfall?”
I want to break down this debate into a clearer discussion around specific characteristics; Type of Effort, Upfront Planning, Sequencing and Feedback, and Composition of Teams. Then talk about how understanding these characteristics helps us improve the ability to be predictable and achieve the fastest time to ROI.
Type of Effort
Product Development encompasses different types of efforts. Agile is frequently viewed as the model for doing exploratory product development. In exploratory projects, teams are exploring new ways of solving a problem or trying to discover a new customer or market segment. Mike Cottmeyer has been calling these divergent projects. Fast time to value involves rapidly performing lots of experiments, getting feedback on your hypothesis, and adapting your approach.
At the other end of the spectrum are convergent projects. In a convergent project – there is a scope, a due date, and a budget. Agile is a very strong approach for delivering convergent projects. Organizations doing convergent projects need teams to have a pretty strong ability to make and meet commitments and they have a significant need to manage risks and coordinate dependencies. These organizations can make the trade-off decisions necessary to maximize the chances they will converge on the best outcome.
Most of the organizations we deal with need to have a pretty clear idea about what they are going to get — and when they will get it — before they decide to do a project. They are primarily performing convergent projects. You manage convergent and divergent projects differently. A frequent challenge we see is when organizations move to Agile, they treat all projects like divergent projects but they are actually in convergent projects.
Not planning isn’t an option. The question is how much planning do you need to do to be successful? It isn’t possible to be predictable if you don’t do a sufficient amount of planning. The red-herring in Agile is that you don’t do any planning. The Red-herring in Waterfall is that you get all planning done up front. Regardless of your approach to the project the amount of upfront planning you do should be based on how much you need to do to answer the questions of, “What will I get?” and “When will it be done?”.
Sequencing and Feedback
As I stated above, most organizations need a pretty clear understanding of what they are going to get and when they will get it. We see different modes of sequencing and feedback. Many organizations accomplish predictability by sequencing the work in phases. For example, Analyze, Architect, Design, Construct, Integrate, and Test/Remediate. The intention is to make good decisions upstream that protect downstream efforts.
The problem that we see in these projects is that testing and integration feedback is deferred until late in the project. Challenges identified late put the project under duress at a point when it is difficult to respond effectively. This is the project that takes as long to complete the last 20% as it took to deliver the first 80%. In phase based projects it is very difficult to be predictable because risks tend to manifest late in a project – and time to ROI is negatively impacted when project durations run past the planned delivery.
The other form of phasing and sequencing leverages frequent delivery of working tested product. When we have done sufficient planning, frequent deliveries can be sequenced to maximize the potential for success on the project. Risks and dependencies are resolved early – while there is time to respond to them. More valuable work is delivered earlier in the project – providing the opportunity to explore options and stop when the problem is sufficiently solved. We gain insight from frequent deliveries and this insight is used to make trade-off decisions to maximize return on the project. Projects using value based sequencing can be more predictable than phase based projects. Time to ROI can also be maximized in value based sequencing in those cases where a smaller subset of the potential set of features can be deployed to deliver value.
Composition of teams
In most organizations, we see people belong to functional groups and are matrixed into various project teams. It makes sense when the sequencing is in sequential phases. Individuals are often spread across multiple projects simultaneously. Using this method, we can maximize the utilization of everyone in the organization.
In another model, people belong to collaborative teams that work together to deliver working, tested product frequently. In this approach, team members have almost instant availability to each other and everything needed to deliver its next increment. People are generally dedicated to a single team so they can work collaboratively and with near immediate availability on each frequent delivery. Co-located teams help with this immediate availability.
Team composition plays a crucial role in the ability to leverage value-based sequencing. The collaborative team composition approach may have a negative impact on utilization (I disagree with that assumption, and I’ll tell you why in a follow up blog post next week). The value gained from increased predictability and faster time to ROI often outweighs the impact of lower utilization.
Arbitrary references to Waterfall and Agile don’t provide much useful information. To be as predictable as possible and to maximize time to ROI, we need to have clear conversations around the characteristics of the teams that are best suited to the problems we are trying to solve. Understand if your project is convergent or divergent, determine the appropriate amount of planning, assess if your project would benefit from phase based or value based sequencing, and whether functional separate or collaborative teams are the best way to build software.
In my experience, Agile is about collaborative teams and value based delivery. I prefer this approach on divergent projects that require little governance and upfront planning, and on convergent projects that require significant governance and upfront planning. So I am very comfortable with Agile – whether the project is a divergent or a convergent type of effort and regardless of the appropriate amount of upfront planning. Not everyone sees these the same way because not everyone has the same perspective of Agile. Let’s move away from red-herring conversations of Agile versus Waterfall and focus on meaningful characteristics.Learn More
Making Work Ready
Last Updated on Thursday, 2 August 2012 09:53 Written by Dennis Stevens Thursday, 2 August 2012 08:35
Teams moving to Agile often abandon planning and documentation. Some coaches claim that any planning or estimating is waste. Some teams hear that we don’t do any planning or documentation in Agile. The concept of not developing “The Plan” upfront comes to mean we don’t plan in Agile and we don’t document in Agile.
Planning and documentation become waste in product development when we delay the start of a project by months so we can develop detailed requirements and task level estimates to come up with “The Plan”. At some point, we have developed “The Plan” as much as we responsibly can and the delay in getting stared is more expensive than improving the upfront precision of “The Plan”.
“The Plan” becomes wasteful when we then use it as the one right precise answer and we create overhead in managing detailed changes that don’t impact the promise to the customer. When we don’t realize “The Plan” wasn’t precisely accurate to start with, we pull people that could be doing work into long meetings to defend where they are and to figure out how to get the project to green (to match “The Plan”). We also end up with starved and overloaded capacity all over the place when we make very precise “resource loading” decisions across multiple simultaneous projects based on “The Plan”.
So we have done a good job convincing people too much planning and documentation is bad. I frequently see this aversion to planning and documentation go too far – trading off the waste from delaying the project too long and putting too much detail too early on into The Plan for the waste of just winging it. What we want to do is progressively elaborate The Plan – making work ready for the teams to optimize product flow while minimizing the waste of over-planning. From Vision and Road-map, through Release Planning, Feature Planning and Story Writing, Sprint Planning, to the Daily Stand-up we have to do enough planning and documentation to make work ready before Planning.
There is work to do around the Vision and Road-map and understanding our customers and stakeholders before we get into Release Planning. Getting the team together to plan a release when you don’t understand the business problem, don’t have insight into the needs of your targeted stakeholders, haven’t come up with even a proposed architecture, and don’t have any strategy for how you will test what is being developed as it is produced seriously hampers Release Planning. There is planning and documentation for the Product Owner or Product Manager to do to get ready for Release Planning.
If you have a large project, you may be doing Story Writing Workshops to prepare the backlog ahead of the Delivery Teams. Before we get the whole team together to slice features and stories in a Story Writing workshop, we need to have thought through the feature a little. We probably need to draw a few pictures and have some data driven examples of business rules prepared before the Workshop. There is work to do to make sure the Story Writing Workshop doesn’t become drawn out and inefficient.
There is work to do to get ready for Sprint Planning. In some of our large projects that means writing acceptance tests for the stories ahead the Sprint. It probably means answering any lingering questions from Release Planning or the Story Writing Workshop. It might mean sorting out some technical risk or documenting some precise validation rule to make work ready for the Sprint. When we don’t get ready for Sprint Planning, it is very difficult to become predictable in the Sprint.
So, we avoid the waste of documentation that is never consumed or that is stale when it is consumed. We avoid the costs associated with pushing a project back for weeks or months while we produce a falsely precise plan with too much detail. We minimize the cost associated with managing inevitable and foreseeable change. This waste comes from planning and documentation for its own sake.
But, we don’t abandon planning and documentation. We still produce “The Plan”. But we don’t do it for the sake of planning and documentation. We do it progressively – elaborating just what is needed at the time. We do enough planning and documentation to make work ready to an appropriate level of detail as our work unfolds. We do enough to help us make and keep promises to our customers. We do enough planning and documenting at the right time to ensure entire product team (product management, development, testers, and analysts) shares an understanding of what we are about to build, what we are building and what we just built. Effective planning and documentation are part of making work ready to help improve our team’s potential for success.Learn More
Getting Testing Involved
Last Updated on Thursday, 2 August 2012 10:24 Written by Dennis Stevens Monday, 2 July 2012 07:23
There is a common anti-pattern I consistently run into involving testing. In this anti-pattern testing is about finding technical defects near the end of a project. Testers view their job as preventing a buggy product from being shipped to the customer. To accomplish this, testers define test cases from the requirements documents. Since requirements are going to change during the project, the testers need to wait until near the end of the project to produce their tests.
What’s wrong with this?
This model doesn’t work. The requirements documents don’t tell a perfect story in the first place. And the documents never stay in perfect alignment. Sometimes the tester interprets the requirement differently than the developer. Inevitably, development delivers something that doesn’t match what testers expect and they file a defect. To avoid defects, the developers have to anticipate everything that might be meant by the requirements. A result is that developers significantly overbuild or over-engineer the product. The bigger and more “dynamic” the product is, the bigger the testing effort.
A result of the anti-pattern is that the cost of producing working, tested software is significantly increased. We are less predictable and we don’t really know where we are until very late in the project. Because we test late we find out late in projects that we aren’t meeting the schedule, or scope or cost. We end up in the blame game trying to decide if defects are a requirements problem versus a development problem versus a test problem. There is vicious cycle that produces a culture of low trust and a lack of collaboration and coordination. This is very common – I see this low collaboration environment every day.
Define the acceptance criteria before you build
Test (n): A procedure for critical evaluation; a means of determining the presence, quality, or truth of something.
Testing isn’t about finding bugs. And it isn’t just about evaluating. A critical activity in testing is defining the criteria for the evaluation – we will call these the acceptance criteria. As we pointed out above it isn’t effective when someone in a silo sets the criteria for evaluation after the product has been built. We want to define the acceptance criteria before we build the thing. This doesn’t incur more cost to the testers. It is no more initial work writing the test cases whether you do them before or after.
Define acceptance criteria as a whole team
Defining them before isn’t enough. Everyone needs to have a shared understanding of the outcomes. There is a lot of benefit in the discussion around defining acceptance criteria. When we agree on the tests upfront developers can build the smallest and simplest thing that will solve the problem – not overbuild trying to anticipate everything that requirements could possibly mean. When we agree on how we will evaluate the product before we build it we will have fewer defects so there is less rework.
Progressively elaborate acceptance criteria
Defining the acceptance criteria before you build something isn’t big up front design. We want to do whole-team just-in-time detailed design. In Scrum, this happens while grooming the backlog and in Sprint Planning. In our Enterprise Agile approach, we break the product into a series of releases in product road-mapping. We break releases into features during release planning. We break features into stories and we elaborate the stories further before Sprint Planning.
As we progressively elaborate the requirements – we progressively elaborate acceptance criteria. In fact, acceptance criteria are an effective way to express business rules at the story level. We also find that non-functional requirements, compliance requirements, and operational requirements can be expressed as acceptance criteria at the feature level so we can ensure we are finishing all aspects of the product as the project progresses.
A better testing strategy
We’re on the way to solving the testing problem. When the acceptance tests are elaborated jointly the testers, analysts and developers don’t have different understandings. When we elaborate them before we build developers can build the smallest and simplest thing that will solve the problem. When we elaborate acceptance criteria at the same time we elaborate requirements we don’t have as much change control required and we actually get better requirements to communicate. This strategy can have a significant impact on reducing the cost of testing – and the time to release of the product.Learn More