Oh to be Agile
Do you want to be Agile or just be agile?
I can see your faces now while you mouth ‘oh no not another blog about Agile’ or ‘some other idiot who can’t do Agile so he is slagging it off’. Hopefully, if you carry on reading you will find that this piece is neither of those. I am going to talk about stripping how you work in an Agile shop completely down and by concentrating on just a few things you can improve your working practices without stressing about whether you are doing Agile or not.
I have been struggling for a while with other peoples version of Agile and how it fitted in with what we were doing as part of the company I work for. I followed people on Twitter and listened to podcasts as well as reading blogs. They all in some way contradicted each other and as a colleague said very rightly that they start to sound very preachy about it. In a way, I found this very depressing as I felt that my version of Agile was far removed from what others were trying to push. In the end, I removed myself from twitter and stopped reading about this Agile thing while I pondered what the problem was and why I felt it should be simpler than what others are making it out to be. I started to think of other situations within development and outside of development that were agile yet they didn’t follow or even know about Agile or follow an Agile framework.
The successful start-up with two people that is probably the most Agile a Software company is ever going to be and they probably don't even know it or more importantly care. They hold no official ceremonies but they are constantly improving and talking to each other they have what is known as open and effective communication and they are honest with each other. They constantly talking to their customer base and stakeholders there is constant feedback on the product which they act on accordingly. While at the start the pace may be too fast to maintain they slowly find a rhythm that allows them to develop at a constant pace.
In a commercial catering kitchen, if you have never been in one I highly recommend you try and get some experience in one because it is amazing. To the outsider, it can look like complete and utter chaos but to the people working within that environment it is a dance and the head chef maintains the beat. Each individual is aware of what is going on around them and they are still able to dive into someone else's station to help them out if needed. Chefs constantly taste their food getting immediate feedback but also other chefs tasted it to make sure everyone was dancing to the same tune. They constantly have to deliver food within a time frame as customers may complain if they get their food late or cold. This is controlled with the Head Chef constantly communicating with the team and the team constantly communicating with the Head Chef. But the communication goes further as waiting staff are also within the communication loop so they can keep the customers within the loop.
When I served in the army we were always told the phrase “no plan survives first contact with the enemy” and because of this each individual was to be aware of everyone else's job. Every private knew what the Corporals knew every Corporal knew what the Sergeant knew and so on. This meant that when the plan did go a little bit off track (in some cases it completely derailed) each individual was better equipped to handle it and knew a way to quickly replan and move on because they knew what the overarching goal was they didn’t sweat about the small stuff that might be going wrong at the time. We had a long term objective a medium-term goal and a short term plan this meant that we knew what we were aiming at achieving but we only concentrated on the short term plan because that was what was in front of us at the time.
I then thought about my first experience in a software shop. We followed a waterfall framework I hear hissing from the crowd but when I look back on it I find we were probably more Agile than any other place I have worked. This is a bold statement Agile came around because of the problems that were found in long drawn out waterfall projects. However, while Waterfall is a framework Agile is a philosophy and an umbrella term that can include frameworks like Scrum and Kanban so I have not seen any reason why you couldn’t do waterfall but with an Agile philosophy where it is suitable. Clearly, Waterfall for most cases is not suitable anymore with the speed of iterations increasing but for some smaller projects, it could still be useful.
We were in maintenance mode our customers sat on the floor beneath us and we were just making small improvements and bug fixes. Why do I claim this to be Agile? Well for one we had constant communication with our customers and they were with us on a daily basis as we moved through there requirements. As one of the testers in the team, I was constantly getting involved with the developers to see what they were up to what was being developed and what requirements were coming up next. We kept communication up between everyone and we constantly improved ourselves and our processes even binning anything that didn't work is this not the core of Agile?
So as I come to conclude my thoughts on this I have to say that trying to be Agile is the first problem. Following a framework by numbers like it is a painting by numbers is another problem. Agile didn't start by being Agile, Scrum or Kanban or any of the others didn't start with Scrum or Kanban and so on. So maybe we should forget about trying to achieve Agile and just be agile instead. Looking at the examples above they all have one thing in common they have learned a way of working that suits their needs.
Saying this, however, there is clearly some skills that help us deliver faster and improve our services. For me, I would say the following are the most important.
- Open and effective communication - not just in the team but across the company, with your stakeholders and customers (As a side note communication is more about listening than about speaking)
- Honesty - identifying the problems and being honest about them having a root cause analysis on these problems to find the best way to fix them. Also, be honest about the good things and doing a root cause analysis on them to see how you can keep these things and use them for other ideas
- Self Organised with good and effective leaders - The individuals and the team need to feel empowered to be self-organized but for that, they need effective and awesome leadership from others to point them in the right direction and keep them on track
- Have a long term Objective - knowing where the company is going helps you to put into context what you might be doing now but be aware that as new information is obtained that the objective can change.
- Have a medium-term Goal - A medium-term goal is something that as it is closer shouldn’t change to much but maybe refined it allows you to check you are on track and the objective is still correct.
- Have a short term plan - Planning is not a bad thing it is useful and allows you to make sure that at that current time with everything the team knows at that moment. The plan is not wrong at the time but maybe wrong latter especially if your plan is stretched out to your medium-term goal.
Wait I hear you say what about value, “Agile is about delivering value faster” we are all aiming to deliver value I don’t believe as adults that we need to be reminded of this all the time. I also believe that by aiming to implement the above the value will look after itself. I know that by having a framework or a manifesto it can help you with answers or something to strive to but I honestly feel that the Agile Manifesto, while its original concept was all about fast iterative development, in a fair amount of situations it has caused more problems than it has solved and while starting with a framework can be beneficial if you only follow it by the letter and don’t adapt it to your needs then it is set to fail.
I will give you this as a possible approach to help your company to just be agile, start by looking at how you work at the moment through the whole company what are the problems but also what are the good things something must be working or the company wouldn’t be making any money or no one would be working there. Ask everyone what their thoughts are and try to build up good communication throughout the whole company. With that, it is easier to do with a flat hierarchy, I know this may be hard to accomplish or even impossible but communication is the key. Branch this out with your customer base as well it is important that your developers are within touching distance of your customers if that is a representative then so be it but you need to be honest about it and make sure it fits in with your company.
Once you have identified the problems and what is working well go through each one and identify why it doesn’t work or why it does. Be honest about it and make changes as needed know that not all the changes are going to work and make sure everyone knows that it is allowed to fail. I would recommend you stay away from using words like an experiment or try and just say we are going to do things this way and we will change anything if needed again it goes with being honest with what you are aiming to achieve. Don’t rush any changes take your time to implement them with the idea that they are going to succeed. Don’t change everything at once but also don’t leave it too long to change. Do a risk analysis and change what the whole team considers to be of the highest risk to what you are aiming to achieve and work down the list.
Empower the people, you do that by having good leaders within the team, people need to be given the tools to become empowered and self-organized and the leaders do that. Leaders are different from management, management is a cursed word and almost puts a barrier up between people you don’t need managers if you have excellent leaders. if you are being honest about everything then people will know if they are doing well or not and should be given the tools to constantly improve so there should be no need for a managerial role.
Make sure that you have an objective to aim for and make sure everyone knows about it also display it not on some website like confluence or on a road map as timings are not beneficial. Make it into a poster and stick it where everyone can see it so they are reminded of it but also be honest if it changes make a public display of taking it down and ripping it up as it shows that the company is not afraid of change as new information comes in. Do the same for your medium-term goal hopefully you are not ripping this poster up too often but the same principle applies. For any short term, plans make sure everybody is aware of the plan and everyone has contributed to it this again goes with communication and being honest.
Change takes time and could also delay certain deliverables as you get used to the new ways of working but because you have good open and honest communication the delay should be acceptable and explainable to all.
Being honest I can not give you all the answers as I do not know all the answers. I don’t know your context and what your specific problems are but I do find by stripping everything down to the basic level and fixing one thing at a time, then you are off to a good start. If that means saying the Agile manifesto is not quite working for us or Scrum isn’t solving our actual problems then that is not a problem don’t worry about that make the changes do what is needed and see what happens, learn from it then if needed change it again.
I hope this has explained my thoughts and why I believe by trying to be Agile could stop you from actually being agile if you have any thoughts or feedback please connect with me on LinkedIn or email me.