Thinking for a Change

The thing I hate most about myself is that I don’t want to change

The first XP book was very important for me. It changed the way I work. It changed my life.

I still apply the practices to improve the way I work. The principles have helped me to make my work more fun, sustainable and successful. The values have helped me to do worthwhile work that delivers value.

But “Embrace Change“? I don’t like change.

How to avoid change

I avoid change on my projects by

• Really understanding the needs of customers, stakeholders and users. Those needs change from time to time, but not very frequently if we really get to the core of what these people value. I get accused of doing Big Upfront Design or Analysis, even in companies seemingly doing Waterfall. Why waste so much time upfront, can’t we start building yet? Customers don’t know what they want anyway, so why try to discover what they need?
• Not committing to decisions too soon, applying Real Options. If we commit later by delaying decisions to the last responsible moment and gather more information, we need to come back on fewer of our decisions. I do get called a procrastinator. Real leaders take charge, take decisions!
• By not being distracted by useless technology churn. Simple, reliable and known tools and technology in our toolkit let us concentrate on adding value. I do get called a dinosaur, not up to date with the latest framework or fad du jour. Real geeks only work with the latest 0.1 version of technologies that are so complex that we can spend months unraveling their intricacies (and bugs). I need a well-padded resume with all the latest technologies to get that next job when the shit hits the fan on this job.
• By making sure we consider supporting processes and users in our value analysis. All too often we focus on the shiny business value generating processes but forget that these can’t work unless people can perform the unglamorous supporting jobs that make these value streams possible. I do get called a Waterfall analyst, who wants to explore every nook and cranny of the system before we can start building. Real Agile teams deliver Business Value, cash quickly. Why waste time with non-business value-adding processes like getting the product into the hands of the user or managing the system to keep it relevant?
• By making a plan (not a schedule) of the goals we want to achieve in the future so that we have a guiding vision when we travel the path. I do get called an old-school project manager who wants to control and stifle the creativity of his “resources”. You can’t be agile if you have a plan.

Projects with fewer changes are a lot easier and less stressful than those with many changes. These projects implement Heijunka. They deliver value surely and steadily. I like that.

Embrace risk reduction and new information

I welcome any change which reduces risk. We continuously identify our main risks and find ways to avoid them. For example, we discover that there’s simple alternative way of doing something. We can use that as our backup strategy if the planned way of doing the work doesn’t get ready in time. For example, we first implement a very basic implementation of a business process and iteratively refine it, so that we’ll always be ready to release by the deadline. Of course, we have to use that extra time that Real Options gives us to actively seek out information and reduce risk.

Embrace increased flow

I welcome any change which can increase flow, get us to release faster and get the cash flowing sooner. For example, we can start by statisfying a subset of stakeholders and users. We can focus on on value stream at a time. We can mercilessly pare down what is really needed to achieve goals. We can get rid of wasteful checks, approvals and delays. We increase quality to decrease changes due to rework.

Embrace value increase

I welcome a change that increases value. For example, “Exchange Requests” let the customer increase the value of our work. If the customer wants to add a feature to a release, they first have to remove an equivalent amount of work from the release. The customer will only perform the swap if the new feature has more value than the one swapped out. So, for equal (or lower) cost, we deliver a product with higher than initially expected value.

Embrace cost and investment reduction

I welcome a change that reduces cost or investment. I welcome a new, simpler way of achieving a goal. I welcome reducing scope as we discover that we can simplify business processes. I welcome a reduction in “dimension” as we discover that we can satisfy user needs (for now) with less exhaustive or refined implementations. I welcome a way to reduce the amount of work in process.

I’ll get me coat then…

Can I be Agile if I don’t Embrace Change? Can I be Agile if I value people and their interactions AND processes? Can I be Agile if I insist on customer collaboration AND a contract?  Can I be Agile if I only want to respond to beneficial change AND follow a plan? Can I be Agile if working software is not the solution or only a small part of the solution? Can I have my cake AND eat it too?

Where do I go to hand in my Agile badge?

If anybody needs a Waterfall coach, let me know. I can change. I’m agile 😉