Today, agile software development is applied to the most of the projects and in case your team hasn’t used agile process frameworks yet, be ready that one day your client will come to you with an inspired expression on his face and say: “We must use agile!” And, for some reason, by “agile” most of the clients mean Scrum, so first it makes sense to read Agile Manifesto and its 12 principles and then proceed to learn Scrum basics.
However, after reading or even memorizing the Scrum guide you will not be able to apply it efficiently immediately. The Scrum guide is some kind of description of Scrum framework shortened as much as possible where every sentence is important and cannot be taken out. It makes sense to read additional books, articles, attend webinars or live trainings in order to apply Scrum effectively. Indeed, as it’s written in the Scrum guide, it’s easy to understand but difficult to master.
Unfortunately, I saw a lot of cases when Scrum was not applied fully or a Scrum team didn’t have all roles or artifacts. In the worst cases, the Scrum team simply conducted daily meetings and assumed they used Scrum. For sure, as I mentioned above, the Scrum guide doesn’t have optional components and if you apply Scrum partially, add extra roles or for example, describe artifacts in another way than it’s described in the Scrum guide it will not be Scrum and definitely, it may affect your effectivity. The Scrum guide gives you the very minimum that should be respected, it’s up to your team and your environment how to apply it but the key elements of Scrum should not be changed.
In this article, I will not explain Scrum theory in details but will try to describe what may happen if you ignore some of the Scrum roles, artifacts or events. I will also try to give some advice for difficult situations which most of the teams face in their Scrum projects.
Roles
It’s always important for the Scrum team to understand responsibilities and restrictions of the roles in Scrum. It leads to many organizational and functional troubles when either the roles are only formally defined or if some role acts with more rights than it’s defined in the Scrum guide.
In case the Scrum master is missing or ignoring his responsibilities team members may not understand the reason why Scrum events are important, roadblocks will often remain unsolved and the whole process becomes ineffective. Indeed, the Scrum master is one of the key people for the team to apply Scrum properly who ensures that the process goes in the right way. It’s the first person who should react when the Scrum team has problems but at the same time it’s not a typical manager.
The Scrum master should not tell the Development team what to do but should wisely help them to outline their work according to Scrum concepts. Sometimes, it happens that a client acts as a Product Owner on a project and he would like to limit or omit Scrum events. The reason why a lot of clients think this way is that when they calculate the time needed for the Scrum events it appears that this number becomes really huge converting to money:
i.e. 2 weeks sprint for a team of 5 developers includes up to 50 man-hours of communication related to the Scrum events:
(10 days * 15 minutes of the Daily Scrum + 4 hours of the Sprint Planning + 2 hours of the Sprint Review + 1.5 hours of the Sprint Retrospective) * 5 developers.
The Scrum master should carefully explain the meaning of all scrum events and other components so that everyone can understand their importance and impact of excluding some of them. Normally, the more Scrum components are excluded, the less productive the Scrum team becomes which leads to higher expenses. Choose a Scrum master of the team carefully, it should be a proactive person with a strong knowledge of Scrum concepts so that he can react quickly in case of any impediment but on the other hand, he should be a patient and tactful person who will work with the Product Owner and other team members to coach them and explain them Scrum concepts.
Another important role in the Scrum team is the Product Owner. Since in most cases the Product Owner is a client himself or someone on the client side it appears that the team often doesn’t have enough of the Product Owner’s attention: clients are usually busy and they may not have time to explain user stories in details, attend events or groom the Product Backlog.
The most critical outcome of such a behavior is that the team can’t effectively move forward with the development, the value that the team produces is not optimized due to insufficient details of user stories. The team tries to fill the gaps based on their guess which may be too far from business requirements or users’ needs. Incomplete information about the goals and requirements will drive the team in a wrong way during the sprint which will again result in incorrect estimates, high expenses, and different expectations. When the Product Owner and the Development team are not on the same page in terms of expected results it may also lead to conflicts after the work is done, especially if the Product Owner blames the team when the problem is discovered.
In case the Scrum master sees that such things may happen he should help the Product Owner by explaining that the time spent with the team results in the maximized value of the development. It also makes sense if the Scrum master spends some time with the Product Owner and helps him to order the Product backlog, write a few user stories, monitor how the Product Owner communicates with the team. Sometimes the Product Owner may start to control every step that the team does. In this case, the Scrum master should explain the Product Owner about constraints of his role and this may be a bit hard in case the Product Owner is your client who pays for development.
The Scrum Master should focus on the fact that these constraints were added keeping in mind that the team is mature and should have some freedom in taking technical decisions. The development team is self-organized so the team members decide how to turn product backlog items into an increment and that makes their work more effective. For sure, the development team should share their plan with the Product Owner so the Product Owner can advise regarding future opportunities keeping his business plan and budget in mind. In the worst-case scenario, if the Product Owner is too busy to spend enough time with the team it makes sense to allocate an additional person who has all the business knowledge about the product. This person will become the new Product Owner but you need to make sure that the client and all the stakeholders respect decisions of this person.
Events
Every Sprint starts with the Sprint planning and sometimes the team wants to save time and ignores this event thinking that they can just pick up the first N items from the product backlog based on their velocity and the Product Owner can approve them. It may actually work for certain teams and the teams which choose this way are usually located in different time zones with their Product Owners. This may work until they face the first problem with synchronization: when the team chooses this way they will not have a possibility to discuss the Sprint Goal, ask additional questions regarding business requirements to choose a proper way of implementing them and make sure they are on the same page with their Product Owner regarding the expected increment.
Sometimes if the Product Owner is a technical person he may even decide for the Development team which Product Backlog items should be done during the Sprint. It often leads to incorrect estimates, great rush on the project and accumulation of a technical debt. The Scrum Master should explain the importance of conducting the Sprint Planning, should guide the team about the techniques which they may use to conduct it in a more effective way (i.e. Planning Poker) and should help attendees to prepare for this event: The Product Owner should update the product backlog and prioritize its items, the Development team should spend some time on new product backlog items, think of some questions which will be asked during the Sprint planning, recall their previous estimates and past performance. At the end of the planning, it makes sense to double check that all are on the same page in terms of expected results and the project goal. It’s good if you store the sprint goal and other notes in some shared place like Confluence so you can get back to it later.
Daily Scrum
The next important event is the famous Daily Scrum. Many developers ask their Scrum Masters why do they need to spend 15 minutes of their morning time on this, at first sight, useless routine. Such thoughts usually come into mind to people who conduct their Daily Scrum remotely sitting at their working places so they can code, read the news or even speak with someone else in parallel. That’s why it makes sense to conduct the Daily Scrum in a meeting room preferably in a standup mode. The Daily Scrum is a good opportunity for the team members to discover issues and inspect their progress. For sure if someone has a blocking problem he may not wait till the next Daily Scrum but will rise it immediately. Meanwhile, if someone is working on an issue and reports it during the Daily Scrum, then someone else who met this issue before may react and save a lot of time.
Besides, the Daily Scrum helps to reduce the number of unpleasant surprises when a team works without daily meetings and after a week they discover that some members moved totally in a wrong direction. Also, in my opinion, daily meetings at the same time in the morning keep some discipline: you need to be on time for the meeting, you need to structure your thoughts for a small report and you need to contribute today, so tomorrow you can report something significant to the team to show that your work helps to move closer to the Sprint goal. Sometimes people forget about the 15 minutes’ time-box and start discussing very specific questions. In this case, a Scrum master should step in and explain that participants only report the issues and then each can discuss them specifically with required persons after the Daily Scrum. Also, if people frequently forget this, you may conduct your daily meeting standing on one leg.
Sprint Review & Sprint Retrospective
The next two events which teams usually omit are Sprint Review and Sprint Retrospective. Sprint Reviews are normally respected by the Product Owners because they like to see results of a sprint but they focus too much on the demo. In this case, such meetings are usually conducted as a presentation of the developers who worked on front-end, while the back-end developers modestly sit in the back because their presentation of a refactored code for API may not look really captivating so their speech during such meetings is quite limited. But the Sprint Review is not only about the demo. It’s a good chance to discuss feedbacks about your software from users (i.e. review reasonable comments from app stores), review new updates of software from your competitors comparing to your progress, get valuable market insights from the Product Owner and discuss some ideas which may be a good input for an upcoming Sprint. If you miss the Sprint Review, your team will also miss a good opportunity to hear that you are moving in the right direction which is so important to keep the team motivated.
The Sprint Retrospective comes after the Sprint Review and some Product Owners ask to make one meeting combining both events. The Scrum team should understand the purpose of each event so that they may come one after another but should not intersect. Sometimes the Sprint Retrospective is omitted during some Sprints. This is also not a good practice because it’s an event where the team can give an honest feedback about what they do not like regarding the process, project, or even behavior of some teammates. Sometimes developers act like introverts, they keep such feedbacks inside and just accumulate their irritation. If you conduct the Sprint Retrospective once in 6 months some of them may not wait for this event and will just leave. Also, if you conduct the sprint retrospective every sprint it takes less and less time because most of the organizational issues get fixed after some time. If you manage to conduct your retrospectives timely, make sure you store their results, really work on improving the discussed points and spend some time on the issues which occur again. I recommend using common techniques for the Sprint Retrospectives such as The Mad Sad Glad, The StaStoKee, The Team Radar.
Artifacts
Normally missing artifacts relate to corresponding omitted events. Sometimes even if an event took place the team forgot to pay attention to the artifacts. That’s why we may have eternal items which will never emerge from the bottom of your Product Backlog. Also, some teams may miss certain artifacts completely. If the Product Backlog is missing the team works on a set of tasks composed by a Product Owner each sprint. In this case, only the Product Owner has some vision about the goal, the team does not have a possibility to understand future prospects and make planning and estimates keeping new features in mind. Also, the team members are very limited in terms of ideas generated from their side. The Scrum master should explain the Product Owner the importance of the Product Backlog refinement and benefits of keeping it up to date. That should be a continuous process for the development team too because the Product Owner may ask the team to revise the Product Backlog items together and add estimates.
The Sprint Backlog is rarely omitted but it’s often limited with what the Product Owner wrote in his User story description. The Scrum team should also convert the user stories into tasks, split them into subtasks if required because user stories usually contain only some brief business requirements, which are not enough for effective use by the development team. It also makes sense not to miss effective techniques for tracking the Sprint Backlog completion, i.e. burn down or burn up charts. I prefer using burn up charts because they have a rising trend line which is more associated with progress for me (but this is quite subjective).
It would seem that nothing can be more important than the Increment. This is what the whole team worked for during the whole sprint. But in case you don’t have or do not conduct your Sprint Review properly you may start worrying about your increment only before you actually need to release your product. Also, the increment may be missing in case the team didn’t meet the Sprint goal. Pay attention to keeping your Increment in a shippable state at the end of your sprint, as this is the indicator that your goal was met, that keeps the team motivated, helps you to release it to production in case you are interested in sustaining your marketing niche.
Definition of Done
The Definition of Done is usually implied but not defined by development teams. Normally, if an organization doesn’t have its own Definition of Done the team considers that it consists of development and some testing. But the Scrum team gets surprised when they discover that the Product Owner also wanted to have a brief documentation about new features, another team that worked on the project didn’t create a database schema which is really important for your team, and some developers didn’t add unit tests because they thought it would not be needed. The missing Definition of Done leads to lack of transparency and different expectations about what to consider as ready to be delivered. If your team already has the previously defined Definition of Done, make sure your Product Owner and all other team members share the same understanding of it. It makes sense to store the description of your Definition of Done in some shared place. For example, we use Confluence for that. We have some basic rules of the Definition of Done which are applicable to all the developers and additionally, our mobile, web front-end and back-end developers have specific points which are relevant for their platforms. The Definition of Done should be reviewed and updated along the development process to increase the quality of your product.
If you just started to use Scrum for your projects, you should not be afraid of difficulties. That could be a bit complicated at the beginning but after a while, your team becomes more familiar with it, which results in increased productivity. Increase the transparency, do the continuous inspection and adopt the process by learning from your mistakes. But always keep in mind that the biggest value of your organization is people. All process frameworks, methodologies, and tools become useless if you don’t invest in your teammates. Scrum implies that you have a self-organized team with a high technical level and synchronization. Make sure you pay attention to relationships, microclimate, professional growth, the motivation of your teammates to the same extent as you care about following a good agile process and your projects will be always successful.
