Thoughts on agility
I talked and discussed a lot about agility recently and I heard a lot of people talking about agile concepts. What you should do and what shouldn’t be done. What’s important and what’s not. What’s allowed? What not? How important is Scrum? Can you be successful without Scrum? Here are a few thoughts on this topic. Consider them as a mash-up of my personal experiences and discussions. Feedback welcome.
Understand where we’re coming from
When you talk about agile concepts in software development or maybe even in all kinds of planning, it’s worth taking a look back where we’re coming from. It’s worth considering alternative – classic – ways of getting things done. Let’s take software development. A few years ago software has been developed like this – and I’m pretty sure you know this story: Customer says what he wants. Boss asks dev team how long it takes. Dev team does some analysis and comes up with a number of days. Boss calculates a price out of it. Customer accepts cost and duration. Dev team starts working and after a period of time figures out that the deadline can’t easily be kept. End of story: Project is delayed or needs more resources or gets more expensive or features are cut. Alternative end of story: Software is delivered on time, but when handed over to the customer, it’s not exactly what the customer wanted. Both ends might have happened at the same time by the way. None of both is limited to only software products. I’ve been there myself. And if you’re working as a developer for more than 8 years chances are good that you have hands-on experience on the waterfall, too.
The most important precondition of going agile: Accept the facts
Non-exact planning happens in plenty of projects. Think about BER. Think about the house your best buddy built. Some things just can’t be estimated exactly up front. Others can: Think about the car you had repaired where price and time was estimated exactly. Think about a visit at the barber.
[Btw: Why is that? I’m not a scientist but I guess it’s the limited amount of variables when it comes to short term projects which make them highly predictable. Don’t get me wrong there are still things that can go wrong badly. But experience helps a lot if you’ve done a task several times and variants are limited. And when it comes to cars the number of parts which might be affected are huge – but limited. (Which doesn’t mean things can still be horribly complicated.) And when it comes to haircuts I’m certainly the wrong person to talk to. But I don’t remember a lot stories when someone told me that he or she was on the barber’s chair way longer than expected.]
Experience tells us that estimation & planning for software projects is almost always completely wrong. From my experience this is even true for projects which seem to be rather small in the beginning and which don’t look too hard at first sight. This leads to the following conclusion: Planning – especially long term planning – of software projects is just not reliable. We’ve got to deal with it! We’ve got to accept the fact that our planning and execution isn’t close enough to reality. In consequence let’s switch to a procedure that is closer. What is closer than exact planning up front? Adjustable planning!
[While reading this a second time here’s an observation I came up with which is worth mentioning: Isn’t moving to an agile methodology nothing more than being able to go into retrospective regarding our past project planning and execution and to be able to learn from our experience. So basically when we decide for a new agile procedure - aren’t we already right in the middle of build-measure-learn ?]
Not delivering what the customer wants is something that doesn’t seem so common across industries outside of software development. At least I’m not always aware of it. But it happens now and then. Think about a random feature in your car nobody needs or one which is designed badly. In my car it’s the position of the cup holders. [*arrgh*] However for some reason it doesn’t affect me too strong. It seems like myself and from my perception a huge share of other people are more forgiving when it comes to “hardware” problems. Maybe it’s the perspective: Are customers assuming that changing something in software can’t be as hard as fixing hardware? Like changing the color of a car after it has been produced - which truly would be almost impossible? Maybe therefore they just don’t accept that software is brought to the customer in an non-perfect way? I don’t know. And it doesn’t matter. If something is designed badly or useless every customer has the right to complain. And they will.
The good news is: We learned this over the last years. Don’t get me wrong: We didn’t learn a technique. We – our industry – learned how our customers behave and what they expect when it comes to software. We got to know our customers throughout the years. So we can adapt this learning today and try to do it right – or better – next time. All we have to do is deliver more exact what the customer wants. But how do we get there? By asking the customer. Over and over again.
It’s all common sense
There’s no magic. It’s all common sense. I remember when I went to university and took a class on project management. I learned about different approaches on how to work in projects, how to run projects, how to lead projects, how to estimate, plan and behave. It all sounded like common sense.
When you’re asked to get something done until a certain day and find out you can’t – what would you do? Wouldn’t you tell that person waiting for you that you’re running out of time? Sure you would. At least if that person means something to you! When would you tell that person? As soon as you find out, I’d guess. At least if that person means something to you. And what then? Well, probably you’d try to figure out a new date together and do some rescheduling. This is the guidance of common sense.
When you’re asked to do something and you’re working on it but you aren’t a hundred percent sure if you’re on the right track, what would you do? You’d ask the person who’s interested in the result, right? Yes, absolutely at least if you’re having a certain interest in success. It’s just common sense.
These were just a few examples. It’s all common sense. All of those project management courses and trainings should have a bold bottom line on every page that sums it all up to: In doubt follow common sense. And don’t behave like an idiot.
Why are we behaving like idiots?
As this is all common sense – why don’t we act like this, when we’re working in a professional environment? What keeps us from doing “the right thing”. What keeps us from following common sense? Why does it happen that projects are delayed over and over again? Why does nobody raise a flag? Why does it happen, that we’re shipping useless stuff nobody ever asked for?
The answer is pretty easy: Because during our professional career our environment doesn’t always provide breeding ground for common sense. While this might sound dramatic think about it for a moment. How often have you had the feeling that your working group in the company you’re working for is led by a complete moron who’s following nonsense goals? How often did you follow orders inside your company that were just stupid, wrong or completely useless? How often have you been asked to do one thing to justify something completely worthless and wasted hours of time that you could have better spend working for something really valuable? How often have you seen wrong decisions been made without the chance, guts or power to interfere? Exactly. This is how things are, this is the environment we’re living in. Again: We have to deal with it. We have to deal with the fact that common sense is something every single one of us might follow as a private person but in a lot of environments (e.g. companies) common sense is eliminated somewhere between career opportunities, hunt for benefits, politics and power games.
We need guidance
With this knowledge, what do we learn? We learn that we’re in need for something to shelter us from insanity. We need some mechanism that forces us to go into the right direction even if it is very tempting in daily business to take the wrong direction. We need something that helps us finding common sense, if we can’t find it ourselves. We need guidance. This could be very simple rules we follow, no matter what. Those rules enforce us to not plan too far into the future. Let’s call it a framework. Or process.
The funny part is: Processes & frameworks have been around for a pretty long time. Unfortunately, experience hasn’t. Software industries are pretty young. Nobody knew how to get things done in the first place. People tried things. People certainly tried to follow common sense. People came up with rules & processes. Some worked. Others didn’t. Experience shows which did and which didn’t. Here’s no one to blame. Nobody could have known better.
There’s no shortcut to experience except by learning from others
However, in the meantime we do know better. It would be a huge mistake to not consider experiences and learnings collected by others who fought in the frontline. All the knowledge that was collected over the years when people tried hard to get processes running following a waterfall. All the thoughts and ideas which were created and tried out. All the knowledge that has been collected by the pioneers should be taken under consideration. When you figure out that things currently don’t work for you as expected, I think it’s reasonable to rely on three things: Knowledge, common sense and the experience of others.
[Talking about experience of others the term “Scrum Buts” comes into my mind. “ Scrum But ” is basically when not all aspects of the Scrum rules are being considered. E.g. people start using Scrum but they don’t follow the rules completely. They say things like “In our company we do Scrum but during the daily stand-up we keep seated”. While I understand the point of view that the success of an introduction of Scrum will hopefully not be dependent on such a rather minor aspect there’s another dimension to this attitude: Whenever you don’t follow the rules of a framework, be aware that you might be ignoring experience of others. And I hope you have a good reason for that. One reason might be the maturity of your team. Be true to yourself: Are you that experienced?]
It’s just a tool
So where does all of this lead to? Scrum is just one tool, that helps you to follow common sense leverages experiences of others and guides you through the weirdness of your daily business. There may be others. Maybe currently it may be one of the best for certain scenarios. Maybe soon new tools will be developed. Scrum and/or agility is not what you are ultimately looking for.
What you’re really looking for is customer value. A good tool (I’m not talking about a software tool here) can help you to get there. But the foundation for every usage of any tool is common sense. Common sense will make you learn from the past. Common sense will make you want to learn from the past. This will increase customer value because you get better over time. Common sense will introduce new behavior when you work with customers and colleagues. Common sense will make you go into retrospective from time to time to change things which didn’t work. What you get in return will be experience transforming to knowledge. This will bring you closer to customer value.
Common sense will make you look at others to learn from their experiences. Experience might lead to you choosing an agile methodology. Common sense might make you choose an existing framework to help you get started and to leverage other people’s experience. So common sense will speed up your learning.
A tool like Scrum or other agile concepts can help you get there because it enforces common sense when it might be sacrificed otherwise and you might run into the same mistake twice.
In my opinion this is key for all agile principles: You have to be willing to learn, to change and to adapt over and over again. Then call it what you want.
Scrum is just one tool that helps us to follow common sense and enforces learning. Common sense is the foundation of customer value. And customer value is the ultimate goal.