In the past few months I’ve spent a lot of time looking and analyzing the scrum process, gone through some formal training, talked to a couple of experts and come up with my own opinions. Some do show the weaknesses in scrum, and some may be just flat out disagreements with the scrum process.
All team members are not equal.
Scrum is built on the idea that all team members are passionate about the project, and respect each other. A cross functional team is a great idea where we can help each other out when appropriate. But that’s not always the case. The truth is I’m not a BA expert. Can I do it? Sure, but I’m significantly less efficient at those tasks than I am when I’m coding. Not everyone has experience doing QA. At my place of work, I don’t even have the tools installed on my machine for design. So there’s a role/specialization in development that says not all team members are equal, and they shouldn’t be!
Additionally, team members have different levels of dedication. A disgruntled, jaded employee is going to have a different level of dedication than the new guy looking to make an impact. Their goals at the company are different. Some want to ship software, some want to improve their skill, and some want to just collect a paycheck. The idea is to hire motivated employees, but let’s be real – you cannot keep everyone happy, motivated, and having the same goal.
Self-Organizing is great but…
Scrum is supposed to allow teams to self-organize. However, it treads a dangerous line in a lot of areas. It is our nature that when five people get together to work towards a goal, that someone acts in some sort of leadership role – even if it is an unofficial one. This is the self-organization. But that conflicts with the all team members are equal. By placing leadership on a team member, that’s no longer equality. Additionally, you tend to let people who are more aggressive and outspoken dominate the conversation, potentially not knowing about the project.For example, I once was working on a complex engine for an application that I worked on. Three developers huddled around the whiteboard and talked about potential issues that could come about. Two of us were working together, and making good progress. The third was not. The third developer was new to the organization and didn’t have knowledge of the business rules. However, because he had the type of personality to dominate the conversation it stopped progress. He should have been asking why instead of dictating. Fresh views are great, but the personality can be a problem.
Third Parties
I always seem to work on projects that have heavy third party integration. Any time you work with a third party, you inherit their headaches times ten. You cannot do anything about them, you can only prepare for them.For example, I had once developed a feature on an application based on insurance risks and rates. The rates would come from a third party. Before actual coding had started, the contracts were written and agreed upon. The third party told me that the service I would need to call would be available in three weeks. I had mocked up a service that I could control and develop against. Not the most efficient way of developing, but it works. Once I finished up my side of the development, I really needed to test with the third party, who was now multiple weeks late. Like any waterfall project, when one module is late, it pushes the next module to be late. This delayed the release. Eventually they finished with a completely different contract that we agreed upon. You can try to protect yourself from third parties, but I find that they always find a way to disrupt your schedule.
Bugs have no real plan
Scrum seems to be ideal for a new project that is starting from scratch. You don’t have to worry about legacy code, being pulled into other projects, or bugs. Let’s face it – every developer who isn’t Larry Gasik has bugs in their code. I have yet to see anyone implement a smooth plan allowing for when things come up. I’ve seen different approaches to handling bugs, and I don’t like any of them. Reduced capacity makes planning look bad and encourages lazy developers. Swapping stories in a sprint destroys morale and timelines.Shared Resources
Smaller organizations allow people to wear multiple hats. This can be both beneficial and detrimental. In large organizations there are almost always too many hats. This is a major problem. Depending on the project, a scrum team may not need a full time DBA, a UX expert, a front end coder, etc. These types of resources then get shared among the organization. When this happens, you’re adding another hurdle for the development team to complete their job. This goes back to a scrum team relying upon third parties. When these things happen, your projections can change based on that third party. When that third party has their own sprint or schedule, it becomes difficult to interact with them and get things done in a timely fashion.Scrum is great but…
It is a framework. It is not intended to be followed by the book. Modify it to be what works for your needs. I’ve never had a full time product owner. I feel like I’m going to find a unicorn before I locate a full time product owner. On a project with only three people, I’ve had to be the scrum master and developer, and when that happened, it was more successful than just complaining.Too often I am seeing scrum being hailed as a silver bullet, and that any time scrum isn’t working for a project, it is because the process isn’t being followed. The scrum framework is built upon ideals when in reality you may not have the set up that scrum thrives in.
