I have used Scrum in more than 6 projects, some are over 13 months long and others could be as short as a few weeks. I even have the Scrum Mater certificate from Scrum.org, so the concept is not new to me. People always talk about a project from a business or a Product Owner's point of view, here I want to bring a new perspective and talk about some of the issues I have experienced as a developer.

All about the product and NOT the project

I think that people need to focus on the product, and not the work itself. Waterfall development methodology is all about the project, the goal is to produce something that is closest to the requirement spec as possible. Once the project is finished then that is it, the team built it is no longer responsible for the product. On the other hand, agile development focuses on the product. The development team must care about the product, suggesting ways to improve it over time. A good development team will fix issues that are not captured in the business requirement, they will also actively find and report issues about the product.

Less can be more

A team consists of fewer people might have a clearer focus and can self-manage much better than a bigger team. I have worked on a project where the two of us managed to rewrite the front end of a web application is a few days. For a different project, the team of around 5 developers achieved almost nothing for weeks. Skills and experience obviously come into play here, but I think the desire to do something and do it well is also a big factor. With a smaller team, it is much easier for the developers to come to the same understanding than a big team.

More isn't always more

A development team is always better to be kept consistent, adding or removing people is going to impact the velocity, always! Just because the burndown chart shows the team is working just as well, the code quality and the overall maintainability of the product will say otherwise. It is a common problem to have a set deadline for projects, this means rather than pushing back deadline business will decide to increase the team's size to increase velocity. But business doesn't understand that if a team isn't delivering enough, allocating 5 more developers is not going to help. If anything, changing the team is going to decrease velocity due to the extra training time spent bringing the new joiners up-to-speed. Sure, it might be a velocity increase a few months down the line but it can't be used to fix a short term goal.

Code quality

When working in a team of 3 - 15 people, it is hard to make sure everyone has the right skills, experience and same ways of working. This is one of the problems I have seen with some of the teams I have been in. As a developer, when there are one or more people producing crappy code, it drags down the quality of the product overall. It introduces bugs, makes the product more difficult to maintain and just simply makes developing the product less enjoyable. Nobody enjoys working on a product that they don't like.

Good Product Owner and a good backlog

A good product owner (PO) is someone who is always accessible to the team, he/she should be there to answers questions as they come up. Waiting till the next day is a sign that the PO should spend more time with the development team. The PO should be actively shouldering any blames made to the product, as he/she is the sole person responsible for the product. In order to avoid blades, the PO should clearly understand the business requirements and break them down into tasks and user stories. This leads on to my next point, PO is also responsible for creating the product backlog.

All future changes must be captured and stored in the backlog, tasks and user stories should be clear to the development team. It sounds straightforward, but the backlog needs to be managed, maintained and updated just like the product's code base. This is always something that is missed and causes dragged out arguments in planning or refinement sessions.

Testing or no testing?

A good development team will always have automated testing, this includes unit, integration and end-to-end tests. The team should find a balance between the different type of tests, and focus on writing the least number of quality tests as possible. In a recent project, we have gone overboard with regression tests, not only the tests takes hours to run locally but also means write tests takes 2/3 of the total development time. I can say for sure that is a terrible place to be, so definitely try to avoid the mistakes we had made.

Why Scrum, why not Kanban?

I personally prefer Kanban over Scrum, because Scrum has all these scrum ceremonies to follow whereas Kanban is extremely simple. With Scrum, new teams often miss important points and use it wrongly, and for a more experienced team, it is easy to forget about the big picture and get caught up in scrum ceremonies like Sprint Retrospective. It is extremely difficult to find a good balance, and all the ceremonies could become a distraction for the team and take away the more important focus on the product they are trying to build. I am certainly not the expert in this field, but I think for a new development team picking up Scrum or Kanban will take the same amount of time. With Kanban, there's a much clearer focus on the product.