Here is an attempt to list down 25 common mistakes we do while implementing agile scrum in software engineering organizations. I believe if you happen to do one of these, it is a good time to re-evaluate it and make the necessary fixes.
Mistake #1: We are very agile because we perform all Scrum ceremonies
It is very like the saying “Visiting a church weekly won’t make you to religious”. The agile transformation could be a step by step process by adhering to the principles and not practices. Maybe you shall not carry out all steps of agile Scrum from Sprint#1, especially when most of the team members have never worked in an agile environment. It is advisable to start focusing on practices that adds value to the product. You shall focus more on bringing the agile culture within the team then start that specialize in practices. The points mentioned in the below sections will be covering this topic in detail.
Mistake #2: A huge scrum team
Very Few Organizations think that they need a large team to reach the sprint Goals. But when you have a large team it reduces the efficiency of the team. The first problem is that all of your scrum meetings will run so long or it may not add any impacts with a large unorganized team. On the contrary, an ideal Scrum team is a small (roughly 6-7) and dedicated team working closely to meet the goals while keeping itself organized. It will be a good idea to keep it as a multi-functional team considering the test-driven approach in mind.
Mistake #3: The team members are not co-located / Remote scrum teams
This is a very interesting aspect at this time when I prepare this list where organizations are encouraging remote work worldwide. But I strongly believe that the team members (developers, designers, testers & scrum master) need to sit together in the nearby locations so that you can enhance the interactions within. The next point we are going to discuss is very related to this aspect.
Mistake #4: Pay more attention to email and reduce face-to-face communication
Imagine if your team members are sitting with each other in the next desks, but they communicate only over email or instant chat applications. If so, please do not entertain. Maybe the team shall agree on an email ban to encourage F2F conversations. F2F conversation creates relations & trust which is most needed for a strong agile team. The time I write this article is very unusual due to the covid-19 pandemic and every one of us is working from home. Here is a good article about structuring an agile remote team & how we shall enable the trust and togetherness by implementing the right communication channels.
Mistake #5: We do not encourage out of office relations
As a scrum team, you can create some fun events outside the office and shall not bring any work-related topics for the discussions, but just team-building events, Pick the most newbie to the team to organize this event where you are team can build relationships and trust. From my personal experience, I have noticed that this reduces conflicts with-in the team. There could be another option as well, Maybe you can conduct Knowledge transfer runways over a pizza in case if there is no chance for an out of office event.
Mistake #6: The Scrum Master is responsible for everything
Usually, I have noticed that the scrum master takes too many responsibilities. The scrum master usually needs to act as a coach without bottlenecking. He shall be an advocate of self-organization within the team. An example, When a scrum team found a blocker during the stand-up, maybe scrum master can assign it to one of the team members. While assigning a blocker always keep an eye on it. This will help the team to grow to the autonomous mode at a fast pace.
Mistake #7: Expecting the Scrum Master to be the Project Manager/ Team Leader
The most common mistake made in Agile is assuming that a Scrum Master is the same as a project manager or a lead developer and this is incorrect. His role is to coach as well as facilitate his team and not manage the team. He shall offer guidance and advice to his team as well as the product owner on matters regarding the scrum framework and he acts as a facilitator in the organization. The scrum master needs to ensure that the team meets the sprint goals, no other focus shifting tasks has been added to the team and the team always have a very high focus factor. This is where the Scrum Master makes a mistake. He is acting as a Manager, not as a Scrum Master.
Mistake #8: Documentation is not required in Scrum
One of the statements in the agile manifesto creates this confusion. It emphasizes working Software than its documentation. This does not mean that you shall not document your software. You always need to do it and it shall be a part of the Definition of done for any agile user story by default. In models like waterfall, the level/depth of documentation was too high, and sometimes it was not adding any business value. Agile emphasizes that first, you need to have a working software, then only the good documentation adds business value. For instance, your architecture and source code, you can decide what kind of UML diagrams you will include to document your architecture and so on, that is the flexibility agile offers. The bottom line here is that only document when there is a business value attached.
Mistake #9: The dictator scrum master
This is another aspect of a mistake we discussed earlier. This mentality could be an outcome of a traditional project manager’s behavior. The most effective scrum master is a good guide, facilitator, and servant leader. during the agile transformation, In some organizations, Scrum Masters are hired to the team based on their experience, and in general, the Senior domain experts and project leads will be taken into the account to this role. This shall create unwanted dependency on scrum master where the team is always waiting for the scrum master to make even a small decision, which is against the principles of a self-organized scrum team, thus sometimes the scrum master becomes a dictator. There is a big chance that this behavior will make the team members leave the project. This is very applicable in the case of the product owner as well.
Mistake #10: Product owner does not participate in the processes / Proxy Product Owner
In a few multinational organizations, the product owner is usually located in a business office near to the customer location, where the scrum team is in an offshore office. Sometime, there could be a proxy product owner to serve the purpose, but this is an anti-agile pattern. The product owner’s presence and availability for any scrum team are mandatory. He shall be easily accessible to the development team for a face to face meetings. The product owner must be present in the refinement meeting, He shall clearly explain the goal of the sprint during the sprint planning meeting which brings the confidence to any agile scrum team. The product owner represents the customer and collaboration with the development team is always required.
Mistake #11: Lack of Retrospective Meetings
Agile transformation is not the best solution for all of your problems, but rather is exposes the problem. Agile Scrum is all about improving ourselves by making mistakes and correcting them over time. But we shall not allow it to happen again. Scrum Retrospective meeting is one of the most important meetings for an agile team where it reflects the team’s feelings about their journey. The Scrum master shall facilitate the retrospective and encourage the team members to speak up what is good/bad/needs improvement. The outcome of any retrospective meeting shall be a list of action items that need to be delegated within the team and resolve it. The list needs to be monitored and closed timely.
Mistake #12: Scrum Master holds sole responsibility for the delivery
This is very close to what we discussed earlier which is the command and control mistake. In the non-agile companies, the project manager is responsible for the delivery and he acts as a single point of contact for project tasks, and when they are hired as scrum master this mistake occurs. On the other hand, Scrum Master shall ensure that the project team is enabled for quality delivery and they have all the tools in hand. The scrum master shall need to do the planning together with the team, making it a collective effort so that the team will adhere to their commitments.
Mistake #13: Scrum Master as a mediator between the Team and the Product Owner
As an example, if a developer has some questions about a user story, instead of directly going to the product owner, he reaches out to scrum master and scrum master further discuss with the product owner to get the answer to it by acting as a proxy fellow. In a true agile scrum team, the product owner must be accessible to the development team directly for any clarifications. The scrum master shall coach the team to enable this level of communication.
Mistake #14: Not removing obstacles at an initial stage
The daily standups are the best way to share the blockers to get any task done. If the development team is seeing a potential blocker for the future, it shall be communicated at the same time, so that scrum master can take necessary measurements. For example, if the development team is seeing a design issue while implementing a task that could create a performance bug, The issue must be immediately informed.
Mistake #15: Long daily stand-up meetings with technical discussions
There are situations that the team has a tendency to talk more about the technical aspects of the task they are working in, and it loses the essence of the daily stand-up. The scrum master can park those critical technical discussions in a slot after the stand-up. The scrum master can ensure that all the team members are available in the stand-up and the team is sticking with the right expectations like “what I have done yesterday “, “what is my plan for today, and do I have any blocker”.
Mistake #16: Incomplete Product Backlog
There is a huge tendency for the product owner to work on the product backlog for the next sprint one day before the refinement/sprint planning. This can create problems because while righting a user story you may have missed a few key points so that during the development the team needs to waste the time in clarifying it. Each of the user stories in a sprint backlog must be accepted by a Definition of ready, It is always recommended to use the INVEST principles while preparing a user story (https://agileforall.com/new-to-agile-invest-in-good-user-stories/). The product owner needs to prepare a healthy backlog at least two sprints in advance so that he can utilize the sprint refinement well / may be updated/split the stories accordingly.
Mistake #17: Scope change during Sprint
This is truly anti-agile, but happens most of the time, especially when you are in the Bug fixing phase. The product manager needs a feature all of the sudden and the product owner cannot say No to it, thus it continues happening. This may result in losing the motivation for any team by holding whatever work they are doing, or they may need to spend additional time in office. The product owner must be empowered to say no and agree on a plan with the stakeholder to make sure that the sprint is not impacted by a scope change.
Mistake #18: No code reviews or no pair programming.
The Agile Scrum is self-organized and they usually have more ownership of the artifacts they prepare. I had a teammate who was with an opinion that I own my code and I am responsible for it and I do not need anyone to review the code. This is truly a bad idea. There are two aspects of the code review, in the first place you are getting a second opinion to the code you have written, secondly, your teammate is also understanding a feature so that he can take over some fixes in the future. Secondly, the pair programming is a great tool when you have a newbie or junior working in the team. The scrum master shall encourage the teams to do more pair programming. The pair programming is a continuous knowledge transfer as well within the team.
Mistake #19: The Daily stand-up meeting is not a status meeting
Usually, in the non-agile world, the team has been working in a mode where they are answerable either to their manager or the lead for their work and there is a huge tendency to continue it even in the agile scrum. The daily standup is not a status meeting, But you are sharing the updates to the entire team, not to the scrum master. The team members can also help each other in resolving the impediments where the scrum master ensures that it is properly resolved.
Mistake #20: No / Part-time Scrum master
The Agile organization must consist of a scrum master, product owner, and the development team, and each of them plays a different role in the game. In some cases, I have observed that one of the team members play a dual role: For instance, the Product Owner is a part-time scrum master and is a bad idea. The scrum master is the coach and he has mandatory responsibilities within an agile organization and it is always advisable to have a dedicated scrum master for a team.
Mistake #21: No follow-ups for the items came out of retrospective
This point was partially covered above. The retrospective is the most important ceremony in the scrum to ensure that we are improving over the sprints. The points coming up from retrospective can be ranked by voting and it needs to be documented as an action items list with corresponding owners. This list needs to be constantly monitored and ensure that the necessary actions are taken. If not, the same issues will happen again in the future and we will never learn from the mistakes.
Mistake #22: We do not have a DOD / DOR for user stories
When we work on a scrum team, The members will be off with different experience levels in most of the cases. If you do not have a DOD, for instance, The estimation of the user story each one of them will estimate based on their own definition of done and it creates problems while delivering the feature. For example, as a product owner, you need to ensure that the story is properly tested before it goes to the next phase. This can be done by adding a list of items as DOD in the user story where you are setting the expectations to the team. The DOR stands for Definition of Ready, This is the responsibility of the team that a user story is ready to refine, where you have all the information needed to estimate the effort. The DOD and DOR minimize the risk for any products you are developing.
Mistake #23: Delivering feature without testing
The ideal scrum team is a multi-functional team where you can have test engineers also involved. I have observed that in some organizations the testing is done by a different department. The development scrum team will focus on implementing the feature that maybe with some unit tests and it is ready for demos. The maturity of the feature suffers in this case. When the particular feature goes to a testing team, later on, there could be a chance for integration issues and it fails even the primitive test cases. It is always advisable to keep the testing part in the DOD and a testing column must be there in the sprint board so that after the implementation the feature will go for quick sanity & smoke test based on the need.
Mistake #24: Product Owners who owns multiple products.
The product owners are responsible for multiple products that do not have focus as they need to continuously switch between products. They may not be available for the development team in some cases.
Mistake #25: Zero Automation testing / No Continuous integration
When you work on large projects it is a good idea to start spending time in automating the test cases to save a lot of time in bug fixing in the future. I have seen that when someone fixes a bug it creates plenty of other bugs and it may get revealed during the critical phase of delivery. Similarly, Continuous integration is also an excellent choice to ensure the integrity of the whole system. The Automation & CI will help any agile team to save a lot of time and ensure to deliver high-quality software.
I hope these tips were useful to you! Thanks for reading!
I have authored this article in Linkedin , URL to it follows : https://www.linkedin.com/pulse/25-common-agile-scrum-mistakes-during-transformation-gokul-kartha/