Downloadable Video: Achieving Agile Transformation with Kanban, Kotter, and Lean Startup

Change in IT is the only constant that you find in IT. Even the methods for managing change, change. Resistance to change is an open invitation to the Grim Reaper of software development projects in decent size companies.

I have mentioned this in other book reviews, and find that it applies here as well. I was sitting in a meeting some time ago with a company that was embracing Scrum like a ten year old being offered a warm plate of chocolate chip cookies. They were grabbing at it as fast as they're little hands could reach out and grab the goodies.

Watching this made me wonder what is was about Scrum that made them embrace it so emphatically. They had claimed to be an Agile shop for years, but were still failing to deliver quality software on time within budget. In past years they refused every single proposed process improvement recommendation made by consultants.

They literally went from zero process (using the name Agile to execute no process at all) to zealot Scrumbots overnight. They didn't even think once about the risk that is associated with change, or how much change really needed to happen in order for the project to be successful. The outcome of this project was very bad, job costing bad.

I have seen Scrum attempted multiple times. Depending on the perspective most failed or most succeeded. Watching from the sidelines, our consultant team's view was they failed miserably most of the time, but according to the internal managers that made the choice to go with Scrum they were a huge success. Depending on who was asking the development team, us, or the managers, they had completely different answers.

In most of these projects the most important party, the end user, saw no change to the quality of software delivered and sometimes slightly worse quality. They were never the wiser that the team was attempting Scrum, so their opinion didn't matter. What?

Yep, in most of these attempts I have witnessed, the end user's activities didn't change. Neither did the upper or middle management, sales, or marketing. It was a development team level attempt to implement a bottom up change that requires change at every level in any decent size organization for it to succeed.

Implementing new processes requires a lot of change and that means a lot of resistance. Change is stressful, even positive change is stressful. According to the original Holmes and Rahe Stress Scale marriage is number 7 on the stressful events list.

The way I see change is if you don't manage change, change will manage you. Have you ever been in one of those environments labelled fire mode. Constant chaos is the norm for the day. Everyone comes in grabs their fireman's helmet and runs to the brightest burning fire.

Watching this video series will show you how to avoid that. This videos series is more of a means to an end rather than an end in itself. If you choose to pursue the lines of thought in this series you will begin of a long, hard, fun, and rewarding journey.

I have copied the description of each lesson below from the LiveLessons site.

Lesson 1

”The Case for Lean Change” presents the case for Agile change and showcases why technology organizations should use it. Current management thinking is out of date and needs to be revamped for today’s uncertain markets. Agile and Lean methods provide the basis for modern technology organizations looking to succeed in the modern world. Agile change is risky, and many agile transformations fail. Lean change is an agile change management method that provides solutions to many of these challenges.

Lesson 2

”The Change Canvas” starts with a review of the canvas as a tool for collaboration. The lesson includes step-by-step instructions for using the candidates, allowing change agents to co-create and co-execute a change model with change recipients and other change stakeholders. The lesson explains the concept of a Minimum Viable Change (MVC), enabling small changes to be validated quickly. Finally, suggested techniques and best practices are described when applying the Change Canvas to change initiative.

Lesson 3

”Validated Change Lifecycle” describes a lifecycle that provides a structured way for change agents to learn their way through a successful agile change. Insight is provided as to how change agents can be at risk and it discusses agile change initiative using the Validated Change Lifecycle. Each step of the lifecycle is examined using a real world example. The last segment pulls the four stages together to give a complete Lean Change lifecycle view.

Lesson 4

”Managing Organizational Transformation” examines how the Lean Change method can be scaled to support large-scale Agile transformation. The lesson provides advice on how to structure and facilitate transformation planning sessions using a Transformation Canvas. Prioritizing MVC based on risks exposed on the Transformation Canvas is also covered. The lesson also provides a walk-through of a catalog of reusable MVC patterns, as well as examples. Finally, it gives advice on how to structure workshops, meetings, and synchronization to effectively manage a large-scale agile transformation.

The world has changed its demands on products and services in the IT world. It wants new innovation tomorrow not next year, and when they get it tomorrow, they want to be able to customize it to their individual needs.

There really is not much choice. You are going to have to start thinking about implementing agile processes in your organizations sooner or later, do yourself a favor and watch this video series first.

Get the Videos here!!