Don’t Sell me Agile, Solve my Problem
Last Updated on Tuesday, 25 February 2014 02:04 Written by Tim Wise Tuesday, 25 February 2014 08:08
A while back I was invited to the AITP Atlanta Chapter for a CIO roundtable discussion that involved questions on agile. The event was a great success and I came away with a bunch of great insights into what topics are on the minds of today’s CIO. One statement that night has really stuck with me. A wise, retired CIO told me, “Don’t sell me your solution, solve my problem.”
That statement further solidified my belief that I am not “implementing agile” (hang with me), but rather I am solving a problem or a set of problems that commonly occur in enterprise environments.
We don’t sell vials of snake oil. Here’s why that may be the perception.
Let’s consider the state of affairs for a moment. When I get the opportunity to have a discussion with a new organization, the person I am talking to needs me to solve a problem. They might not know anything about agile, scrum, kanban, or any other process. Alternatively, they may have experienced a poor implementation and have an immediate bias to any of the “agile” words (i.e. sprints, daily scrums).
If I am selling them something, I genuinely want to solve the problem, not implement agile. That allows me to be a pragmatic partner with knowledge of agile systems that can benefit my customer. It breaks down zealotry and keeps me honest.
In the end, I am directly and intentionally not talking about agile, scrum, kanban, or lean or anything else that is under the agile umbrella. I simply want to know, what is the most impactful issue that their enterprise is facing right now in their unique context. Can I solve it? No, but we (myself and the enterprise) can. It must to be a partnership though to be an effective sustained transformation.
Here’s the catch. Most, but not all, issues will fall into one of several categories.
- Time To ROI
Though categorically these problems are recurring across many business enterprises, the underlying causes can be a complex, interwoven gobbledygook of methods, procedures, and people.
That’s why it’s important to listen and offer up expertise when you understand the problems. It’s an engaged dialog that I am targeting to create a shared understanding of their problem so we can work to create a vision of our solution. I’m not there just to lend an ear. That’s why I need all this experience stuff.
Speaking of experience, I have found commonality among the solutions for each of the categories listed above.
Let’s take Predictability. In order to become predictable, most organizations will need to learn how to systematically decrease batch size, reduce WIP at the enterprise and team levels, and stabilize teams. Inherently, this will increase quality and decrease Time To ROI. To further improve those, I will need to run experiments on their unique context.
How do they begin to get predictable? That’s what they need help doing. It’s what scaling agility is really all about. Getting more value out of the system to decrease time to ROI and predictably make and meet corporate goals. Informed, predictable returns on investment.
At my core, I believe a predictable system is one that we can run experiments on and get most other problems solved. That’s my key to unlocking the shared potential of both parties.Learn More
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.
Bottom-Up Implementation & Top-Down Intent
Last Updated on Monday, 22 July 2013 10:02 Written by Andrew Fuqua Tuesday, 23 July 2013 07:15
A good strategy that I have used for dealing with complex agile transformations in large enterprises has two parts: bottom-up implementation and top-down intent. As Mike puts it, this is “where leadership sets the direction and establishes constraints, but with teams that are empowered to operate within those constraints.”
Bottom up implementation means helping teams be as successful as they can within their constraints. It means getting them mature enough to report out significant performance information like velocity, story ratios, resource shortages, quality and blocking issues on a reliable cadence. It means gaining transparency about the challenges in an actionable way. Due to extreme constraints in many organizations, this isn’t easy. What’s constraining agile in your organization?
Bottom up means helping the teams factually communicate the impact of obstacles on team performance. I use assessments to identify and communicate the “non-agile” behaviors and practices that are reducing the potential performance of the teams. Because we know that Agile/Lean practices work, we know that the teams that assess higher will perform better against their business drivers and performance metrics. Have you identified the obstacles in your company?
This approach of team and organizational assessments and improvement road-mapping tied to team metrics is a very mature way to help sustain the changes and to highlight where my clients aren’t getting the success they want. All this information from the ground credibly expresses the impacts of the organizational and management obstacles that arise from management decisions. In many organizations, you can’t simply create change in the larger environment to make the team stuff easy without first producing the information needed to justify change to management. This brings us to…
Top down intent requires helping management understand how they can be successful with Agile teams. They often are not in a good position to be successful with agile, they are under tremendous duress, and they need to work through a ton of challenges. Sound familiar? But we can still make progress. This requires explaining at the upper management levels and in other parts of the organization why they need stable teams. It requires data to demonstrate the impact of the organizational design in order to support moving toward the recommended org design. Understand the system, how it creates value, and its constraints. Build Scrum teams around the constraints.
As part of top down intent, it’s important to build awareness of the capabilities required in the program office that will be necessary in order to maintain the changes after the external agile coaches leave. They need to hire people to sustain momentum with internal training and coaching. And they should do this early on so these new people can get up to speed, spending time with the external coaches.
So there you have it: one way of approaching complex agile transformations in the enterprise. There is more, so stay tuned.Learn More
Structure 1st: Why You Should Not Start With Practices
Last Updated on Monday, 24 June 2013 11:06 Written by Andrew Fuqua Tuesday, 25 June 2013 08:10
Starting your agile transformation with a focus on practices is not an entirely bad idea, but with the wrong culture and structure, agile practices will be superficial. People will go through the motions. People will do agile things like have standups, demos, and planning meetings. You’ll have stories. It will look agile on the surface. But that’s all it will be — looks. There will be no substantive change, no stable teams, no control over Work-In-Process, no empowerment, and no predictability. You’ll have shallow collaboration, fault-finding and blame, and an unstable velocity. You’ll have no real support for agile or for improvement. You’ll get limited value out of your agile adoption efforts.
This isn’t the 1st time I’ve written negatively about mechanical agile and about how the agile values and culture are more important than the practices. While that is what I know to be true, there is more to the story.
So if starting with practices isn’t the best, where should we start? It’s not wise to start with culture either. Why not? CSM courses talk about practices and agile culture but when people go back to work they hit a structure that doesn’t support it, or they hit a command and control environment that doesn’t allow it. Attempts to change their culture are met with the realities of their organizational structure. Their structure is built around a different set of cultural expectations. The existing structure reinforces the old culture. Changing culture is hard, which is why many organizations start an agile transformation with practices.
Fortunately, deciding between culture and practices as the starting point is a false dichotomy. The place to start is with the structure.
Starting change with structure creates space and safety for practices to be put in place. At this point, we still can’t tackle culture head-on, and the practices will still be superficial at the start, but now there is support for the practices. You’ll have a shot at stable teams, at self-organization within the team, and enough empowerment for making reasonable commitments, leading to predictability. In this way, you can act your way into a new culture. Yes, I’m saying a new culture will emerge, but at this point, some intentional attention to shaping the culture is wise.
When I say structure, I have a few ideas in mind. The first is choosing between feature teams, component teams, services teams, or a mix. There is a great discussion on this topic on the LeadingAgile blog. Feature teams are great when you can have them, but an organization of size and complexity at some scale needs services or component teams added to the mix. Often, large organizations are already structured around component teams. We have to consider whether that is the best structure for their agile implementation.
Another idea I have in mind is just the stability of the team and whether it’s really a team, as opposed to a workgroup or project-group. For agile to work, we must have stable teams. Teams don’t work if management is often moving people around or if people are on multiple “teams”. Teams need to bond, to learn how to work together. Colocation is a huge help. Cross-functional is assumed.
Structure is among the most important concepts to nail for anyone scaling agile. At LeadingAgile we’ve been developing shared understanding on our approach. During this time, I’ve come to appreciate how much you can achieve with structure, along with practices, to create a team-based iterative and incremental delivery setup that is a precursor to agile. Once that is in place and we have some personal safety and delivery capability, some of the other things can begin to emerge, toward an agile culture. At a high level, that is our strategy for how to walk through the structure–practices–culture loop.Learn More
In Organizational Agile Change Management , Culture Comes Last
Last Updated on Wednesday, 12 February 2014 05:06 Written by Jesse Fewell Friday, 22 February 2013 12:00
Here at LeadingAgile, we have a specific cycle for achieving organizational Agile change management. In short, to make real substantive organizational change, you need to attack the following dimensions
- Organizational Structure:
- Processes, Practices, Policies
- Cultural Beliefs
…in exactly that order. That’s right, when you strive for organizational Agile change management, you need to do the culture part last.
“But wait, Jesse. Isn’t culture the most important ingredient of an organization? What about the phrase ‘Culture eats strategy for breafast’? Why not do the most important thing first?”
Agile Change Management : Culture Last
I’ve been coaching this to my clients for a while, but in the past few months it has become painfully evident to me that Rule Number Zero for “going agile” is to have stable team rosters. One of my clients has the habit of shuffling people from one project to another, with no notice. When I started talking to them about the mechanics of user stories or other such details, they simply couldn’t care less; they were overwhelmed and tired from getting yanked around. A different client actually KNEW they had to re-organize their teams to be more focused. But while senior management was busy socializing the new org chart for 4 months, the teams were thrashing, fully convinced that management didn’t have the fortitude to effectively pull off any real Agile Change Management.
Some of my colleagues think that if you go straight to modifying the cultural mindset of the leadership team, you will get the momentum you need for lasting results. But the problem is you can’t get there from here. There is a known, methodlical process for changing people’s mental models. Specifically, consider that the same process applies for people struggling with personal dysfunction. Think about it. To achieve behavior modification,
- First, get out of the environment that enables the dysfunction, and get into a support structure
- Then, leverage that support structure to work through a 12-step program
- ONLY THEN, can you introspect and self-actualize yourself as the new person
Granted, it is an iterative cycle:
- Change one small environmental thing =>
- to create the space to change one small process =>
- which slightly shifts my confidence based on a known track record =>
- which motivates me to make another environmental tweak…
But the point here, is that the iterative cycle of behavior modification is that you can NOT change a belief system, until you first have some positive behavioral evidence, which only happens after you create a safe and stable operational environment.
What about you? Have you seen the latest mission statement, management fad, or feel good effort yield zero results in your day to day work?