Many of the followers of this blog are likely familiar with the Scrum framework for agile software development. That said, the software startups in the AtomLeap High-Tech Accelerator have brought up several issues related to the implementation of the framework, such as difficulties with meeting the targets set for sprints.
In order to help the entrepreneurs in our accelerator program tackle these issues, we organized a workshop with our startups and Jonas Kwashik, the founder of tech consultancy and design agency Sleighdogs and a Google Expert Mentor for Product Strategy & Marketing. Below are some takeaways from the workshop. If you need further tips regarding software development and are a high-tech startup based in Berlin, feel free to apply to join our program using the application form hyperlinked on our homepage. We are currently looking for one more startup to join our program starting in January.
The Scrum framework
According to Orr Frayden, AtomLeap’s development team manager, the Scrum framework was developed to help teams streamline the creation of new features or even entire software applications. The framework allows delivery teams break long-term strategies and goals down into smaller tasks that can be executed, tested, improved, and launched within relatively short timeframes.
As you can see in Figure 1 above, Scrum cycles are normally comprised of sprints, which are team efforts to roll out one or several features during short and concentrated projects that normally last two weeks (but can vary in length from one week to one month). The beginning of the sprint is normally comprised of a short meeting during which the sprint is scoped down and future users, who can be either clients or internal staff, communicate to the developer team what they need.
Unless this is an entirely new project or product, most sprints will have an input from previous sprints in the form of a task backlog. Those are the tasks that were not accomplished during previous sessions and that the team needs to revise and prioritize in order to incorporate them in the current sprint. Next is the design of the sprint session, based on the input from users/clients and the team’s structure and expertise.
The role of the Scrum Master (or delivery team leader) in these cases is to ensure that tasks are achievable within the given timeframe, that the right task is assigned to the right person, and that they are aligned with the long-term goals of the team. The following week or weeks are crunch time, the time when the delivery team actually codes the tasks ( or “tickets”) they set out in the beginning and when issues like the “bug having a bug” come up and must be sorted out. During the implementation phase, teams normally communicate during brief sessions or “standups” to other team members in order to alert others about the blockers or challenges they are facing and ask for help if necessary. Tickets are considered completed after they have been coded, tested, and evaluated. The sprint ends with a retrospective of what went well, what did not, and what still needs to be done (the backlog).
Tips and tricks on how to make your sprints more effective
Planning for sprints is not always easy. Often times, it is difficult to estimate in advance how long developing a certain feature or task would take, particularly if the type of technology being developed is very new. Failing to accomplish targets or deadlines on a consistent basis would in turn result in a demotivated team and in long-term difficulties reaching productivity goals and standards.
According to Jonas, some tips that can help you avoid this common pitfall is to make sure that the Scrum Master is familiar with the coding language and general challenges and dependencies associated with executing the tasks. Another tactic is using the fast-forward method: instead of planning tasks, executing them straightaway and then evaluating the results (does it work or not? Should we keep e). Alternatively, instead of (e)valuating tickets based on how much time they take to complete, Scrum Masters could devise a point system based on the estimated impact or value of each ticket to the project or product (output-based valuation).
Another important tip, according to Jonas, is to make sure that the workload is commensurate with each team member’s level of experience. For instance, new team members should get more of a buffer, he recommends, in order to get up to speed with the rest of the team.
Furthermore, some aspects of sprints — such as recording blockers on a daily basis for each team member — can be easily automated using plugins for Slack such as Asana, Standuply, or Kyber, which can help save time and improve communication among team members.
Last but not least, the sprint follow-up is almost as important as the sprint itself in order to ensure coherence among sprints and that they are aligned with the company’s long-term strategy. Therefore, make sure that you incorporate the takeaways from previous sprints into new ones and that you do not forget about the task backlog until the following sprint.