Patterns for Agile Change: Blog 5: Transformation Backlog

-
Opening Story:

Employees are invited to an Executive briefing about the future of the company. The CEO and other board members present the strategy for the next few years that could mean significant change for a lot of employees within the company.
At the Q&A session as people ask questions about what it means for them, answers seem vague and ambiguous, and executives refer to a plan that the Operational Director is creating and will be available in a few weeks.
Employees leave the meeting unsure of what this means for them. When the Operational Director's plan is made available, the leadership makes efforts to 'convince' or 'win-over' the employee-base, so that everyone is bought into the plan and executes it.

 Summary:
Rather than spending time communicating the plan to everyone, spend time communicating the problem and context, and involve people in working out the solution inclusively.

 Context:
You're a member of the board and believe that the CEO's vision is the best approach for the company to be successful over the longer-term. However, you're unsure of the detail of how to get there and whether everyone is going to buy into the strategy.

 Problem:
There is a clear 'Dot on the Wall' that both the Shareholders and Executive team are aligned on and need to get started rapidly. However, there's no clear plan to get there, the devil is in the detail and they need help from the people involved in the delivery of products and services to shape what needs to happen and how to get it done. They also need the entire workforce to be bought into the approach in order to execute it.

 Forces:
Operational priorities mean that balancing long-term change and short-term deliverables causes tension.
The successful implementation of the plan is dependent on the engagement of the employees, as it is their passion and energy that can deliver the change
Competitors and market dynamics mean that timelines are short.

 Essence of the Solution:
Inclusively describe the 'Dot on the Wall' as the board/leadership team and facilitate workshops to identify what needs to be done.

 More about the Solution:
Involve everyone! Fully brief everyone on the context, strategic analysis, market drivers, and overall strategy and intent. Then, openly ask everyone for their help in achieving that Dot on the Wall. Think about the different perspectives: Product, Processes, Technology, Tools, Facilities, Training, etc that help realise the vision.
Work through prioritisation & ownership in smaller workshops to create a transformation backlog. Items that require changes to products move off the Transformation backlog and into the Product Backlog. This enables non-product change items to remain on the Transformation backlog with clear focus and transparency.
Review, Iterate & Communicate the backlog as you progress through the change activities fully utilising the pattern 'Murmuration'. It is important for everyone to see the Transformation backlog as a 'living' activity and feedback on progress regularly.
The Transformation backlog provides content and direction for 'Call a CoP', and uses the 'Pathfinder' pattern for large or risky change activities. [these patterns will follow in future blogs]. 

 Resulting Context:
A prioritised list of deliverables required to achieve the 'Dot on the Wall', that has been fully communicated to everyone, and collectively created. Done correctly, this energises people, helps people understand the drivers for the change even if they don't necessarily want or like the change.
The transformation backlog also becomes a means of measuring/seeing the change over the longer period. This level of change takes many months and it helps to be able to articulate and communicate progress.
Negative impacts: If the Transformation Backlog is created collectively, but then change activities are delayed or pushed back due to operational reasons or lack of funding then the stall/delay in the change is visible to everyone. There is no hiding place for the executive, if having engaged the workforce in a change activity, they are not able to execute upon it due to funding or operational constraints, everyone will lose faith in the change programme and the transformation backlog becomes a damning list of everything that needs changing in the business.

Known Uses:
SME Software Department c30 FTE
Financial Services Software Company c220 FTE
Online Digital Company c200 FTE
Financial Services Corporate Unit c400 FTE

Comments

Post a Comment

Popular posts from this blog

Lost in Translation

-
Enterprise Scrum - Tactics for Implementing Agile Practices If you are implementing agile practices, methodologies and organisational changes within the company without full executive support, you are probably facing an uphill struggle. I was watching a TV documentary on the space race the other day, and one of the interviewees stated that in today's world nobody takes any real risk... This is fundamentally the problem you face, agile is perceived as high risk and difficult to manage. From a traditional management perspective, it is! Agile is about recognising there is a limit to control, that all things are not predictable, and that although we have clear objectives and a general direction, the detail of functionality and architecture is unknown at the beginning of a project. Managers need to learn an empirical approach to work and ensure that feedback loops and frequent communication are embedded within the fabric of the organisation. So with so much risk... cost, direction, cont
Read more

Starting Out

-
I left Conchango and started in my new role at the beginning of March this year. I'd been working as Scrum Master ( www.controlchaos.com ) with the likes of Howard van Rooijen ( http://blogs.conchango.com/howardvanrooijen/default.aspx ) and Ian Shimmings ( http://blogs.conchango.com/ianshimmings/default.aspx ), and fundamentally wanted to take agile practices to an organisational level. Moving a development team of 25 from traditional methods to agile practices is an exercise in change management. But even the word change management implies a clear direction, manipulation or cohersion and "management" of the process. I knew straight away that in order to encourage adoption of agile practices I would need to capture hearts and minds rather than direct a change programme. My previous blogs discuss transformational leadership and emotional intelligence, and I recognised that this is how I want to lead development. Even writing (I want to lead development) seems to go against
Read more

Breaking the Iron Triangle: Project Manager v Scrum Master

-
Image
As a PM my general approach to initiating projects has been to build a Project Initiation Document (PID – Prince). A PID details the project objectives, initial scope, organisational structure, roles & responsibilities, deliverables, project processes (lines of communications, risk management, issue management, change control), plans, costs and timelines. And starting an agile project I would still identify most of the above and ensure it is clearly communicated to all stakeholders. But… I have learnt that adopting a scrum approach changes two fundamental things for a project manager: · The Iron Triangle · The Role of Project Manager The iron triangle of cost, time and scope (or quality) is typically the responsibility of the project manager to manage. Hopefully tolerance levels have been set for each element of the triangle, and if the tolerance level is about to be breached or is broken, the project manager escalates their issues to the project board or steering group. Previously
Read more