Business Agility in 4 Easy-to-Understand (but not so easy) Steps
In order to gain comprehensive and lasting business agility, an organization must work hard to integrate and align all of its divisions and departments with the company vision, mission and goals. But today, our business silos can feel like continents, separated by vast oceans. An agile or digital transformation can help bring these continents together, but some are easier to make progress on than others.
In this post, I’ll try to articulate a few ideas I’ve been working on lately to help break down the complexity that often comes with transformations. My theory is that while the work may be immense and take years to perfect, the strategies are not that hard to comprehend. And they definitely don’t require an overwrought framework or complicated organizational redesign to make tremendous progress.
1: Foundation of Why Agile and Product Teams
Most transformations work first on building out the DeliveryStates continent, bringing together Software Engineering (IT and Technology), Product Management, Architecture and Operations. This is the foundation. It may often be first because it’s easier for an organization to work on the agile mindset, behavior and principles with their product technology teams. But it’s also where most customer value is created and delivered, so it makes sense for an organization to focus here first. Clearly Product Management and technology must learn not just how to work together but how to work alongside each other on the same team. This is obvious to those that understand the named roles on an agile team. Many transformations, however, neglect to focus on building emergent architecture practices and fully integrated operations and technical support services. These can all be tackled within the confines of Technology and Product Management.
One criticism of technology-only focused transformations that can be easily remedied is creating better awareness of why agile makes a difference both inside and outside of IT. The key, however, is to not use agile jargon while doing this. Some non-tech areas like Finance and most executives will understand Lean, Risk Management and even the startup hypothesis-driven mindset required to establish product/market fit. Even existing Technology teams can be jaded by agile misconceptions (see related book), prior bad experiences or feel they know the Agile Manifesto and Scrum so they are good. Build the appropriate awareness, education and training using a language that can be universally understood in business terms.
2: Portfolio, Finance and Servant Leadership
In terms of departments in the organization, the PMO is perhaps the next closest continent to where the product’s value is created. Programs and strategic initiatives managed by the PMO at a higher level often do not have daily interactions with the agile teams and their direct managers, except perhaps at checkpoints, milestones and times of financial impact. This separation can create political strife, along with the fact that many PMOs are fiercely tied to their waterfall pasts and have yet to embrace an agile mindset and learn to properly mix the two as needed. However, great Delivery Managers and Product Managers responsible for the success of the teams can and should work closer with the PMO to create greater alignment. Perfect places for this collaboration to collide include the communication of product roadmaps and proactively setting funding expectations for products and teams.
On the same continent with the PMO is middle management. There is a lot to say about the transformation challenges with middle management, enough to focus a series of blog posts on servant leadership and changing the roles and responsibilities within the middle layers of management. But suffice to say, the old ways of doing things in a hierarchical, command-and-control way will not work as the organization evolves closer to Business Agility. Team members will still need HR managers so that role remains intact, but other traditional functions of middle management will need to evolve to a more supportive, servant leadership mindset, providing increasing amounts of accountability and responsibility to the maturing, self-managing product teams. Managers do, however, need to continue to keep longterm ownership of the solutions built by teams as a failsafe for the fact that teams may come and go over time.
As Portfolio Management and iterative funding processes are built, the PMO, middle management, Delivery Managers and Product Managers will find new ways to work together with technology leadership and finance to make decisions and establish priorities where the most customer value can be created.
3: Customer Centricity and Vision Alignment
Meanwhile the continent of CustomerPromiseLand, including Marketing, Sales, and Customer Support, is often even more disconnected from the product tech delivery teams, reporting to different executives and not in synch with the product creation, feature-level impacts or team-related details. They are often surprised by new products and capabilities because we forget to keep them plugged in, not planning in advance of ship dates or products launches. This is also solved by great Delivery Management and Product Management, by the way. Sales, Marketing, and Customer Support are stakeholders that should be invited to sprint demos, especially big ones that unveil upcoming new features and products. When they are present, be sure to spend some time refreshing them on any changes to the related product roadmaps. Even better, schedule specific times to synch up their activities and timelines with the product team’s delivery schedule. The easiest way to break down silo walls in an organization is to simply reach out and talk to people.
Customers, themselves, are also on this same continent, and sadly the most removed from anything the organization is up to. There are many points of interaction to consider with customers. Consider the fact that Sales, Marketing and Customer Support likely have the strongest relationships and deepest understanding of what your customers like and don’t like about your products and services. The organization should work hard to make sure that knowledge makes it back to the Product Management and Technology organization in ways that can impact those perceptions, perhaps by prioritizing the bugs that are impacting your biggest customers or prioritizing the features or services that will win over the biggest targets. Internally, we often don’t have these relationships across silos, so it will take someone passionate enough about solving these problems to create these new regular paths of communication.
Other points of interaction with customers should reside within Product Management and Technology itself. There should be enough knowledge of your customers to create a short list of trusted and representative customers with whom you could schedule regular conversations to discuss product development plans, show early working prototypes, and ask hypothetical questions to guide software development. Consider establishing both a formal customer design review process, following traditional UX and research oriented questioning patterns as well as an informal feedback loop for products mid-development. A Customer Co-development Program can be a bridge-builder for existing customers that helps build even deeper relationships as well as creating the opportunity to build even better products that you know customers will love.
ExecutivePole, as the name implies, might actually be the furthest continent from the others. The larger the organization, the more layers of management and less detail there may be about the specifics of the value being created for customers. And while there are easy ways to include executives and senior leaders in milestone product reviews or through encouraging gemba walks to know better what the teams are doing, this level of information sharing is perhaps not as critical as the flow of information in the opposite direction.
The most senior leadership of the organization are responsible for setting the vision, mission, goals and objectives. These messages must be crystal clear, frequently repeated, and shared in a multitude of ways so that everyone through each layer of management and every person on every team understands them. One of the most important ways to ensure the organization is focused on the right things is to take the time to explain why the organization is doing what they are doing. This type of alignment is probably rare, because there are many ways to fail in communicating and ensuring the messages are received. But with Organization Change Management and a Change Agent Network to help repeat and explain these messages, organizations of any size should be able to broadcast the same message to every employee, creating better alignment and understanding about how and why they delight customers.
4: People Operations and Happiness
Finance and HR are perhaps the furthest removed from where product creation happens because teams can do all of the above using existing, annual finance and HR processes. Both departments have traditionally stuck with annual renewal cycles, which is a hard rut to get out of. It is possible to build an agile organization that creates products incrementally under the guise of existing project-based funding models using the older annual budgeting and longterm project funding targets. It’s awkward, but ask anyone in technology and they will share their stories about how they get around annual budgets to get their work done in a more iterative fashion. Discussing these pain points with trusted finance representatives may be a great first step to building new processes together. Finance budgets and targets are almost aways sheer guesswork and they know it. Finding a finance champion to help explore concepts like Beyond Budgeting and #NoProjects will have an even greater impact.
HR has a similar disconnected mindset with annual targets, standard percent increases and performance management strategies built during the industrial revolution. These two departments often cause the large majority of cultural pains and happiness challenges to the evolution of culture during a transformation. All the more reason to tackle them as soon as you are able. Don’t expect big changes quickly. But your transformation team should spend some time educating, training, and introducing concepts to your rule-making friends in finance and HR. They can be turned into enablers of happiness if you try hard enough. Start with some internally focused design thinking and express the challenges in terms they can understand. Responding to change quickly enough with financial and hiring concerns are problems they can relate to and ones they should be motivated to help improve.
HR rewards individual performers based on job title expectations and ignores the value of the team, the customer value produced and the psychological safety factors between managers and team members that make the team as a whole productive. Should HR be convinced to consider team-based motivations, team-based hiring needs, and outcome-oriented incentives, the shift to an Agile HR can begin and ignite lots of other changes. There are radical organization structure changes some companies are considering with pods and tribes and layers of teams, all of which can be made to work, but an organization should start work on the prior three steps before they decide on disruptive HR changes that affect the whole company. People Operations is a new class of HR principles that can help get HR more intimately involved in day-to-day challenges and help drive greater business agility.
Conclusion
As promised, this is an over-simplification of how you might accomplish an enterprise-wide agile transformation to achieve greater Business Agility. Please let me know what you think, how you’d improve any of the ideas above and anything that doesn’t make sense. I’ll keep working on these ideas and will share more detail inside each of these four steps in future posts.
About the Author: Brian Link is the owner of Practical Agilist, LLC. Brian provides leadership as an Agile Delivery Consultant and Business Agility Coach. Follow Brian on Twitter @blinkdaddy or LinkedIn.
