This post is from the Collabnet VersionOne blog and has not been updated since the original publish date.
Shiny Objects and SAFe
Recently, while I was teaching new teams on how Scrum fits in a larger Scaled Agile Framework® (SAFe®) structure, the question kept coming up from a product owner. "Yes, all this new Scrum stuff is great, BUT how do I juggle multiple requests from multiple stakeholders?" “My customers keep asking for more and more without taking anything off the plate.” I often refer to this as stakeholders chasing “the next shiny object.” Or, I want it all and I want it now. Our business customers often fall into this mode due to the delivery nature of the waterfall projects we have been running for 40 years, where we deliver late, we do not deliver all they want, and it is not the best quality. As a result, I think they ask for everything they think they might need, which results in some of the difficulties of delivering what they REALLY need. So the answer led me to explain how not only the Scrum teams deliver work, but how each of the teams is part of a larger ecosystem of project, program, and portfolio control that helps define work and priorities from original stakeholder requests to the work dispatched to the individual team members. Walking the team through the SAFe Big Picture was exciting, and I'm not sure everyone took it all in a short time, but the questions kept coming: “Where do we fit in?" “What happens if I get buttonholed in the hallway and asked to do something by one of my customers, do I promise to deliver what they want?" and (well, you get the idea), new practices, new ways of acting and reacting to old situations. As team members they were afraid to tell a customer “No, we cannot do that”, or “I don’t know we have the staff to cover that request.” In a recent engagement, the CIO never refused a request. We needed a way to corral her “Can’t say no” responses with SAFe. And we did. I’ll explain further a little later. The end result of these problems is a book of work that continues to expand, priorities that are not met, pet projects that take precedence and generally, queued work that gets out of balance with priority requests. SAFe has some of the answers. We need to look at adding a strong helping of simple discipline and rigor following the SAFe principles and practices. But in my opinion, SAFe adoption alone is not enough – you need the Circle of Life in an IT shop: People, Practices, and Tools. All three combined are a recipe for success. [caption id="attachment_5597" align="aligncenter" width="500"] SAFe 4.0 Big Picture used with permission from © 2011/2016 Scaled Agile, Inc.
All rights reserved. Original Big Picture graphic found at scaledagileframework.com.[/caption] People – SAFe does give us governance structures, roles that staff needs to play, and definitions of how they interact. This is highly valuable as it gives substance to the various roles in SAFe, while being flexible enough to add or revise, as needed. After all, it is a framework. Process / With the introduction of Scrum and Product Owners, all the Inspect and Adapt cycles, potential added capabilities with Portfolio management to direct traffic, the picture looks a lot better from the standpoint of someone driving and managing those priorities. Now we actually have a framework to customize and make “our own” to manage a book of work for a medium to large shop (say 500 – 10,000 staff). New versions of “Essential SAFe” are available for smaller shops as well. Tools – They give us the necessary discipline and rigor to carry through with the often complex dance of delivering systems and features to production. We need a single global collection point as a repository of the work to be delivered, a means of dispatching the work to various teams, a collection of metrics to report our current state, past efforts, future capabilities, compliance with practices, and so on. Tools provide us with the ability to do this. Strengthening the back/end delivery through DevOps is also a great capability to deliver. Still, Stakeholders of Systems Want LOTS of Features So, our business customers are still going to come at us from many different directions with a ton of Features, which can often be identified as "the next shiny object." What work may already be in stream or in construction can get impacted as the “next shiny object” can now be added to the list. Shiny objects occur with amazing regularity as a result of:
- A competitor introduces a new function – keeping up with the Joneses.
- A stakeholder gets impatient for the delivery of a feature and becomes focused on that current shiny object.
- A simple request in an email, which you mistakenly agree to do, goes from being a small paper airplane to a B/2 stealth bomber/sized project or program.
The results of stakeholders repeatedly chasing shiny objects tends to distract teams from delivery. Stakeholders can change their minds about what is important based on what is happening in the business world – which is often disconnected from our IT delivery world. Unless we have a strong commitment to the SAFe processes and practices, we are unlikely to actually combat the shiny object syndrome. SAFe practices corral, organize, prioritize, and deliver whole categories of shiny objects based on the needs and priorities of the stakeholders. At the portfolio level:
- We corral, organize and prioritize (and even set the value of) shiny objects.
- We use Kanban capabilities to organize and prioritize objects.
- We use Value Streams to align work and fund the work (unfunded work like those B/2 stealth projects die at this point).
- We make strategic level decisions for the good of the enterprise.
Remember that errant CIO who promised everyone who asked whatever they asked for? We gave her a sheet that became an input form to the portfolio screening process. So what happens when that commitment starts to backslide or fail? How can we make sure a complex system of systems like this keeps on working? SAFe is based upon a set of key Lean and Agile principles:
Also of critical importance are the core values of SAFe:
For organizations to effectively implement SAFe, we also need a significant amount of individual and team based capabilities of rigor and discipline. In addition, we need some mechanism to keep us on track, and monitor speed, delivery, quality, and compliance, plus deliveries in a priority cadence that is driven by the stakeholders. Rigor and discipline of this type can come in the form of using an enterprise agile lifecycle platform (such as VersionOne) as a key to providing:
- Planning capabilities at various levels for various roles
- Metrics gathering and reporting
- Quick methods of prioritizing
- Globally distributed capabilities of defining and managing work
In my own experience working with large and globally distributed organizations, performing SAFe planning and execution, and utilizing technology with enterprise/wide capabilities of the caliber of VersionOne, provides them with the rigor and discipline to successfully be SAFe. Graphics reproduced with permission from © 2011/2016 Scaled Agile, Inc. All rights reserved. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.