Most organizations use annual funding cycles and large projects to undertake work. These create planning cycles that are too long to adequately react to market changes.
Agile businesses budget at a higher level of abstraction. They budget around a desired business outcome instead of requirements or a highly detailed scope of work.
Agile businesses also use stable teams that stay together for extended periods of time. These teams become well-oiled machines that learn how to leverage each other’s strengths, how to communicate with each other, how to work together, and how to get things done.
Project vs Product Lifecycles
Historically organizations used projects to fund and build products which they then handed over to sustainment groups for support. These days software is becoming more critical to the business operation of every organization. Banks are becoming IT companies with financial products, cable providers are IT companies who also offer infrastructure services along with their digital offerings. These software projects should never “finish” since they are core for customer engagement and revenue production. This is the new era of ongoing products instead of temporary projects.
The Old Way: Projects
Projects are typically estimated and funded upfront or based on a calendar year. For example, Project A may receive funding for $3M to cover its estimated 2-year development cycle, or $1.6M for this year and $1.4 for next year based on its project spend.
Traditional project teams complete development and handover to a sustainment team. This team needs to complete knowledge transfer before they can successful sustain the application through minor upgrades for the remainder of its lifespan. If major changes are required a new team is spun up, they learn about the product, make the changes and then hand it back to sustainment. Each handover and knowledge transfer takes time, loses valuable information, and reduces accountability for success.
The New Way: Products
Adopting a longer persisting product view of applications and services better matches the reality of today’s digital business. By creating a single, multidisciplinary product team for its development and sustainment we avoid the knowledge transfer and accountability losses of handovers. We also create stable, high performing teams who are accountable for a products success.
Switching from projects to products involves several core changes.
By creating stable Value Stream teams we can achieve much higher levels of efficiency and productivity. This far outweighs the supposed flexibility coming from pulling people from work and moving them around to different projects. The ‘fungible resource’ model of moving people causes teams to be in a constant state of storming/forming/norming and makes it almost impossible for them to achieve the ‘high performing’ state.
In addition, fixed Value Stream teams are much easier to manage financially. A fixed Value Stream team has a fixed burn rate. This makes estimation and budgeting much simpler.
- Business Agility Institute & LitheSpeed: Funding Flow – The Middle Ground of Agile Budgeting
- Blog Article: Martin Fowler, Products Over Projects
- Business Agility Institute, Finance Insights Playlist
- White paper: Emergn, Moving From Projects to Products
- Book: Allan Kelly, Continuous Digital: An Agile Alternative to Projects for Digital Business
- Book: Shane Hastie, Evan Leybourn, #NoProjects: A Culture of Continuous Value
- Scaled Agile Framework Lean Budgets
Visual Management Systems (VMS) or “Kanban Boards” are Lean artifacts. Typically, they are large display boards that show all the work being done. They allow anyone to quickly see work in progress, understand its status, and assess what is under control and what is not.
These Kanban boards are designed to help visualize and optimize flow. Applied at the portfolio level, they help drive a continuous flow of ideas, prototypes, deliveries, revenues, and customer feedback.
- Change the “unit of work” from projects to product features
Align feature delivery to near-term / quarterly business goals
- Do dependency planning at the feature level and find those features that can start flow through towards “done” right now
- Use visual management systems to see the flow of work and uncover bottlenecks
- Address organizational bottlenecks
- Projects are decomposed into features and/or MMPs
- Batching is minimized so that features and MMPs are flowing independently of each other
- Business outcomes that support the strategy are being incrementally achieved on at least a quarterly basis
- The entire portfolio pipeline of work is visible from “concept to cash”
- Business value achieved by quarter
- Feature /MMP throughput
- Feature/MMP cycle-time
Most organizations are not accustomed to managing for flow. Instead they tend to manage for local efficiency, people utilization, or around traditional processes. None of these techniques enhance organizational level flow or throughput.
In addition, most organizations view the “project” as the primary unit of work or unit of delivery. By batching many features and fixes into a single project and then delivering the project, the organization looses the ability to quickly deploy value to the business and to customers. Simple changes that could provide value today are delayed and eventually deployed when the whole project is completed. Customers do not care about your internal projects … they care about features and fixes. Lean is all about deploying value “as defined by customers”! The key to achieving portfolio flow is to find features and fixes that start to flow immediately towards production delivery.
Working in this manner, we can start to achieve a continuous flow of value.
An end-to-end Visual Management System is a tool to help leaders see and manage flow in the portfolio. It helps to identify bottlenecks and optimize the speed of delivery.
A simple Portfolio Kanban, as shown, can help leaders prioritize general demand, shortlist and prioritize demand, and feed a program backlog with prioritized work ready for implementation by multiple teams.
Using a Portfolio Kanban is a strategy for global rather than local optimization. Not only must teams work efficiently as they develop products, projects and programs, but portfolio managers and executives must manage work streams for the most value also. This involves prioritizing initiatives based on ROI and the cost of delay while remaining cognizant of constraints and dependencies.
Portfolio Kanban brings additional visibility to the initiatives in development (work in progress or WIP in Lean terminology) and organizational constraints. Many businesses attempt too many cross-cutting initiatives unaware of the collisions and contentions this causes. They see a business opportunity so spin up a project for it without data about it’s impact on current in-flight work. Often dependencies and constraints associated with supporting groups, poor environment provisioning, or legacy system integration limit throughput.
The result of too much work in progress and poor visibility into constraints is twofold. First everything slows down as teams engage in a complicated coordination dance of both technology-compatibility and people engagement. People try time slicing to determine what is fair and try to please or at least serve everyone. The second issue is things inevitably break. When using new, emerging technology, no one can foresee all the impacts or incompatibilities. As issues occur people on two or three projects have to stop, determine what happened, fix it and then pick up from where they were and continue.
With high levels of work in progress, determining the source of conflicts is hard and the frequency of issues is high. Momentum is difficult to build and maintain. In a culture where issues and delays are the norm it is tough to establish a mindset of accountability and reliable delivery. As a coping mechanism people establish a do-the-best-I-can mentality and do not step up to own and fix problems as frequently as we would hope for. Why would they? The next change may make it impossible, better to just do what is being asked for today.
The solution is to use Portfolio Kanban to show how the current network of initiatives creates additional work and risk. It is not a case of learning to say “No” to business requests, it is a case of using stricter sequencing based on known dependencies. Actually far more work can be delivered in a given period if the work was sequenced rather too much work attempted concurrently.
- Interview: Karl Scotland on Visual Management with Kanban
- Book: David Anderson, Kanban: Successful Evolutionary Change for Your Technology Business
- Article: Leankit, Why We Need WIP Limits
Agile HR & People Ops
Human resources has been undergoing a shift to support the dynamic expectations of workers and customers today through a more interactive, iterative and inclusive approach to functions such hiring, talent development, performance management and corporate communications. “Talent management,” “experience management” and “people operations” are just a few terms entering vogue to describe an evolution of the function classically known as HR.
- Adopt an iterative, incremental and adaptive approach to rolling out and testing new HR initiatives
- Focus on attracting and keeping the best talent through engaging hiring, onboarding and working experiences, rather than controlling bad actors with bureaucratic policies
- Make career paths flexible to drive a growth mindset and support crossfunctional behavior
- Create flexible working environments that support both local and remote collaboration
- Use local knowledge of specific teams and people to drive targeted support solutions, rather than deploying inflexible centralized plans
- Make performance management feedback loops frequent, proactive and developmental rather than occasional, counteractive and punitive
- Favor transparent communication strategies over opaque internal planning
- Improved engagement and happiness among employees
- More flexible career paths that support cross-functional teams and a growth mindset
- Ability to attract and retain highly engaged top talent
- Transparent communication policies with clear feedback loops
- Happiness/Engagement among employees
- Ratings on learning & development programs
- Hiring speed and efficacy
- Train your HR group in agile methods
- Assess where HR could advance agility
- Update HR vision and values as appropriate
- Story map some tangible goals and releases
- Create a Kanban board to track HR work
- Build hiring and onboarding games
- Design new compensation schemes
- Design a flexible career progression system
- Decentralize HR and “go to the gemba”
- Highlight and eliminate process waste through value stream mapping
- Adjust resource management and allocation policies
- Run a skills marketplace
- Experiment with flexible schedules
- Craft an advice process to enable self-management
- Design a compelling employee handbook
- Implement a micro recognition system
- Take regular pulses of your teams
Many traditional PMOs are optimized around Project Initiation and Governance, both of which need to change if they are to adequately support business agility. Often, the PMO helps start projects. Organizations can enable Business Agility setting up an Agile Value Management Office, which focuses instead on completion of projects and flow.
Governance in many organizations is built around the idea of large, infrequent changes. The expectation is that product deliveries, project releases, and business process changes will all happen infrequently and when they do, the changes will all be done at once.
For example, in most organizations, changing a production IT system involves a series of approvals and sign-offs that can take weeks or even months to accomplish.
Once again, these processes are not designed around the concept of “flow”. They are not designed to handle small, frequent changes.
To enable business agility, the governance model will need to change. It needs to encourage small and frequent changes, since those are less risky. It also needs to design smaller, lighter-weight controls that can be executed quickly and efficiently.
Dynamic STrategy & Decision Making
Many organizations are organized by an annual planning and budgeting cycle. They set financial targets for the year, set strategy for the year, and launch projects for the year. This assumes that, through detailed upfront analyses, we can predict the future accurately enough to choose a clear strategic direction a year or more in advance. Unsurprisingly, in many of these organizations, delivery also happens yearly. It is common to see large organizations with 200+ day cycle-times for the delivery of larger programs and strategic initiatives.
As organizations move toward Agile, many accompany a new way of working with modern and trendy management structures, such as the adoption of Holacracy or enterprise-wide self-management. Just because organizations need to be adaptable does not mean they cannot have a long term strategy or business plan.
In fact, the most Agile enterprises are grounded in a shared purpose, driven by a leader with a razor-sharp vision and an unwavering set of principles. Rather than just go with the flow, Agile organizations make decisions based on data, and build dynamic strategy through continuous measurement, learning and responding.
Moving to shorter strategic cycles is one of the most powerful things that leaders can do to make their organizations become more Agile. Agile businesses might set quarterly goals, and have small quarterly strategies that make incremental progress towards those annual goals. Delivery groups then create smaller, shorter efforts that show measurable progress towards the strategy.
Each quarter, the leadership team assesses which targets are being met and which ones are not. By this time, competitors may launch new capabilities, customers may demand new services, our own financial position may have shifted, and we can adjust the next quarter’s strategy based upon the new information. No longer are we locked into year-long gambles, year-long spending, and a year-long wait for results.
Decision Making Velocity
Agile businesses require a more dynamic, and decentralized decision making process. One that works fast and efficiently, and can create good and credible decisions sometimes based upon incomplete data. Additionally, leaders need to build their team members’ capability to make decisions on their own, without the leader herself being a bottleneck.
In Principles: Work and Life, founder of the mammoth hedge fund Bridgewater Associates Ray Dalio shares guiding principles that have been the cornerstone of the growth of himself and his company. In his straightforward list of rules, readers find a rock-solid path to rapid, decentralized decision making.
According to Dalio, to make decisions effectively one must learn, simplify and decide well. A “radically open-minded” leader weighs choices based on advice from people with “believability,” and decision making becomes a process guided by principles. To Dalio, believable people have repeatedly and successfully accomplished the thing in question — who have a strong track record with at least three successes — and have great explanations of their approach when probed.
The leader’s job then is to develop decision making capability, ensure that decisions are made through open and transparent critical thinking and discussion. Also that the decisions made by people with proven decision making capabilities are weighted more than decisions made by people without experience of a track record or believable opinions.
Recently, Lean Startup® Techniques have been integrated with Agile approaches. An example is Dual Track Scrum that overlays a discovery component onto standard Scrum Delivery. This allows for Lean Startup style validation of business ideas in parallel with product delivery.
Often the business and product side of organizations still operate with traditional waterfall approaches that are largely driven by a projectized funding model. As a result there is pressure to lock in scope, schedule and budget upfront. However, locking in scope increases waste, stifles innovation, and delivers useless features to customers.
LitheSpeed favors an integrated model that combines Lean Startup®, Design Thinking and Agile Delivery. While high level scope is defined and agreed upon up-front, detailed scope is deliberately deferred to the last responsible moment, and driven by a continuous, lean discovery. Business ideas are tested via Lean Startup style experimentation while Design Thinking helps us refine exactly the solution that end users need, discarding unnecessary features.
End-to-End Value Stream Teams
Agile businesses use networks of End-to-End Value Stream Teams to deliver improved customer experiences. They operate as full-lifecycle, entrepreneurial groups that rapidly adapt to changing needs.
These Value Stream Teams extend the notion of ‘stable agile teams’ across the full range of activities that it takes to define, build, and deploy a solution. In a sense, they are a company within a company that takes full ownership and accountability for its product.
These entrepreneurial units are able to move with speed and effectiveness because they do not need to navigate ten different silos and functions. They have all the skills and resources needed to deliver, right now.
Value Stream Teams operate using minimal, sufficient-to-purpose Digital and Portfolio Management and governance. This includes long-term considerations like strategy and road-maps and short term considerations like metrics, investment, measurement and reporting.
Implementing Value Stream Teams
Establish Cross-Functional Agile Teams if they do not already exist
Establish Leadership Representation from Business Groups comprised of people from each silo within the value streams.
Map Value Streams to identify opportunities for improvement, customer
experiences, and the business units needed to deliver core business products and services.
Define End-to-End Team(s) within pilot journeys with small, cross-functional agile teams
“Shift-Left” to business including units such as business planning, marketing and legal
“Shift-Right” to include operational and sustainment units
Pilot End-to-End Delivery Pipeline with executive support and active coaching assistance
Long term success combines technical delivery excellence with customer service and responsiveness. Development cannot be successful independent from customer experience. Nor can operations be a success without seamless integration with development releases and customer feedback/requests. Today Agile businesses link the three domains of Development Success, Operational Success, and Customer Experience success through Outcome-Based Measurement.
DevOps automation techniques link the development, release, and customer feedback disciplines that enable outcome-based measurement. This includes business success deploying products and services through all the intermediate operational stages to customer success and feedback.
Focusing on outcomes (goals) rather than outputs (traditional metrics) allows us to achieve the true benefits of an integrated lifecycle without being distracted by local optimizations or unintentional gaming of the metrics. By optimizing the whole we can achieve greater customer satisfaction and loyalty and higher levels of feature throughput and efficiencies.
We start by learning the outcomes each segment desires. The image below shows common outcome based measures for each stage of the development and operational life-cycle.
Viewing the components integral pieces in an unbroken chain of services allows Agile businesses to optimize for throughput, quality and service.
DevOps principles and practices encompass the entire technology value stream. They enable IT groups to develop and deliver value quickly, reliably and securely to its customers. Improving the flow of value through the technology value stream is foundational to achieving business agility. Further, we need to identify and radiate the feedback at every step back to the team and business stakeholders to see how customers are interacting with our products and services.
DevOps drives business success by automating communication, collaboration and integration across traditionally separate organizational silos. Features are delivered faster, safely and reliably by using technical practices such as version control, continuous integration, continuous delivery, automated testing, loosely-coupled, cohesive architectures, low-risk release patterns, and telemetry.
Besides the business benefits, DevOps adoption has shown to foster higher employee engagement, morale, and retention. Put simply, organizations that embrace DevOps practices get more done, with higher quality, improved operational efficiency and higher satisfaction levels.
Furthermore, DevOps techniques enable outcome-based measurement. From customer success to business success and through intermediate stages, we can measure the delivery of value and outcomes at each and every step.