Scrum Practices in Software Development Teams

​The first question teams must understand is why we use Scrum in the first place and what objectives we want to achieve. I don't know your answer, but for me, the key idea why the founder introduce Scrum and what Scrum is trying to achieve - is to minimize waste - waste of resources, waste of time. There are many tasks introduce waste in a software development team throughout the software development life cycle, especially with traditional waterfall or teams trying to practice Scrum. Scrum practices is to minimize waste.

 

​I believe many teams are working out Scrum by introducing some artifacts of Scrum. Some teams have Sprint cycle introduced and believe it is Scrum. Some teams believes they are doing Scrum by having every meeting that Scrum is asking for, naming the planning, retrospective, review and daily stand-up during their Sprint cycle. Before I start learning Scrum, a QA lead in Foxit US, who has 20+ years of experience and joined several Scrum teams in the past in different companies, shared with me:

​"it really is very efficient but the whole team has to be fully onboard with using this process. no halfway. if you try to mix agile and traditional waterfall-type of methodology, it doesn't work".

​This is the same I read from the book about Scrum - that if you try to take only some specific practice out of Scrum and work out your own way, it won't work. In fact, if you spend 10 min. to scan through the Scrum Guide, you may be able to find what are missing in your Scrum team and how the team can improve if the team is start asking "why we are taking lengthy meetings? why we have so many incomplete stories in the Sprint? why seems something not right in Scrum?"

 

I believe some, if not many, Scrum teams in many software companies are missing the following key roles.

​Scrum Master
Someone can read through the Scrum Guide and become the Scrum Master. Yet another may read through one or few books on Scrum and become the Scrum Master. I have read several articles online when their software companies are recruiting Scrum Masters getting candidates claim to be Scrum Masters after going through some Scrum Master certifications. They answer interview questions as written in books but unable to provide practical solutions when being asked for different situations that commonly faced by teams who are practicing Scrum. This also happens in the case when an organization is receiving Scrum training with trainers are learning Scrum more on the theory side than practical side.

Personally, I believe Scrum Master must have rich software development project management experience and understand the reasons behind why each Scrum Practice introduced, what problems it is trying to solve and what objectives it is trying to achieve - not just Scrum itself but every artifact it introduces. For me, this role is so important that it decides the fact that if Scrum is practicing as it suppose to be in teams. No matter what happens, the Scrum Master could understand the reason, can find the solution(s) with the team and make it right.

You can find the responsibilities of Scrum Master from the Scrum Guide but, for me, the key responsibility of Scrum Master is to promote and enforce Scrum practices from the beginning and throughout the software project. It sounds simple and one may believe he is doing the right thing - but again, are you helping the team minimizing waste effectively? Are "workable" software being created? Are the objectives of the Scrum meetings achieved?  

Scrum Master is NOT the project lead, which sounds like a project owner of the whole team. Scrum Master is NOT software development team lead. Scrum Master is NOT the Director nor Architect. By saying so, I mean a Scrum Master can co-exists with Project Lead, Software Development Team Lead, Director or Architect in the team and has no conflicts of responsibilities.

On the other hand, if any one in the team has the ability to be a Scrum Master (someone who understand Scrum in practice and not by theory), he could serve more than one role in the team. So, a Project Lead can be both a Project Lead and the Scrum Master. A developer can be both a developer and Scrum Master.

While I believe there are other reasons why an independent role Scrum Master is necessary, one reason is that a Scrum Master can participate in more than one projects at the same time.

Product Owner
This role is obvious and is sometimes referred as Product Manager in some companies. He is responsible to deliver the software project deliverable as a product. I saw teams having a Product Owner but who doesn't understand Scrum (possibly an issue of missing a proper Scrum Master). In this case, it makes no different with a team missing a Product Owner. If a team is missing a Product Owner, this can be an issue. 

No matter a team has a Product Owner or not, there is a few key points that Scrum promotes that the Product Owner should adapt:

1. Each Sprint must deliver a workable product. While one can apply Scrum in any industry, I am talking specifically on software industry. And for software, delivering a workable software in each Sprint is feasible in most, if not all, cases, One can easily say, "no, no, no, it is not possible in our project", but keep reading the rest of this page if you're going to say this again.
   
   This simple and key aspect of Scrum that requires delivering workable software in each Sprint creates a challenge to Product Owner especially who doesn't have technical background knowing what product features we can deliver first and which stories can be completes in one Sprint due to its time constraint, In that case, Product Owner must work closely with the Development Team member(s) while keeping in mind not to introduce waste (wasting to have too much resources working with you to educate and estimate/prioritizing tasks for Product Owner).
   
   
2. Each Sprint must deliver a workable product and is usable by end user. The reason why Scrum promotes delivering a workable software is to have the software to reach its intended users as soon as possible. For workable software, a software engineer may argue that completing a specific function in a software portion of a large module of an enterprise software is also a workable software. I won't argue that and it may be valid in some projects. But from the point of view of a Product Owner (not a software architect or project lead), this might be unacceptable. Keep in mind that the software must be usable by end user.
   
   Example: in one of my previous projects which the team is developing a digit signing solution, signing a document involves uploading document, adding recipients, putting signature fields to documents, customizing email template, sending notification for signing, recipients signing the document and eventually a document is being signed by a digital certificate. We had a 1 week Sprint and we had only 4 software engineers at that time. How can the team deliver a workable and usable product in one Sprint? A team may easily decide to spend the first Sprint on setting up the software framework, another Sprint on the uploading document module which support multiple documents with the support of multiple document formats with conversion of PDF and yet another (or possibly a few) Sprint(s) on adding signature fields and support different fields types. However, it is obvious that end of each Sprint is not a workable software nor usable by user. Instead, our team did create a workable software in the first Sprint, which reuse a software framework of a previous project, supports uploading only one document, only one recipient (the current user), adding only one type of signature field (textbox), customizing just the email subject and content, sending through email, self-signing the document by filling in the text and printing the text on the PDF document. It has the complete signing workflow with minimal feature but is a workable and usable software. It doesn't even have a user registration nor login, which was implemented in subsequent Sprint.
   
   It is obvious why we need to deliver software as soon as possible. Software is designed to be used by end users, and we have to deliver the software to end users to make sure we are working on the right direction and the right purpose in the way that it really solves business problems that it intended to be. As compared with traditional waterfall model, one can spend months to create the first prototype before knowing that we are in the wrong direction. Or in a technical migration project that after completing 90% of the migration and finally found one key component in the later 10% of the time that was unable to migrate and has to fall back to legacy technology.
   
   Despite the fact that the project can go wrong or not, after releasing the first usable software to the end user with minimal features, the users can be able to start finding values in these early versions. They can give feedback on the next important features they are expecting and the Product Owner can adjust priority of the Product Backlog to accommodate the request. 
   
   In a large migration project, a team can spend months to migration the whole project. How about start delivering with the minimal features on the new platform?
   
   Another major reason why require to deliver a workable product and is usable by end user is to achieve project transparency. Not just to be transparent to end user how the product works, but also to be transparent to project stakeholders, who may be the management team of the company, partners of the company or key customers. Transparent to management team so that they can give directions if the team is running to the right direction, to see if they discover the value of the project from time to time and adjust the priority of the project which may result in allocating more resources to the project (or suspend the project if the team is not doing the right thing). Transparent to partners and key customers to get early feedback if see if software products are solving business problems. In fact, this is the reason why we have the Review meeting in Scrum.
   
   
3. The owner of the Product Backlog. It may sound simple to be the owner of the Product Backlog. But the success of the project is really relies on the backlog itself. Being the owner of the Backlog, you are responsible for every items inside.
   
   Are the stories defining in the way it suppose to be? Are we describing the backlog as a list of business requirements? Or the backlog is a list of technical requirements or technical tasks?
   
   Is the Product Owner able to clarifies the business values of each story and provides a clear "definition of done" from the user's point of view? Or the stories become engineering tasks only software engineers can understand?  
   
   The suggest syntax to get started is something like "As a [user/role in the business], I want to...[the business purpose]... so that .... [the business benefits]". The story is a business story that is created by the product owner expressing what he wants to achieve from the business point of view. The main idea why doing so is that Scrum wants to make use of the brain power of each software engineer. It is believed that if the Product Owner describes a business problem, each software engineer in the Scrum team can come up with their own solutions. Note that it is not just one and only one solution. As a software engineer who is very strong in problem solving and who understands there are always ways to achieve the same result via different implementation (i.e. different source code), Scrum believes that each software engineer can propose one or more solutions in different approaches. If a task is a well defined task, then the engineer is just working out the implementation, it results on the waste of their creativity. If in a migration project that the Product Owner can clarify its purpose of the task, maybe a team member can come up with a better solution than what the existing solution implement which was being used in the past 10 years? Software Engineers are not just coders.  
   
   Being the owner of the backlog also means that the Product Owner is the one only who is responsible on what to put in the backlog. Not any one else. Any others can give suggestions and to negotiate. But after all, it is the Product Owner who owns the backlog.  
   
   
4. Priority. Product Owner is the owner of the product backlog and is responsible to prioritize the stories. The priority is so critical that it determines what stories to implement next and it decides what business values the product should shows to the project stakeholders in the next Sprint. 
   
   When working on the digital sign project mentioned earlier, a Scrum team may decide to implement "Documents Upload" module first in the first Sprint, then "Add Recipients" module in the next few Sprint. While this is the logical steps in the signing workflow but the "priority" here is much more granular than that. The implementation of the module has to be breaking down into stories. Each story is supposed to be able to be completed in a day; while a few may span two or three days at most. So in the above example, instead of the whole "Documents Upload" module, "upload single document of PDF file type" (which can be completed in a day) is of a higher priority as compared with "support multiple documents" and "support docx" or "support img" (each of which can also be completed in a day but not a priority in the next Sprint). 
   
   
5. Set a Sprint Goal. Setting a goal for each Sprint and also a key in Scrum. A clear business goal let the whole Scrum team and project stakeholders understand why the team is working on those tasks in this Sprint and why Product Owner prioritize and select the stories in this Sprint. All members understand and work towards the Goal. For every decision point the team has to make, e.g. they found issues that may need to spend more time than they original estimated, they could ask themselves whether if the decision can achieve the goal of the current Sprint.

Sounds like you are not the Scrum Master and not the Product Owner, it looks like all described above is none of your business. But it is not. Because both Scrum Master and Product Owner can be someone who doesn't have the technical knowledge you have. Even if they do, you are the one who implement it (no matter you are software engineer, QA or UI). You know how much time it takes to implement a particular story, related risks and dependency. You have to pass this message clearly to Scrum Master and Product Owner. 

During the Scrum Planning meeting,

• Product Owner will propose the Sprint Goal. Development Team can negotiate the goal(s) - to minimize the scope of the goal or to propose more than the Product Owner expected;
• In planning poker, the development team needs to give estimates which must consider all related risks and resource requirements;
• In Sprint starting, it is important that it is the development team who put stories into the Sprint (the Sprint backlog), not Product Owner. This may be a common mistake that some Scrum teams have. 

Product Owners prioritize the stories in the way that the most important stories that could achieve the current Sprint Goal are always on the top-most position, while optional stories are lower in the list. When development team are deciding which stories to put into the Sprint, it is always selecting from the top to the bottom. If eventually development team selected those stories but unable to achieve the Sprint Goal, then it is either the goal is too large to accomplish or the stories is not breaking down small enough.

 

Yes, you can. You can always takes things easy and in the state of honey moon by achieving less by either giving a high complexity point during planning meeting or putting less stories into the Sprint backlog. This is why Scrum specifies Scrum Values, which are Commitment, Focus, Openness, Respect, and Courage, and I want to emphasizes a few:

• The team members are always trying to do their best and achieve the best of their best. Individual team member may not be able to achieve high productivity in their previous projects due to whatever reason, but Scrum helps each team member to excel their best. This is why Scrum has daily Scrum to make sure each member is working toward the right thing, towards the Sprint Goal, and is not stuck on specific issue or task. If a member get stuck, other members discover and would be able to reach out to move things forward. There are Retrospective meeting that the Scrum master and each member identify issues, resolves it and improve the whole team. The productivity of a successful Scrum team is at least the four times when they start working on their first Sprint (measured by complexity points).  
• Commitment. That when you, as a member of the team, are agreed to complete the stories you put in the Sprint backlog, you must complete it on time and with best quality. You must know that the whole team depends on you and "stories cannot be completed" is unacceptable. If, and only if, you find it difficult to complete the whole story, then always look at the Sprint Goal and ask yourself if you can propose to implement certain sub-tasks which achieve the major goal and leave some fine details later. Discuss with the Product Owner when doing so. Do not develop a culture that stories can be carried forward to the next Sprint. 

​This is why a Scrum Master is important to keep promoting the Scrum Values to team members from time to time to make sure everyone understand and exercise them. 

Side Note: The planning poker can avoid certain development team members wants to reduce productivity by giving high estimation on stories. It is why each member is supposed to give their own estimation and the members with lowest estimation can challenge with those giving highest estimation in different rounds of planning poker if the difference is large.

 

​Yes, this might be true. There are thousands of reasons one might not want to change the way it is and keep believing the current project implementation is the best. Realizing the need for change is one of the most challenging thing in life. There are 3 words that the Scrum book I read keep repeating at least 5 times throughout the book and I want to share with you: "change or die".