Agile Transformation

This content is syndicated from Agile & Business by Joe Little. To view the original post in full, click here.

I have already started, 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 should know by now that 'having it all figured out' is not a notion even worth talking about. You cannot, you should not, and you 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. I said you were not all powerful. That is not the same as saying you are completely without influence and smarts and wise things to say and do. You are a Jedi.

We are starting to build 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) 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, god, is that the world's best term or what?) 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 change'.
* 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 in American corporations!) 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 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 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?

Leave a Reply

Your email address will not be published. Required fields are marked *

16 − three =