Being agile or working agile is not something that is exclusive to a specific area or a specific industry. It is an approach about wanting to see a better end result, to be willing, and interested in, to improve and change to create the greatest possible benefit. Or as John Steinbeck once said, “to think differently today than yesterday separates the wise from the stubborn”, regardless of whether you work in IT or not.
Imagine that you wallpaper a room. It is three o’clock in the afternoon on a sunny summer day, it is hot, and you are tired. You are halfway through putting up the next piece when your dear partner comes into the room and says that he thinks you should choose a different wallpaper than the one you bought, and which now decorates about half the room. How does your reaction to this scenario play out in your imagination?
Nevertheless, the second agile principle says: “Welcome changing requirements, even late in development”. Do not accept or tolerate, welcome, even those who are sold on agile development would probably feel frustrated in the scenario above.
How can you then call yourself agile, if you only accept – not ‘welcome’ – these changes?
In the scenario described above, it’s conceivable that your partner saw something that you did not. That his or her desire to make a change doesn’t come from any malice or arrogance but to create the best possible result. Despite that, we have a hard time not seeing work as wasted. So, what does it mean to welcome changes late in the process?
In order to be able to understand that the work done needs to be changed or even thrown away completely, it is necessary to be able to see a better end result. A vision of the future that has been improved. Because if you are not invested or aware of the end result, the frustration will increase – why should you have to start over now?
Many companies find it difficult to clearly communicate and inspire with the vision they have, and it is obvious to them why the new change is better! Everyone should see that, right.
But now it’s about system development, not wallpapering. In system development, it’s not about work that went on for hours, or days. Instead, we’re talking about work that may have been going on for weeks, months, or even years. And it is not only our own work, but also work from our colleagues that may need to be discarded. The stakes are greater.
When digital cameras became big in the early 2000s, there were two companies that adapted to the new market and two that didn’t. Nikon and Canon became big in digital photography, Kodak and Polaroid went under, what can we learn from this?
Obviously, it is not enough to innovate to succeed as a company.
Kodak invented the digital camera but could not, or did not want to, change its business model to profit from the new invention. Innovation is not enough, what we think will be good doesn’t always turn out well and what we don’t think will be good can become our future. It doesn’t matter what we think, but it is the customers and the market that ultimately decide what succeeds and what doesn’t. And what does the customer want? Sometimes they have no idea until they experience it.
Now you may feel inspired to reframe your work, to make change a strength instead of a resistance. Then it is good to keep in mind that the work we do in working life is often part of a larger chain that is not always under our personal control. We are never faster than the wholeness, if you work with system development, there may be a requirements analysis, a design, or a budgeting, for example, before you are involved. When we seek to maximize our flexibility, it is important to look at the entire chain. From idea to use, small changes are of course good to make on an ongoing basis and we should never stop looking for how we as individuals can become more flexible in our work. But when we decide on wallpaper months or years before we start wallpapering, and maybe also decided by someone who is no longer involved, we have a challenge changing these decisions.
Is it possible to measure our flexibility then? Yes, by asking yourself: “if this decision I’m about to make is wrong, how long will it take before the error shows?”
If you work in product development, the answer is probably that it is only when our customers get to use our product for real. This is where methods such as prototyping and A/B testing to create experiments come into play.
However, in the end it is very much about the culture we have. You may be reading this thinking that it would never work for you. That’s not how you work, but if you think it would be good if it did, then maybe you are the right person to make a change in your organization.
When change happens, it is always because someone does something different. So, review the length of the decision chain and whether it can be shortened. Watch the results expected and whether they are actually achieved. Try things and fail and learn something new from the failure. Prepare yourself to be surprised by the results, kill your darlings – don’t get too attached to your own ideas, and welcome changes, opportunities, and lessons that it entails.
That’s my way of looking at agile, but who knows? By the time you read this, I may have changed my mind.