Scrum for small teams
A small introduction to Scrum
Scrum is a tool for bringing out the best in development teams. It has been around for several years, but I believe it has gained a lot of momentum in recent months, with companies like Square and Shopify adopting it as well.
These days, many companies are choosing to implement scrum for teams with less than 20 developers (or 10), and we have seen some great results from it. Okay, maybe not all of our clients have implemented scrum yet, but many are looking at how to do so.
The Scrum Framework
One of the reasons I like to use scrum is that it’s an easy way to manage teams that aren’t as big and diverse as large companies. Most people think they know how to manage a team, but they often have no idea how to build one, let alone test it.
Scrum is a framework for allocating work and communicating progress. It allows the team to be responsible for allocating work, not just the individual. Since each team member has a specific role, they need training in how to do so.
In a scrum/agile organization, each individual has an “account” or “ticket” on the board that reads: “I’m responsible for this item” or “I’m not responsible for this item” — depending on whether you want them to do the work or not. They are also asked about their priorities and which items are most important for them personally. They then learn how best to allocate their own time with others in order to meet their goals.
In other words, scrum allows everyone involved in an agile project (including management) to be accountable for what happens with their teammates — regardless of whether they’re working directly with them or not!
Common Scrum Work Implementation Problems
In the following, I’ll describe various common problems in implementing scrum in small companies.
First, consider a team consisting of five people.
We have a Product Owner (PO) who is responsible for defining and prioritizing features to be implemented. He or she defines requirements for each feature – requirements for what should work, what should not work, how long the feature will take to complete, and so on.
This PO also works with developers to ensure that the requirements are met within their scope of responsibility – ensuring that they are not adding more features than they can actually carry out (by example: if a developer knows that one feature might be delayed because it is new code, he or she may decide to do it anyway), and that the developer can complete it within the time allotted by customers.
An agile team consists of five people: developers, architects, testers, business analysts (BA), and PMs (also called developers). Before starting any sprint, each member of the team must sign off on the sprint’s status. This is done using the sprint backlog which is a detailed list of all tasks assigned to each developer based on his or her role in the sprint (tasks in Sprint 1 are tasks in Sprint 2). For example:
Sprint 1 task 1 — T1 — T2 — T3 — T4 — T5 — S1 — S2 — S3 — S4 — S5 — B1 . . . . . . . . . . . . B50
The business analyst prepares an analysis report for each task from this backlog. The architect designs which features will be implemented during this sprint based on these reports and tester’s input regarding quality assurance issues. The developer implements these features by completing his or her assigned tasks according to the architectural design provided by architect at this point in time as well as any additional changes requested by tester(s) based on feedback from other teams/architects during planning meetings/conversations/etc.. At this point in time there is no definable release date as an application has just been initiated but there are still several months before public release. At some point leading up to this milestone date when we think we’re ready for public release we’ll need an inter-team meeting where everyone agrees upon release date and what all features will be included in public version of our product along with any known bugs and difficulties encountered thus far along
Strategies for Team Communication
Scrum is a framework for managing small teams. It is unique in that it allows teams to work together productively, to deliver products that are high quality, and to do so in an effective, efficient, and sustainable way.
Scrum is a product of the agile movement. It was originally developed by software engineer Steve Krug when he saw a need for “scaled Agile” (also known as “Scaled Agile” or Scaled Scrum), where small teams could be directed with greater clarity and efficiency than large teams. Scrum was specifically designed to address these issues:
“The transition from traditional large group development methodology to Agile methodology required understanding how different stages of project development worked. The issue was that traditional large groups were often disconnected from the activities of individual team members at any stage of their projects – the team members themselves lacked insight into their own roles and responsibilities.”
Scrum has been adopted by companies including Twitter, Netflix, Lyft, Spotify, LinkedIn and Salesforce.
Organizational and Cultural Issues in the Implementation of Scrum
Scrum is an agile development methodology that was developed by Ken Schwaber and Jeff Sutherland. It describes a development process that can be used to create software products faster and with more simplicity than traditional waterfall development methods.
Scrum is mostly used in software companies, but it can be applied to other industries like financial services, healthcare, manufacturing, or even in the military. Scrum has proved to be highly effective at producing high-quality software. This is due to its simplicity and flexibility. Using Scrum means that every individual who works on a given project is coordinated by the team as one unit with clear roles and responsibilities.
However, there are many things that need to be taken into consideration when implementing scrum:
I was recently reminded of a situation I had at my previous job where I was struggling to get things done. We had a ‘make it happen’ team, which meant that we were constantly scrambling to meet deadlines, and most of the time we were nailing it.
I was struggling because I didn’t know how many sprints would be needed on a given project, or what the dependencies would be among them all together.
One day, I told the team about my problem: “The shortest way to solve this is to split our sprints up into chunks that are guaranteed tasks, where each chunk can be completed independently from the others.”
They looked at me like I was nuts. “The whole point of scrum is that we should focus on getting stuff done quickly!” they said.
I realized then and there that it might not have been a good idea for us to use scrum at all: It would not help us get stuff done faster; it would just make our projects less efficient and more chaotic than they already were — which wouldn’t help us achieve our goals in any way.
What this means is that when you hire people for small companies, you have to accept their default behavior: They will work hard and they will do their best; they won’t let other people down; and they will succeed only if everyone around them does similarly…
In short: Everyone has to behave as if he or she were in charge of his or her own team…