7 Culture Hacks for Enterprise Agility: Being “Agile” with Agile Transformations

Image for post
Image for post
Source

Let’s briefly examine this interesting quote about human behavior by John Locke. I believe he meant that we humans, more often than not, are victims of the herd mentality. This can be extrapolated to organizational behavior, given that organizations are made up of people and their thinking and decision making shapes the course of organizations after all. What’s noteworthy from his work is that, he thought when faced with competition there is a subconscious urge to adopt merely the behavioral properties [while ignoring understanding of the essence or losing sight of it] and expecting a change in status quo.

In this article, I am going to talk a little bit about how this behavior can be seen in enterprise digital and agile transformations today. While Lean and Agile thinking have been around for a few decades, at least since Toyota pioneered lean management philosophy for waste minimization and improving consumer value, why has this become increasingly popular in the last decade? What is the biggest value proposition of agile and lean thinking that is making everyone adopt it? Most agile experts would unequivocally respond to these questions with the same answer — “speed to market”. That’s the essence! But why so much focus on speed to market now more than ever? I would say the high speed at which consumerization and commercialization of value propositions is possible today with advanced mobile technology has made the threat posed by unconventional, digitally advanced market entrants more real now than ever!

It’s no news that, lately, almost every organization has either already embarked upon or is thinking to start their “agile journey”. However one of the foremost things that most organizations adopt in their agile journey is the “structural design” of a typical agile organization, or in a worst case of this attempt they end up with agile branding for existing organizational design, i.e., identify delivery teams as scrum teams, setup daily scrums and scrum of scrums, re-term business and technical requirements as user and system stories, features and epics, size them using story points, measure progress in terms of velocity and the whole inventory of terms that most popular agile frameworks suggest. Great! But, what about the essence? Do these changes by themselves improve speed to market?

Image for post
Image for post

In the context of software delivery, becoming “agile” is not just about adopting team meetings and documentation standards. First, it is about thinking of value as outcomes of a value chain and not as scope within constituent software platforms that deliver only those platforms’ outputs. Second, identifying and prioritizing scope across the constituent platforms of the value chain along with meaningful integration points with operational processes and/or existing legacy capabilities. Third, decomposing the scope across platforms into independent, negotiable, valuable, estimable, small and testable stories. Fourth, delivering the most value (end user outcomes, not platform specific outputs) in the least cycle time possible. In the sections to follow, I am going to present seven hacks to improve speed to market focusing on the aforesaid four aspects.

1. Paint and see the big picture:

Not all of our enterprise software platforms produce customer value. In large enterprises, more often than not, software platforms produce outputs to help handle certain functions of the value chain and don’t contain the entire value chain in them. In essence, they only help achieve a function that contributes to the end outcome. One more key thing to note here is that customer value is not always associated with the go-to-market products of the organization. It could be anything that the customer receives as a service from the enterprise and forms a perception and a reaction — like a phone call with customer service, a bill of service explaining the services delivered with the costs incurred, a purchase order, a sales order etc. If customer value is produced by a bunch of software platforms talking to each other, utilizing the outputs of each other, features cannot be defined within the platform silos. They should be written to be focused on the actual outcomes in a way that allows producing of the said outcomes minimally first and incrementally following. I have talked about this in detail in my previous article on outcome focused feature definition. Additionally, this approach provides visibility of the larger purpose to the end customers and generates feedback loops that will prove to be invaluable to the organization.I say, put a picture that provides this context up where everyone in your team can see everyday!

2. Don’t lose sight of the big picture:

It’s one thing to think through and write features to be outcome focused and increments leading up to the end product or experience. It is a whole another thing to do the work within silos in a coordinated fashion such that the said outcomes are produced minimally first and incrementally following. More often than not, platform teams that are part of a value chain lose sight of the end outcomes that would make up the end product and end up focusing on outputs of their own silos, that do not produce end outcomes. This causes more work to produced in silos than understanding what’s truly “integratable” to produce end user outcomes, prioritizing and producing relevant work across the software platforms. See the following figure in which I have tried to illustrate this problem:

Image for post
Image for post
Silos Problem: More work is produced in silos than is integrated across the value chain to ship customer outcomes minimally first and then incrementally. This causes a ton of rework for all teams.

It’s wise for software platform teams to prioritize work that can be integrated with work from other platforms to produce outcomes, instead of building integration “tech debt”. Tech debt, in general, is risky. It’s even more risky to pile up your integration tech debt, assuming one day all work in silos will magically come together. It’s easy to lose sight of this and keep building work that cannot be integrated as rapidly as it is supposed to be. Keep reminding your teams that features must produce end user value or outcomes, not just platform specific outputs… and remember, Scrum of Scrums and forums for cross platform teams are not about coming together, discussing status of the silos and going back into silos. It is more about looking at how the scrum teams together can deliver or are delivering end user outcomes!

3. Decompose to build:

One of the important principles of Lean is Just-In-Time (JIT). This has become more relevant in software engineering today, more than ever. It is common to see software platform owners getting busy with building their own backlogs with user stories once features are identified in the product vision or roadmap in line with enterprise value delivery (discussed in previous sections). But the key thing to keep in mind for them is whether the user stories are translating into value at [close to] the same pace at which they are identified and put into the backlogs. Otherwise, the backlogs will keep piling up leading to obsolete stories due to lack of reaction to feedback loop, overloading of teams, multi-tasking, de-motivation and other morale issues due to not being able to delivery either expected quantity because the quantity is unreasonable, or quality of work because the team is suffering with morale issues at this point.

4. Attack the queues:

More often than not, Scrum teams get narrowly focused on work completed by individuals within the team the previous day, work aimed for completion by each of the individuals for the current day and impediments to complete that work during stand up meetings. They see developers as developers, testers as testers and see their functions as mutually exclusive and linear. To put it in context, for any given day, if there is not enough work for testers to complete because development tasks are held up, they can’t move forward with this line of thinking! Scrum teams must aim to be cross functional with “T-shaped skills”. Instead of asking each individual in the team what they worked on the previous day, what they intend to work on next and what their impediments are to finish their individual tasks, they need to shift focus to looking at the Kanban board, see how the work is flowing and where the work is clogged up. The queue that’s troublesome should become the focus, so work starts moving forward from that queue as opposed to piling up. Remember teams succeed or fail together if value is not delivered. It’s actually sub-optimal if all the team members deliver what they need to individually, but the work of the team as a whole is not moving forward.So put global optimization over individual or local optimization!

5. Automate Everything:

JIRA workflow between backlogs to test execution and deployment pipeline, almost everything can be automated. It’s important that there is as much automation as possible. A lot of times the tools enable automation to the extent that the teams are willing to use them; as in teams need to opt into them. For instance, there is no point in having a person accountable and monitoring whether features are moving along the program level Kanban board as the user stories are moving along the team level Kanban board. This can be done by JIRA. There is no point in having state-of-the-art tooling and not effectively using them. Similar to business and software workflows, the technical workflow needs to be automated as well. To be globally effective, the tools managing these workflows need to be appropriately integrated. More often than not teams, instead of investing the required effort into automating workflows, manage backlogs as they would in spreadsheets and manually align work across the value stream. At this point, we are better off managing them in spreadsheets because the advanced tooling actually works counter to this manual process! From a technical standpoint, Test Driven Development (TDD), Acceptance Test Driven Development (ATDD) and deployment of each user story when developed and tested, are all advanced practices requiring thorough automation around test case execution and release management. There’s no point blaming the tools to be ineffective if the thinking and management of work are traditional.

6. Continuously integrate, deliver and deploy value:

If you are building a new product, build your MVP as quickly as possible first. Remember MVP is “viable product. It does not need to have everything. If you have not already heard of the Zappos story yet, they just had a way to take orders for cool shoes before they built out a robust way to deliver them to customers and manage the processes behind the scenes. It is also said that they were so focused on customer centricity that on a few orders where they did not have the shoes to fulfill, their associates ran to the stores to get them and then fulfill them. The moral of their story is that minimum viable product is something that lets you take your value to the customers with minimal resources. In their case the value was “shoes”. Zappos probably thought about what they needed at the minimum to sell shoes online — a website to showcase shoes and take orders on them. Similarly, in your case it may be to provide a great customer experience through an accurate adjudication of a claim submitted at point of sale for a covered service in an insurance plan. Think about what you need at a minimum to achieve the customer journey of in-taking a claim being submitted at the point of sale, validating it against the covered benefits, looking at the utilized benefits and sending a response on what is allowed and what is not. You most likely don’t need everything under the sky to make this journey happen “minimally” and need only select functionality across internal functions. If you are building on existing platforms or modernizing them, do not do it in isolation of your go-to-market products and operational experiences. The reason being that, you will never be able to transform everything under your portfolio and keep the software platforms relevant to your future business context. The better way to go about it is to chew off capabilities from your legacy context and launch them incrementally into the modernized context while continuously integrating with your legacy platforms until they are fully modernized. From a technical standpoint, to make the aforesaid happen, development, testing and deployment practices along with respective tools to support CI/CD (Continuous Integration and Continuous Delivery/Deployment) need to be adopted.

7. Reward and celebrate experimentation and innovation:

I heard this on a podcast called “What’s Next!” recently and found it to be catchy, and above all, making a ton of sense! There is a very common misconception that innovation is always something ground breaking. It doesn’t have to be. It maybe just looking at the status quo and questioning if it makes sense or something else in its place would make more sense. It may be as simple and small as an operational or technical process change. For this, it is important that your team members feel empowered to challenge the status quo. It is important that they will rewarded to come up with alternate ways to be effective, but not punished or shamed if the alternates don’t work. Willingness to try and fail is something that teams and organizations need to embrace to succeed in the competition for relevance in the very demanding marketplace focused on customer centricity. Teams also must adopt methods and techniques to experiment on ideas with quick prototypes and narrow down to viable solutions that matter to their context. Design sprints are a great way to quickly run experiments on ideas and learn without having to actually build and launch them to realize feedback. However, most organizations that have started running design sprints do so in isolation from software platform management, as part of a separate “innovation” unit perhaps. They try to feed viable insights to their IT management to incorporate. It is nobody’s priority to incorporate insights that are not prioritized projects…and yet again we blame the tool. Design Sprints provide a great way to experiment on ideas, so why not use them as part of software platform management and develop features that are truly value providing?

Takeaway:

Enterprise Agility and Product Management require a mindset shift from managing the activities that lead to outcomes in a linear and tunnel visioned manner to managing the outcomes themselves: getting them out of the door quickly and iterating on them frequently. The idea is to not only enjoy fast feedback loops, good will and revenue streams, but also be competitive and relevant in the marketplace. If you are taking months and years to build your business value, remember, there may be competitors out there who are adept at doing it way faster. Remember, technology is not only enabling your traditional competitors but also new and unconventional market entrants who have mastered the art of designing customer focused value propositions and software platform management. This is not possible through mere adoption. We can’t be adept at doing this just by saying: “Starting tomorrow, we will be agile…and while we are at that, let’s also scale agile”. It requires deliberate shift of what we incentivize, reward and celebrate: Is it quantity of work in silos and complacency or smart cross functional work focused on consumerization of outcomes? Is it hours of labor or creative thinking, problem solving and innovation? Is it individual deadlines being met or value being delivered by the team(s)? Is it our people being awesome or just hard working?

Disclaimer: Thoughts expressed here are my own and do not represent the interests of any organizations to which I am or have been associated.

Originally published at https://www.linkedin.com.

agile, digital transformer. product, service designer. ai aficionado. foodie, traveler, reader, complexity thinker, philosopher, photographer. views are my own!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store