Is it too much effort for small teams?
Scrum is a popular collaboration framework based on Agile methodology which embraces cross functional collaboration, incremental development, and design flexibility. I am going to give you a high level overview about scrum. If you need more information, check these useful scrum tips and resources developed by Jordan Job.
Roles and responsibilities. A typical scrum process breaks up the responsibilities into 3 different roles: Product Owner, Scrum Master, and the development team. Product Owners is the person who represents the client’s best interest. This is typically the person who interacts with the client and has a firm understanding of the business requirements. Product owners are also the initiators in the scrum process who define the list of tasks called Backlog, and prioritize them in order of importance. Scrum Master, on the other hand, is the process leader who is responsible for make sure the team is following the scrum best practices.
Scrum in action. A typical scrum process begins with a Product Backlog, a list of tasks and requirements, usually created and maintained by the Product Owner.
Once the backlog is established, the team will decide on the Sprint. A period of time where the development team will complete a set of tasks from the Backlog. These tasks are usually determined based on priority and level of effort and are re-assessed in the sprint planning meeting at the beginning of each sprint cycle. From my experience, teams typically pick two week sprints because it is a good time frame to complete a substantial amount work yet still gives the team enough flexibility to pivot if priorities changes.
Some team also do Daily Scrum, which is a quick daily stand-up meeting to report progress and discuss issues. It gives team visibility on the pace of the development and decide if crash course is needed to make up time.
Once a sprint is complete, there usually is a Sprint Retro meeting to reflect on the previous sprint and fix any issue on the spot. It is also a great opportunity for the development team to re-assess their capability to take on more or less tasks on the following sprints.
“Wow! sounds like a lot of work!” “I thought we are trying to become lean and flexible right? This seems to be adding more steps?” These are the typical reaction I get after explaining the process. Some people may feel this is too much administrative work that they may not have enough bodies for. So does it really work for small teams? The answer is yes, and let me show you how our team was able to make a big leap in process efficiency and product quality using scrum.
At the time, I was managing a team of 5 software engineers supporting multiple applications for different product teams. each application has it’s own products, own agenda, and own code base. Although we were a good size team, we were spread out pretty thin. At any given time, we would have no more than 2 people working on a single platform.
As the product line and code size grew, our team was having trouble keeping up. Even though we would follow our development plan to a T, we would still find ourselves in a repeat pattern where we would develop a solid plan upfront, then the plan changes, leaving us scrambling to meet the deadlines. The diagram below shows our traditional water-fall process and how it evolve over time with changes.
There were a lot of back and force debate on if this was a plan issue, a resource issue, or a process issue. After several management meetings, I was finally able to convince the managers and the team members to give scrum a try. This is how we set it up.
- Product Owner: product managers naturally became our product owners for each scrum team split up based on platforms.
- Development Team: the development team is also split based on platforms. They were allowed to float around based on the platform workload.
- Scrum Master: The only real big change was my responsibility from a lead engineer to a scrum master, which meant I had to take a step back from development work and focus more on the administrative aspect of scrum. Running sprint planning and retro meetings, keep track of our sprint boards, etc. To make this work with our small team, I also took on QA, so we don’t always have the same developer testing their own code.
The diagram illustrate our sprint logistics:
- Two week sprints with a sprint planning meeting for each of the product line at the beginning of each sprint.
- First sprint meeting is also a development kickoff meeting where we plan out all the sprints in a development cycle upfront. The plan can be incrementally adjusted as we re-evaluate in the sprint meetings.
- 15 minutes daily stand-up meeting to report progress and discuss any questions.
- retrospect meeting at the end of each development cycle to re-evaluate and celebrate the release. Any lessons learned will be incorporated into the next development cycle.
How was this effective? The area we noticed the most improvements is how scrum process systematically handles changes. It significantly reduces the development iterations and prevents defects from carrying over to the later iterations and thus yields a faster and more efficient pace with a higher product quality. Let me demonstrate this using a real project as an example.
The picture shows one of our 3 month development project under the old waterfall process. I recorded each of the planned(Green) and unplanned(Red) revisions to illustrate how changes were introduced over time.
As you can see, we put together a initial plan to do 6 tasks with about one revision each. In reality, we get a lot more and even some scope creeps down the line. Each time a set of revision comes, we would try to accommodate immediately and try to turn around a build at originally defined check points. Typically, something like this will take at least 10 or more iterations.
Unfortunately, quick turn-around also exposed us for potential bugs as we were not given proper time to test. For example, if you look at 11/21/2016 revision where a bug was introduced. Before we could properly test for it, another revision came 4 days later. The new set of changes shifts everyone’s focus, and that particular bug got lost in the mix. Fortunately, we found it near the end and delayed the launch. Otherwise, we would have a much bigger issues with a major escape in the field.
How would scrum help this scenario? Using our new scrum process, we would break up the project into sprints like the red lines shown in the diagram above, and here are the improvements:
- Systematic changes: Changes are only re-assessed at beginning of each sprint cycle, which allows us the batch some of the changes together. From my experience, a lot of revisions are changes on top of previous changes, which made previous revision obsolete. This was a big efficiency gain because it allows us to tackle more things with less iterations. Note: this is also a huge behavior change because it also means you are not accommodating your client’s immediate request, which can be counter intuitive to grasp. In other words, be careful. it is going to be a tough sale trying to explain to the client.
- Incremental testing: Each sprint is focused on a set of tasks that are aimed for release quality. This means there are multiple opportunities to perform proper testing to make sure defects are not carried from one sprint to another. As you test incrementally, you will get a higher quality product at the end.
- Fewer iterations: scrum allows us to accomplish more with few iterations. Usually, the number of sprints is the number of iterations you need. The overhead time saved from redundancy like compiling code, analyzing bugs, and run QA test is more than enough to cover off on the extra administrative tasks. Time saved can also be re-allocated to other more productive tasks.
Aside from the 3 big items mentioned above, we also noticed that development team were able to focus better because tasks were fixed at sprint level. The issues were easier to identify and address because it’s incremental. Finally, the mentality shift to embrace changes kept our team spirit high and made the development experience more fun.
All of these contributed to a better product at the end. Comparing from projects before and after we implemented the change, we had nearly 80 % reduction in defects and 70% reduction in development iterations. In fact, the larger and more complex the project is, the better we performed. Yet there were still room for us to get even better. So for those who are still hesitant about making the change to scrum, I would advise to go for it. If your team is small, don’t be constraint by the formalities . Tailor the framework for your need. Remember scrum is like a big tool set. It is you that ultimately decide which tools to use.
