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.

TL;DR:  

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.


Comments (1)

  1. Unfortunately the story is almost never that simple. The customer seldom knows what he wants. The requirements are seldom defined at an approachable level of detail, the complexity being often understood only when the development is already half-done. The boss seldom asks the development team how long it takes, and even when it does the team needs to take a decision with incomplete information. Lot of time is lost in design without understanding completely the requirements or narrowing the requirements at the needed level of detail. New requirements are included in the project and often aren’t discussed with the development team, sometimes without considering their impact on the solution and schedule.
    Often the customer has a fix budget and a timeline from which is calculated the development time. The development time is usually 30-40% from the project time, quite often the developer having to solve design issues or problems existing in tools/frameworks. Quite often the developer is burdened excessively with meetings and other project and non-project activities that often aren’t considered in the schedule.

    Many of the issues can be tracked back to communication between PM, architects, developers and customers. Each of the mentioned parties have own view that quite often diverge. Important information get lost in between. It’s also true that the developers seldom are in direct contact with the customers, that the developers maybe haven’t understood what the customer wants.
    Besides communication there are other Project Management issues that have impact on the project – availability and the choice of resources, unrealistic schedules & planning, too many status meetings, inadequate PM skills, lack of adequate training, and so on.

    Agile philosophy attempts to address some of the issues existing nowadays in software development and sometimes it even succeeds. Most of the points from the Agile Manifesto make sense –frequent deliveries, closer/better communication between customers and developers, minimizing the amount of work, accent on self-organizing teams. On the other side looking at how this is implemented in practice – changes are not adequately coordinated, requirements are inadequately documented, people try to implement ad literam a methodology, pair programming, user stories, too much required transparency and treating programmers like dummy interchangeable and commoditized components – make from Agile a nightmare and for many projects a bad choice. Frankly, the way it is implemented, it seems more a method of babysitting the customers and providing more transparency for customers and their investment rather than building an infrastructure for success, of investing in developers.

    “Common sense is not so common.” (Voltaire) I think that organizations spend too less effort on creating common understanding, in diffusing knowledge inside the teams, in helping employees educate themselves further.

    A methodology might enforce some common sense, though it’s not a perfect recipe, guarantees no success by itself even if many expect too much from it. A methodology is a mean to be used and adapted as considered and many ignore this important aspect, attempting to follow blindly what’s written in books without thinking for themselves. I have seen Agile projects that failed lamentably, projects in which facts from the Agile propaganda kicked back, being somehow invalidated by practice.

    It’s difficult to argument that Scrum is performing better than other methodologies. In the end each project reduces to the people involved in the project and their experience, capabilities and effort spent in addressing issues as they come. I think that one has to take from each methodology what works, build an infrastructure that supports adequate communication and successful projects. There are seldom methodologies or recipes that work for all.

    On whether Scrum helps organizations follow common sense and enforce learning depends also how the methodology is used, and how it’s integrated in organization’s infrastructure.

Skip to main content