Building a Change Artist

September 15, 2014


So you want your organization to change? Then you just might need a change artist. What is a change artist? A change artist is someone who leads change in an organization by sharing example and by influence using visualization. That is to say, a change artist will not mandate or coerce in order to introduce change, but rather they will begin with themselves and demonstrate their own change – thereby providing the example and the potential motivation for others to seek similar change in themselves. The visualizations help to share the story – you need the artist.


I think that people who are able to express their ideas through pictures are particularly well suited to creating the kinds of compelling visualizations that help convey what change might look like. They don’t have to be technically competent as an artist. Just good enough to draw stick figures and tell a story. Its really not that hard once you stop worrying about what people think.

Can we create people like this? Or are they born to it? I don’t think the hard part is the art. Anybody can do that. It’s how they approach change that matters most.


Perhaps there are organizations that would be more receptive to change initiatives that aggressively use visualization techniques. I can’t help imagine that visualization can add a compelling element to any transition engagement. I’ve not see much evidence of that sort of approach on agile transition engagements that I’ve been on. I’ve seen the power of what a simple drawing can do to draw people together and generate discussion. Using some sharpies and some butcher paper I can start a conversation that will continue long after I’m gone. I’ve seen it happen. There isn’t a text document in the world that can compete with a good picture. I’m not talking about Visio diagrams either. There is a quality to the hand drawn diagram that invites people to engage in a way that no sterile electronic diagram ever will. I’ve held two versions of the same diagram, one hand drawn and one electronic, side by side and the preference is almost always unanimous – the hand drawn version wins. I think the magic lies somewhere in the the errors and mistakes in the drawing. They must serve to remind us that we are  human. Perfection isn’t necessary, and in fact may be counterproductive.

That’s who I want to help me change the world. Combine the passion for change and the art and I’ll give you a change artist.


Starting Backwards

September 13, 2014


If you were to draw a diagram of the entire product development process from start to finish, what would you start with? If you are like me, you’d probably start with the customer, or maybe sales. Then you’d probably pass the idea along to product management and onward to development. Last, but not least, the product would make its way to operations for deployment in production.

It’s pretty straightforward, front to back, end-to-end. Everybody knows how it works. And if we are going to try to improve this process, where do you think we typically start?

At the front? In sales? No.

At the back? With operations? No. Not there either.

Right smack dab in the middle? BINGO! Development always gets the love first.

Now what kind of lunacy is that? Now I’ve been part of a process improvement effort or two, so naturally I start to think I see patterns. Well, hallucinations of some kind anyway. Almost every time we start with the development teams. We do a good job, we get them up and sprinting, train a few scrum masters, console a few managers, and Bob’s your uncle: the dev teams are agile! Then what happens?

Downstream, the operations teams aren’t on board with the whole agile thing. They aren’t going to let you change their release processes just to satisfy some fad. Rapid change? Are you nuts? And what about the other end of the value stream, sales? They’re willing enough if it makes them money, but you’d better deliver (which isn’t happening with the operations guys, so you are screwed).

So lets take a step back and look at the value stream. Where do we typically see the most time spent? It’s not development – we’ve been squeezing development in one way or another for decades. However, you can find the most amazing queues in sales. With the rest of the organization moving so slowly, they naturally develop queues as they wait for the work to get done.

The question is, why don’t we start at the back? Why don’t we make the end of the value stream our focus first? We need to stop starting in the middle. Goldratt would have us chasing the bottlenecks. More power to him. If I speed up operations first, I may not see an immediate increase in productivity, but I have created the runway for success. I have them on board and bought in. Now, we move up the value stream to the Development teams. If we can get them performing, then we have already prepared the runway for them. No longer do we give them a fast car and ask them to drive it into the wall. Now they can deliver and they can do it with proper support from operations.

From there we can continue to move up to Sales and the front end of the value stream. They should be an easy sell at this point. So, the question is, why start in the middle?

Some Ideas for Managing an Effective Agile Transition

January 14, 2008

Going into an agile transition there are a lot of variables that need to be considered in order to make the transition a successful one. Those variables include:

  1. Timing – Should the transition be made in the middle of a major project or should the transition be timed such that it takes place between or at the beginning of a major project
  2. Transition Strategy for multiple teams – There are two major strategies that I am aware of (and I’m sure that there are many more): make the transition all at once, or start with a pilot project and move gradually toward an agile organization. Each has its own costs and benefits. The culture of the organization can also play a role in making this decsion (cautious vs. aggressive)
  3. How will distributed teams be brought on board. These days it is very common for companies to have either distributed or outsourced teams working around tht world. An agile transition is going to impact them too. How do you manage their part of the transition to agile? Ignore them? Train them up too? And what about the cultural considerations with trying to train someone in Agile techniques from a radically different culture?
  4. How will the training be organized? Do you want to train and certify everyone before starting the first iterations of the project, or is there more value in giving them an orientation, setting them loose, and then returning to run them through the certification course after they’ve stubbed their toes a few times? Again, there are trade offs to each approach.
  5. What sort of coaching support will you provide for the teams?
  6. What kind of additional materials can you bring to bear in support of the teams making the agile transition.
  7. how will the Agile roles (Scrum Master, Product Owner, Team) be mapped to the existing organizational structure. What will be the impact on the people who are currently in those roles?
  8. What kinds of tool support may be required to help facilitate the transition to agile? Communication support tools for distributed teams? Automation and testing support for operations and QA teams?
  9. What are the drivers for the change to Agile? What is motivating this move? A desire for more rapid releases? Perhaps reduce costs? Improved quality? Once you have identified the drivers, then you need to identify the metrics you are going to use to measure the success of your agile transition. Bug count? Throughput? Lead time?
  10. What additional training can be provided in support of this transition? Training in technical practices such as TDD or design patterns?
  11. Is scaling an issue here? Will the teams need to be trained in managing teams at the enterprise level (ie. Scrum of Scrums, Meta Scrum)?

These are just a few of the questions we have been asking as Ibegin the transition to agile for this company. For some of these issues I have opinions and recomendations. For others, it is simply a matter of discovering what the motivations and desires of the company are.