Hi there, welcome to part 2 of my blog series on the pros and cons of Agile Scrum, if you haven’t read part 1, you can view it here.

In my 2nd and final entry in this blog series, I will focus on the what I perceive to be the biggest cons of Agile Scrum. Also, as a caveat, the pros and cons should be viewed in the context that an organization has successfully implemented Agile Scrum. Some Agilists will tend to brush off any perceived criticism of Scrum and claim that it was not implemented correctly, so the assumption for this blog should be that you are in an organization that is Agile and Agile Scrum has been implemented correctly.

Lack of software development practices

I have been Agile for about 4 years and one negative of Agile Scrum is the lack of stated software development practices. Scrum implements key practices that produce good software such as team collaboration and faster iteration loops but it fails to give guidelines for good software development practices. Scrum offers no guidelines on how technical tasks can be shared among developers throughout a project to prevent knowledge hoarding . Unlike Agile XP, Scrum also fails to mention any methods on how developers can consistently improve the code base by refactoring code, testing and code reviews. When an organization has made the decision to implement Agile Scrum as their software development methodology, they may choose not to augment Scrum with widely used software development principles, such as the ones I just stated. The organization will be Agile but the lack of strong software development practices will result in a codebase that has more bugs and the team will spend a lot of wasted time fixing them.

One of my first clients was a healthcare company who had decided to implement Agile Scrum in their organization a little over a year before I had done work for them. I was at this client for a little over 2 years and they were very Agile. However, software practices such as testing, code reviews and knowledge transfer were optional. The team I was a member of didn’t write many unit tests, rarely did code reviews and we certainly didn’t do a lot knowledge transfer. When a developer started to gain significant knowledge of one part of the system, they typically were assigned any tasks related to that area of the application. What forced us to implement better software development practices was the software tended to be very buggy once we pushed the application to the testing environment. Also, as time progressed, people who had deep knowledge of important parts of the system started going on vacation and others would have to scramble to quickly get up to speed on areas of the system that they were unfamiliar with. To address these issues, our team decided to have code reviews every Friday, dedicated a huge portion of two sprints to re-factor the codebase so we could start writing more unit tests and started rotating tasks so everyone could become familiar with all areas of the application. With these changes, the entire team saw a drastic reduction in the number of bugs and the developers became more confident in making changes to the system because we had unit tests to support us and due to increased knowledge sharing through task rotation, the team had a better understanding of the entire application.

Ceremonial

One of the best qualities of Agile Scrum is that it does a good job of forcing the team to collaborate. Scrum accomplishes this by defining 4 official meetings: Daily Stand-ups, Sprint Planning, Sprint Reviews and Sprint Retrospectives. During these meetings, the team will be highly collaborative as they discuss issues, engage the product owner, demo the product and plan for future sprints. However, these meetings can become overwhelming and time consuming for team members who are responsible for delivering the product. From my experience, of all the official meetings Scrum defines, the daily stand-up is the meetings that organizations tends to obsess over, especially chickens. I think it is very important for the entire team to gain insight into what a person has been working on, what they are working on currently and if they have any roadblocks. However, I am not so certain that holding a daily stand-up has to occur everyday, especially on teams that are very collaborative and sit in the same room together. If a team consist of a very competent Scrum Master, the Sprint Burn-down or Burn-up chart should always be up to date, available to everyone and should serve as an instrument to gain insight into what every team member is working on and if there are any roadblocks.

Many of the Agile Scrum teams that I have been a member of have treated daily stand-ups as meetings that must take place at all costs, even if only one person is available to take part. At one organization in particular, I was working as a consultant and I was part of a team of five people. One day, it just so happened that the other four team members were either out of the country or had called in sick, so I was the only team member available for the daily scrum. Our Project Manager use to obsess over Agile Scrum meetings and she insisted that we do a daily stand-up, although I would be the only one to attend with her dialing in from home. I literally went to the front of an empty room and told myself what I did yesterday, what I would be doing today and that I didn’t have any roadblocks. On the project I am currently working on, I recently took a vacation day and when I returned the next day, I had about 4 emails where I was being asked to provide my daily scrum update on the day I took vacation. Some of the team members hadn’t been notified yet that I was going to be out of the office but the tone of the emails seemed to suggest that if even one daily scrum update is missed, the entire project is doomed.

Stand-ups tend become status meetings

The problem that I have encountered most with Agile Scrum is that the daily stand-ups tend to devolve into status meetings. Of all of the Agile teams I have worked with, daily stand-ups being used as a status meeting and a tool to put pressure on the team has been the rule and not the exception. From my experience, you have to have a very competent Scrum Master, Product Owner and a mature team to keep daily scrums time boxed and serve their intended purpose, which is to keep the team apprised of what is being worked on and if there are any roadblocks. When managers, VPs and executives attend daily scrums, it is very easy for team members to feel compelled to give a status report and feel pressure to go into detail about every single task they have completed or are currently working on. When daily scrums start to become status meetings and a mechanism to control the team through fear, the team can start to fracture because a meeting that is supposed to be very quick, has now become drawn out, stressful and a “cover your butt” situation. If the team is not mature enough, they will start to crack under the pressure of these types of daily stand-ups and try to one-up each other by going into too much detail about what they are working on to please the managers attending the meetings. From my experience, what eventually happens is that QA and the Developers will start to point fingers at each other and the overall team chemistry starts to suffer because it will become a “us” vs “them” situation.

On my very first Agile Scrum project, I remember the Director of a particular business unit would attend every daily scrum meeting. What everyone noticed is that whenever a team member would state that they had a roadblock, the Director would have a scowl on his face and give off an impression of great displeasure that the team member was not able to complete their task. Because it was my very first experience with Agile Scrum, if I had a roadblock, I tended to either downplay it in the daily stand-ups or I would not mention it during the meeting at all to avoid the perceived disappointment of the Director. Also, on another Agile Scrum project I was a member of, the daily stand-ups became such pressure cookers that the team members tended to throw each other under the bus and try to impress the managers and VPs that were in attendance by bragging about all they work they had completed the previous day. The team chemistry was so bad that the Project Manager ended having to call an emergency meeting where our entire team went into a room, hashed out all of our issues and had to agree to drop all grudges after the meeting was over.

That’s it for my blog series on what I feel are the biggest pros and cons of Agile Scrum. Agile Scrum is a great methodology for organizations to use to produce better software but like any methodology, it has its strengths and weaknesses.

Thanks for reading my blog and if you have an opinion, please feel free to share your thoughts on what you feel are some of the cons of Agile Scrum?