So I have been thinking about this for a while now. I have worked at multiple companies that have changed to Scrum agile process. They have had their ups and downs but in the end I think they all failed in the real reason to do agile. Scrum was first originally defined as “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal.” Everywhere I have worked flexible and holistic wasn’t part of any of it. Below I am going to outline 5 ways it is done wrong and some ways it could be fixed. In the end, the real goal of delivering better software to the client.
It’s implemented with an iron hammer
All too often things are forced onto us at work. It is human nature to resist that change. Sometimes it is needed like in the case of policies to protect the company, it’s assets, and people in them. But when it comes to a process that helps teams get stuff done better, forcing it on anyone is never going to get the results you want. Scrum forces you to have cross functional teams as well as time-boxed iterations. Jumping straight to this from waterfall is a huge leap.
The easy way to fix this would be to switch to a much less strict process. Let the changes happen slower and by the team’s own guided effort. If you made the mistake of already doing the opposite then start from this point, it is never too late to fix it. Ask how well it is working, what isn’t working, and for any ideas on how to fix it.
You actually have a meeting like this in Scrum called the Retrospective but so many companies don’t allow changes to process in these meetings or don’t do them at all. Start doing them and feel free to do things like remove iterations and just use a simple Kanban board. The trick is to do it the kaizen (change for better) way and to do it in small steps so you get real and useful changes from the Retrospective.
Too much emphasis on getting it right
All too often when new teams start using Scrum they are focused on am I doing this right. This goes for 10 year scrum teams as well with statements like you are not doing it right. This is just like programming; there isn’t just one right way to do agile programming. Scrum is just one process that borrowed many of it’s ideas from other methodologies before it’s time. What was right even 6 months ago might not be now for your team.
This line of thinking comes back to the way we were taught in school. In school there was a right answer and the wrong answer. If you do it wrong you failed and failing is bad. But that isn’t true, failing is how we learn as humans. You didn’t learn to ride a bike without falling. You didn’t learn to read without making mistakes. A funny thing happens once you accept failure as learning; you learn that the faster you fail the more successful you become.
“I failed in some subjects in exam, but my friend passed in all. Now he is an engineer in Microsoft and I am the owner of Microsoft.” – Bill Gates
So feel free to fail but be willing to admit it and be willing to adjust things to work better next time or change the whole thing to work better. Also keep in mind just because another team was successful with doing it that way doesn’t mean you will be as well.
All teams have to do it the same way
I have never understood why companies think one way is best for all teams. Especially in companies that have more than one product. It is like upper management gets gold stars when they can tell the CEO we all do the same thing like sheep. Not all teams have the same goal. Many times products are built differently and are in different life cycles. A new product spends less time or no time on bugs in production but a 10 year old product with a bunch of technical debit might spend 50% or more time on bugs in production. One team might have many unit tests, integration tests, and does full continuous delivery and another team’s code wasn’t written to be easily tested at all.
My point here is you need to push back on this notation that every product and team has to deliver it in the same way. Scrum can work great for some scenarios and some just end up being mini waterfalls. I do understand that means management and the tooling might be different between the teams. This is ok, the money you save from only having one training and one tool verses possibly a few different ones isn’t worth forcing everything to be done the same way. Time is always far more valuable than money and most of the time you can find free open source tools to do what you need anyway. Focus on the pain points not on doing it the same way.
Scrum is the only planning
I see this all the time. Scrum focuses a bunch on the process and not as much on the technical side. So many times dev managers and project managers are more focused on getting people working than planning. Lots of times items are pulled into the next scrum though not all the requirements are there and you spend time in the planning meeting on requirements when they could have been done beforehand with less people.
You might also have grooming meetings to assign effort to items in the backlog to help the product manager decide what to work on next and requirements. This is great but the backlog shouldn’t be the only planning tool used. You need to take that data out and map it to overtime charts based on average effort per week/sprint in the past to get an idea. Only then can you make an educated guess on either when something will be live or how long it will take to get everything you want in.
Once you have the correct data you have two choices:
- Set a release date and whatever gets done gets released on that day. You can give an idea of what might be in the release but you can’t guarantee all the items that will be in it.
- You can set the list of items to release next (The smaller the better) and not set a date. Again you can estimate a date but you can’t guarantee the date.
If you don’t do one of these two things you are going to run into the same issues you had with waterfall and more than likely the quality of the product is going to suffer the most. You also run the risk of burning out the team.
The whole company doesn’t buy off on it
This is the biggest issue I see. I don’t know how many times I have heard, “oh yes management is ok with this,” but then when we say, “no, we can’t fix that issues ASAP but we can put it in the next sprint.” Or we say, “yes, we can fix that but we need to pull this item out of the sprint.” Then they freak out or even worse is middle management caves in and says yes and we just end up with too much in the sprint and not fully testing it or extending the sprint.
This actually goes for customers as well. They need to know we are delivering things in the correct tested and ready to go live way but so many times we drop everything to fix one issue for a client. Yes they are happy but then they will always expect that and even worse it breaks code somewhere else because we rushed it.
I understand those customers pay the bills and this make CEO’s and upper management happy. The issue is that CEO’s and upper management are not understanding the trade offs. If it isn’t correctly done and tested that debit adds up and eventually you have a system the cost to much to add new features too. If you have this issue maybe Scrum isn’t the correct method for your team. There are many other agile ways to handle this style of management and to produce a good product.
Kanban is a perfect example. You put all tasks on just a board. You can only have a few items at any step at anytime. This forces stuff like pair programming and QA and developers working together to get items done faster. Now when the CEO asks to get something in or you find a bug in production it gets added to the top of the list and is the next item that gets worked on. No need to have a formal planned iteration on what we are working on this next two weeks. Just a board of what we are working on now, what is next, and what is done and ready to be released.
In Conclusion
In conclusion if any of these are happening at your company maybe the company would benefit from a different process. Kanban can be a great place to start but it is in no way always the right choice. In the end it isn’t about putting things in iterations, having a bunch of meetings, or forcing every team to do it the same way. It is about adjusting the process and finding the best process to deliver the best software with more reliable to the client for you and your company.