This blog post is focused on what steps senior leadership can take for their agility journey and where to begin. As one of the most popular idioms refer
The first step is the most difficult part the journey
I would say
The realization that you need to take the journey is the most difficult
By addressing the following six aspects, you can launch your Agility initiative with great confidence of achieving your goals and sustaining an Agility culture in your teams. Let’s start from the beginning
It is a way of being aware of changing the environment and responding quickly, in line with the team or organization goals. As a by-product, it is also a way to getting things done in the shortest of time, creating superlative quality and maximise the benefits for the users. An Agile approach also encourages incremental development and value delivery. This enables that customer to be continuously engaged in the development. Closing the feedback cycle continues to enrich the features, while getting something usable progressively.
I have seen many organizations calling themselves agile by following a few show only steps. Such as getting certification, create a product backlog and start conducting ceremonies. The there is a plethora of tools to manage multiple metrics in the hope to continue to “manage” the agile teams while expecting them to be self-organized.
That doesn’t really bring in a change. What’s required is a higher level of collaboration, technology excellence or just enough hierarchy.
Before you start the journey, the first thing that you would have to answer is what are your organization/business unit goals under these three dimensions?
- Increase Revenue by increasing customer segments or customer wallet
- Reduce the cost of technology or overall service
- Disrupt the existing revenue generator or new geographies
Ability to succinctly convey your goals in an elevator is considered as a key leadership trait. While the first response could be all of them are goals, great leaders need to resist that temptation. It would make it practical and realistic when you prioritise the goals and then look at different possible next steps. Think of this as a set of tools. Not every problem needs a hammer. One should explore possible models in mind before you try going in one path.
Think Lean Management
Six Sigma and ITIL were toolkits for understanding whether there is consistency in what is being delivered.
Those models are changing towards creating a holistic answer to the question ‘Are you doing the right thing?’ and then looking at how do we do it right. For example, instead of considering metrics as something to be measured to ensure that SLAs are met, pondered and looked at, find ways to move towards the speed in which a problem is getting resolved. Using DevOps and Value stream realization is a way to find the waste generated in the whole lifecycle and using DevOps approaches to automate it.
Continuous improvement cycles (a.k.a retrospective) are at the heart of agility. And taking this simple model from the customer point of view and drawing out areas that need trimming has yielded the highest benefit at a lower cost. This has worked for an organization that I was consulting earlier.
Agile Product Model
Looking at the services you offer in a holistic way, would lead to identifying different teams. Some of the usual suspects are testing, development, production support, L3 support, Operations, Business Development. When you look at the value added to the customer, there is value added in every stage. However, by looking at the number of handovers from one team to the other, there is waste added inadvertently.
Local optimization leading to global sub-optimal performance
For instance, one of the organizations I had coached, created self-contained teams based on the user journeys – customer acquisition, market research, loyalty /retention, market operations. Each of the teams included cross-functional team members having the technology, analytics, product vision all in the same unit.
This kind of product driven agility avoids the long tail syndrome, silo-ed organizations and waste reduction.
Empowerment of agile teams doesn’t stop at creating the goals and letting them complete it. While the easiest way is to imagine an enterprise of scrum teams as teams working together, an empowering organization is one that has a strong leadership to help create multiple empowered organizations.
Self-organized teams while looks very cool on paper, it’s hard to implement when our jobs are at stake. You can almost imagine the leaders’ hands holding everyone together to act as a safety net.
Empowerment, at times, is confused with the abdication of responsibility by the leaders. When that happens, teams take decisions not necessarily aligned to the leaders’ vision. This leads to the assumption that the teams are not necessarily making the most of the empowerment they have been given. Hence as a leader, while enabling empowered teams, the working agreement should be very clearly laid out by the leader on the goals for the team.
This not only keeps the teams focused, but also motivates them in making decisions that matter.
While there are multiple scaling agile practices present, this is one area that is not given enough impetus.
Empathy Driven Tools
There is a disruption in user behaviour and how and when they use certain services. For example, in Chennai, academic-oriented kids always used to go to tuition starting from 8th grade to improve their competitiveness in acing the exams. This was a given for the previous generation. Now there are two shifts happening. More kids want to explore non-sciences background such as art direction, macroeconomics and the others that continue their journey towards an engineering or technical line are moving away from the only classroom driven training towards Baijus.com, ahaguru.com, Khan Academy, drama schools. These are clear disruptions and only when you understand the roles and goals of the personas, would you as a leader be able to understand what type of solutions that you should invest in.
Agile Product Budgeting
Empowered teams need to be followed by a change in the way finances are governed. When we look at Scaled Agile Framework (SAFe) it advocates a full-blown Train based budgeting. While that’s definitely one way to go, another way to look at budgeting is to create a budget for a product to see the level of investments required in the 1-3 year horizon and budget for the entire business unit (or in Spotify terminology – Tribe).
While the traditional model was to keep the budgets directed to specific projects to avoid overrun, this defeats the purpose of fully agile teams. When we expect architecture to be emerging, the same should be expected in the budgets. Are PMO functions adept at letting control to the teams and only enabling them with the required capabilities?
An organization that I am consulting has truly started their digital transformation with the creation of empowered teams, agile product model and agile product budgeting with leadership providing a vision of where they want to go.
While it’s great to think that when I have agile teams, my problems should be resolved magically, it is similar to the thought that once I have laid out the foundation, my house is done! Your work has just started to take the next steps towards agility.