This is a very in your face title especially for a blog that focuses on Agile. Have I lost my mind or come to my senses? Probably neither (I list my mind a long time ago), but hear me out.
We should not be striving to do agile, we should be striving to be agile. For me, agility means being able to accept change without consequences. Consequences mean disruptions in the form of re-allocating work. Putting things aside. Stopping what you are in the middle of doing and doing something else. Can we do that? Probably not, but that isn’t the point. It is the idealistic goal.
When you “do” agile, the usual reason is that you want the benefits of agile. Faster turnaround, less bugs, higher quality. The thing is, just “doing” agile won’t give you that. You can do all the stand ups you want. Have sprints, retrospective and have the board. It generally is meaningless. Sure, you may make some progress but you are not agile. You are only going through the motions. If you really think about it, doing agile may actually make the same amount of work take longer than waterfall. Yes, I did say longer. The reason is that with agile there tends to be a lot of rework. You build a little something. Get feedback, if that feedback is negative, then you may have to do that work again. The thing is that you are only doing a little bit more work. You are also building something that the customer wants or needs. With waterfall, you get feedback towards the end. If that feedback is negative, usually what happens is that it is now too late to change anything. So, the work is forced onto the customer. They have no choice unless they are willing to delay. So they live with it. Not a happy customer, but they have had this for so long that they are use to it.
So, don’t have the goal of doing agile, Have the goal of being agile.
So how does this look?
Let’s start off with a trip to Lala land. Where everything works as intended.
In every project in Lala land, they have a scrum board. Just like what we have, but in Lala land, work flows smoothly from one end to the other. New requirements come in, they flow from one stage to the other synchronously. When the developer finishes development,the tester has just finished testing the last lot of work and thus pulls the work from the developer and tests. The same with UAT and finally the move to production is done immediately after UAT finishes and only takes minutes. I hear you say, let’s be pragmatic. This is not the time to be pragmatic. That will come later. This is the time for dreams and idealization.
So, what are the benefits of working in Lala land?
Work flows freely without delay. There is no backlog as work is done as soon as it arrive. There is no need for rearranging work as it gets worked on as soon as it is commissioned. In other words, this system is agile. Change can happen on a whim with no repercussions. Sounds like a fantasy. It is.
Now we bring in reality. There are delays with work. It starts to build up or has already built up. Deadlines loom, and we have organized chaos. This is the current situation and you have probably been doing agile and see this mess.
So the question is, do you want to live in this situation, or do you want to live in Lala land? I’m guessing Lala land. So, how do you get to Lala land? First thing, do t accept the current situation. Second thing, do something that moves your situation a little closer towards Lala lands ideal. This is where doing agile comes in.
The way I see it Agile processes do one of 3 things.
- Highlight problems
- Solve Problems
- Highlight and solve problems
1 being the predominant focus. In other words, Agile processes help you identify problems towards being Nimble. It is the permanent solution to those problems, not workarounds that help you attain agility.
For example. In Lala land, they accept change without any consequences, but how can you accept change without any consequences, if you are working on something. You have to stop what you are doing, then do rework to accommodate the change. Here is our first problem. So instead of saying “It can’t be done”, think “How can we do this?”.
One method may be to break down the work into smaller chunks so that when a change comes in, a smaller chunk of work is disrupted instead of a larger chunk.
So what needs to be put in place to break down work into smaller chunks? Here is our next problem. Well, we need to spend some time breaking that work down. When should we do that? And so forth. You may then get a whole list of things that need to be done to attain the goal of accepting change with no consequence. Some will be easy to implement, some will be hard. Don’t worry about that, Just pick the first thing on the list, determine what you expect to happen once it is implemented, then implement it.
Once implemented, evaluate. Did it achieve what you expected? Yes, yay! Does the next thing on the list still make sense? Yes, implement. If either of these questions return No, then learn why then rethink your plan. This will happen frequently. Circumstances change, just re-evaluate and try again. It’s part of the journey to being agile. Did I mention that you need to do this while still doing your normal work? Well, you do. So you can’t spend weeks or months doing improvement while ignoring your normal work. The only way you can do this is to continuously do a little bit every day. Every bit counts. Continuously improve just a little every day towards that goal of being agile. Now that you start doing this, the agile processes such as scrum, Kanban, Lean Software etc will add structure to what you are doing towards being agile. This is the doing side. These will help you find the problems towards being agile, solve them and move on.
What people tend to do when the do agile without being agile is the goal is ignore the problems, push things faster and then wonder why it all falls apart. Try not to fall into this trap. If you do, you or those under you may end up hating agile because it is a really really bad experience.