Tag Archives: Agile

Agile Transformation – 2

I have already started talking, but want again to continue talking about an easy subject: Transforming a company to agile.

Well, not so easy. But not as hard as some people think.

‘A journey of a thousand miles starts with one step.’

We are too easily discouraged by what seems a daunting task. We too readily make the mental mistake: “I have to have it all figured out before I can start.” Sorry, but when working with people, you know that ‘having it all figured out’ is not possible. One cannot, one should not, and one will never control other people.

Still, there are things we can learn and things we can do better to make (or influence) how the agile transformation will unfold. We are not all powerful. That is not the same as saying we are completely without influence and smarts and wise things to say and do. We have our talents.

I and a colleague are thinking about building a course on how to do agile transformations.

Some basic notions:
* change in organizations is hard (but far from impossible)
* there is much existing knowledge on how to get change to happen and how to get it to stick
* this knowledge is not simple
* agile transformation in some sense affects ‘everything’
* it is necessary to make a list (of work to do) and prioritize
* for many reasons, it is useful to work as a ‘transformation team’
* it is useful to learn some theory. Put another way: trying to learn from experiences at other places
* it is useful to learn and do and get feedback and repeat (PDCA)…in executing the transformation
* top-down or bottom-up? Yes!!
* although there is no ‘one size fits all’ answer, there is a basic framework, and some very common patterns
* for an agile transformation, our bias is that all change agents (well is that the best term?) must actually understand, in a real way, the key stuff they are recommending changing to. Ex: They should have actually been in a Scrum team, as a pig.
* ‘people don’t resist change, they resist being changed’.
* for more than one reason, in general we want the ‘objects’ of change to take some decisions about what the change is. (Freedom: what an original idea for humans!) This is not a stupid ‘everyone is exactly equal’ notion. Nor ‘let’s find the stupidest guy around, and let him decide everything.’ Perhaps more to discuss.

Some notions about the course.

* the course is only useful if it helps the change get more results. Just teaching some people is not enough.
* we define change agents broadly
* the course discusses some key concepts and theories
* the course does exercises
* a workshop, practical and specific to your situation, is included
* basic patterns of new idea adoption
* setting a scope for a transformation team
* determining the effectiveness of a transformation team
* what is a reasonable price for agile transformation?
* how do we convince the ‘buyers’ to take the plunge? How to convince them to continue to invest?
* where does communication fit it? How do we know we are doing the right amount and doing it effectively?
* what are some tools and methods the transformation team can use to ‘make’ the transformation happen?
* how does the transformation team identify emerging impediments to the transformation?
* is there a connection between the transformation team and the ‘real’ agile teams? If so, what and how?
* is there a connection between the transformation team and other groups in the firm? If so, what and how?
* how does the transformation team do adaptive planning, and explain adaptive planning, for the transformation?
* how does the transformation team measure success?
* what about scaling?
* what about transformation in multiple locations and time zones and cultures?

These are initial thoughts.
Your thoughts?

 

Facebooktwittergoogle_plusredditlinkedinmail