Outcomes-Focused Agility: Experience Report
Outcomes-Focused Agility: Experience Report
When faced with uncertainty and ambiguity, outcomes-focused agility is proving invaluable in enabling us do things we need to rather than what we may have intended to do.
Join the DZone community and get the full member experience.Join For Free
See why over 50,000 companies trust Jira Software to plan, track, release, and report great software faster than ever before. Try the #1 software development tool used by agile teams.
In my recent post, What? You Don't Know Why You Are Doing Your Project?, I indicated that I would do a follow-up post on examples of where I have used the outcomes approach successfully. As you recall, the post was subtitled "Outcomes Focused Agility- Story Mapping our Strategic Intent".
In this post, I'll provide two examples of where I have applied it successfully as well as provide an example of where I am currently using it with good success so far.
Procure and Implementing a Learning Management System (LMS)
My role: had overall portfolio responsibility for guiding both the technical and business teams.
Several years ago, I was hired by the learning and development group of a local government agency to help them procure and implement an LMS. They used to have all of their employees in one building. The situation was that employees were now in different cities, in different countries, and on different continents.
Most PMs would view this as an IT project and would proceed to begin developing the procurement documents, followed by the procurement, getting it installed and configured for use. If they did that within the expected 18-month timeline and $2.5M budget we had, they would have considered the project a success. However, by the measures of value that really needed to be satisfied, they would have failed.
When you take an outcomes-focused approach, you start by asking why they feel the need to do this particular project. Ask why (along with what and how) enough times and you uncover all manners of actual need, many of which are left hidden using most project approaches. Over a period of the first two to three months of the engagement, I helped them discover and recognize the following:
- They had no experience, tools, or process for developing on-line course content.
- They had no content management system.
- They had not considered what new services as a learning and development group they would need to offer their internal clients once the new way of delivering learning content was in place
- They had not considered the governance of learning within their organization and what that meant to how they approached employee development.
There were many other things we uncovered by asking why, but the above gives you a good idea of the real problems we had to tackle, which far exceeded just procuring and implementing an LMS. Using outcomes-focused agility, we were able to define the real work we had to do to make the implementation of the LMS a success for them:
- We identified four additional value streams that had to be addressed on top of the one to enable learning delivery management (the role of an LMS fits in that value-stream).
- We uncovered that five different software products were needed and not just the LMS.
- We realized we had to design new processes for governance, learning content design and development, learning content management, learning management delivery (where the LMS was actually used), and talent management.
We used a services canvas that I designed based off of the Business Model Canvas to help them figure what services they offered to the rest of the organization and how they would be measured.
Once we had the initial versions of the outcomes map and the Service canvas, we would place the latest iterations of each on our wall and leave stickies and pens on a table beneath them. Most every day stakeholders and team members would walk by and spend a few minutes looking at the canvas and map and use the stickies to leave questions, comments, and ideas. This enabled serendipity across the team and stakeholders. While one person was adding stickies, someone else would invariably walk by and they would then have a conversation about the map and canvas and the content of the stickies.
Every few days, we would collect everything and update the map and canvas and then hold additional brainstorming sessions with everyone. Both the serendipitous and brainstorming events enabled us to create a shared understanding of the why, what, how, who, when, and where of our portfolio and it's various programs and initiatives with all of the required players as all of them contributed at different times and to different degrees to their creation. No one felt left out.
We used Scrum on each of the initiatives including the procurement process, for doing business process design and development, and for systems integration. We also introduced the idea of using an agile approach to learning content development for the new content that would need to be created for the new LMS to deliver. Without suitable content, there was no need for an LMS!
Having taken an outcomes-focused approach, we also created the basis for value-based decisions across the entire portfolio for each of the products that would be created to satisfy each outcome. While Scrum assumes that someone else has already decided which products should be developed, outcomes-focused agility helps us determine which products have to be developed ( in this case learning content, business processes, an RFP, systems integration, etc.). It also helped us to establish the basis for value prioritization within each initiative and product so product owners knew the higher-level strategic goals that were to be satisfied.
Remember products themselves are just outputs. They are not outcomes, nor do they measure the benefits of what you have done, and hence they also do not help you understand why you are creating them. They do contribute to outcomes, but they are not themselves actual outcomes.
Here is a summary of some of the project metrics (sufficient time has passed that I can share these):
- $1M to procure an LMS.
- Projected total 10-year license cost $9.8M.
- 200+ page RFP document was expected based on what a similar agency had done to recently procure an LMS.
- Do this in one project.
- $25K to procure the LMS which was only 2.5% of the actual budget that was to be used for procurement.
- Projected 10-year license costs were $75k.
- An eight-page RFP document that explained the RFP process was used to drive procurement along with other tools we developed for the exercise (no vendor was allowed to submit paper-bound responses); only electronic responses were permitted.
- RFP and vendor evaluations, including boardroom demos, only took five days to select the winner.
- There were seven initiatives that had to be completed as part of a portfolio within a total of five separate value streams
- The portfolio was completed within the 18-month original window and the $2.5M budget.
The Learning and Development group also restructured based on the new services they were now offering and the processes that supported them. The new processes and the restructuring ideas came from the people who were most affected by it. There was no need for organizational change management as it was changed by engagement and with the design being done by the entire team.
We managed to achieve far more real value delivery in 18 months than was expected and for the same money. Hence, we were able to deliver what they actually needed rather than what they had originally intended of simply procuring and implementing an LMS.
Build and Implement a Professional Licensure Management System
My role: had overall portfolio responsibility for guiding both the technical and business teams.
A national professional association wanted to build a professional licensure management system. Again, this sounds like an IT project to most. After all, we would be building a software product but in reality, it was a more complex actual scenario:
- There were 12 regulatory bodies, the national association, and an examining agency all of whom had to be factored into whatever was created.
- The national association only had a few employees up until taking on this initiative.
- They had no real internal infrastructure or hosting capabilities.
Using outcomes-focused agility helped us to identify:
- Ten separate value streams.
- The need to add new physical facilities and procure network infrastructure, new hosting services, etc.
- The need to stand up an entirely new organization to support and operate the eventual systems and infrastructure.
- The need for pathfinder projects to standardize the licensure process across the various licensure bodies, to gain experience with the support model that would be needed, and to investigate required self-assessment capabilities for those seeking licensure.
- Instead of just one software development project, we identified 27 separate initiatives across 10 separate value streams; in essence, a portfolio with 10 separate programs.
This was way more than simply building a software product.
A coordinated delivery was established across multiple years covering facilities, infrastructure, hiring, and product development, as well as an organizational restructuring that would enable them to stand up and support a national professional licensure management system.
Mature People, Process and Technology Capabilities
My role: portfolio leadership and agility mentoring
The last one I'll report on is one that I am currently engaged in with mature people, process, and technology capabilities. The particular team, in this case, is a technical team that connects business line capabilities to one another. They have been in existence for four years and started out as part of a larger project. They split off into a separate team to carry on the operational side for their original development efforts as well as to do similar development work for other business lines.
With the prospect of doing work for many business lines instead of just the original two, we felt that we needed to put more formality into what the team does and how it does it. We have identified four value streams to answer the four main outcomes questions as listed below:
- How do we govern it?
- How do we build it?
- How do we operate it?
- How do we sustain it?
The team sits inside of a very large IT organization inside of a very large government department, so the work they do has a high degree of sophistication as well as being of significant consequence to the business.
The team currently owns the entire development and operational support of what they build including at the platform level so we have to address topics such as:
- Business and technical governance.
- On-boarding of new portfolios.
- All facets of DevOps.
- Systems management.
- Business activity management.
- Migrations of existing products to newer platform technologies.
As there are multiple very sophisticated technologies in play, it is not just enough to know what you must do, but you also need to figure out which technology is the right one to use in each circumstance. As a result, in order to determine what we must do (the initiatives) to satisfy a given outcome, we have had to create and execute initiatives whose goal is to help us sort out our strategy for the actual initiatives to support the identified outcomes.
By asking the four key questions above, we have so far identified 40 initiatives that we need to undertake. The ones that are developing strategies for certain areas will lead to the addition of more initiatives once they are completed.
This is another of the hidden benefits of outcomes-focused agility as noted above. We can use strategy development initiatives to both identify and define the initiatives we need to undertake to achieve a given set of outcomes on the map after we have already started on the portfolio. Now that is the ultimate in outcomes-focused agility! We have also had to tweak some outcomes statements as we have started to deliver on some of the initiatives.
When faced with such a high degree of uncertainty and ambiguity as this one presents for the team, outcomes-focused agility is proving invaluable in enabling us to do the things we need to do rather than what we may have intended to do at the outset across a very complex landscape.
The Results (So Far)
The fact that the goal of our work is to mature people, processes, and technology is not lost on us; maturing our people means constant inspection and adaptation to what we learn along the way. We are also able to adapt to new circumstances as they have emerged as we continue to do other work for the business lines.
We are also advantaged by constantly iterating our overall strategy based both on the strategy initiatives we have identified as well as the ones that are implementing those strategies that in some cases, we have yet to define.
Another aspect of outcomes-focused agility is that it enables the portfolio team to more quickly assess the consequences of delays and changes in organizational priorities. Due to some external factors, for example, we have had to revamp our outcomes delivery timelines within the portfolio.
In one example, we were able to assess the consequences of deferring some initiatives to a later FY on the basis of getting less money this FY. We were able to do this assessment in less than 30 minutes! All we were given was the dollar amount that had to be deferred.
Our map enabled us to make a value-centric decision as we already knew the relationships between initiatives, products, and outcomes (or results) and hence we could quickly determine which initiatives, products, and outcomes could be deferred while having the least detrimental impact on our overall strategic intent.
Without these maps and their details, this would have taken days if not weeks for something this large, and even worse could have led us to defer the wrong things.
I have always ensured wherever possible that each of the initiatives within an outcomes map can be done within three months or less and that we use Scrum throughout. This incremental approach allows us to tackle complex situations in manageable pieces. It also allows us to re-vector our remaining work based on what we learn along the way.
We are very definitely seeing the value of allowing emergence to guide us by tackling things in small enough chunks and even if something turns out to not be what we expected, our investment in each one is not that great, so our risk exposure is significantly reduced.
The Role of Emergence in Outcomes-Focused Agility
Emergence, as I discussed in Chapter 7 of Agile Value Delivery: Beyond the Numbers, is more than just about our architectures and design as described in the principles of The Manifesto for Agile Software Development.
It also applies to our understanding of the holistic messes we are solving that often contain many different problems as the examples above demonstrated. In all of the above examples, it was never a single problem to be solved nor a single project to be executed. I would suggest that this describes 99% of most of what we encounter in the real world versus what is often attempted through single monolithic projects.
Outcomes-focused agility directly supports this form of emergence and provides the context in which to story-map your strategic intent, even when you have yet to fully describe your strategic intent as was demonstrated in the last example.
Understanding emergence helps us be comfortable with uncertainty and ambiguity. Outcomes-focused agility helps us deal with emergence in a rational manner which then allows us to use and adapt multiple frameworks, practices, methods, and techniques to achieve value-delivery. We use what is most appropriate to the context of each single problem we are solving rather than trying a one-size-fits-all approach, or even believing that we are solving a single problem, as we rarely are.
Rather than address benefits realization under each of the above examples, I thought I'd deal with it as a separate topic. For those of us familiar with outcomes-driven approaches, we know that the measure we use to determine the presence of our expected outcomes is to identify the benefits we would need to see in order to determine that the outcome was present. This is as I described it in Chapter 2 of Agile Value Delivery: Beyond the Numbers.
Outcomes cannot be directly observed. They are only observable through measurable benefits. Much has recently been written about benefits realization, which is seeing a resurgence of interest. However, without the context of outcomes-focused agility, we may end up focusing on the wrong things and we still don't have a framework that facilitates our emergent and shared understanding in the face of ever-increasing uncertainty and ambiguity. Benefits realization is itself not enough.
One of the areas of outcomes-focused agility I have not yet attempted is to take the same focus towards the team itself. What outcomes matter to them? I hope to do some experiments with that over the coming months within my current portfolio.
Outcomes-focused agility enables portfolio, program, and project teams to gain insights into both the magnitude and the specifics of what has to be done. It also provides executive levels with a high degree of confidence that we have thought things through enough at the front-end without locking into solutions too soon so that we can more fully create a shared understanding of why we are doing things and use that shared understanding to drive decision-making throughout and at all levels.
An incremental delivery approach through value streams and their associated programs within a portfolio model also significantly reduces financial, schedule, and delivery risks.
So, we really don't have to plan or describe everything upfront. Recognizing this simple reality enables us to help the business and its customers and clients end up where they need to be, which may not be where they originally intended to be. After all, isn't that what we all hope for?
Opinions expressed by DZone contributors are their own.