Abstract: What if you have less than 3 people available on a project? What if you want to or need to use Scrum? In Agile, Scale is a hot topic, but how does scaling work in the opposite direction? How do you scale down a process like Scrum for teams of 1-2 people and still make it deliver value?
This is a scenario facing a lot of people who want to follow Scrum but don't have a team around them. Take for example consultants working on per hour projects, where customer budget is finite and features over people are prioritised. College students working on final year projects or their thesis area which is a single person challenge. Open Source contributors building and maintaining projects that are powering the Fortune 500 are often 1-2 maintainers. These are some of the scenarios that we faced in Red Hat, all of which can follow an Agile way of work where Scrum’s principles and execution can be applied to small-scale teams; however, they’re often applied in a way that leads to something slipping. In our experience, that is quality. We set out to investigate whether we could maintain a high-level of quality and still have value driven output with a reduced team size. The result of this research is Small Scale Scrum, a long awaited and novel concept in Agile supporting planning, developing and delivering production quality software solutions for 1-2 person teams.
We will share the Small Scale Manifesto, the Small Scale Framework, results of our survey and share with you the successes of running this project in 10 real world projects and finally how we will crowdsource Version 2.0 of Small Scale Scrum by allowing you, the Agile community, to help us Inspect & Adapt the framework.
Lessons Learned from Your Experience: - * I realised that Scrum is becoming a de facto choice for running a project but small teams are not equipped to follow it. That this results in both a poor output and an unfair view of Scrum.
- * Scrum was often used to try and 'get more work' out of a project that had finite budget and people. The biggest slippages were always Quality and Communication. Comms was to be expected but Quality was a surprise as developers are schooled on good practices such as TDD/BDD which were abandoned in small teams
- * Having a daily standup as a single person brings much stronger reporting and risks or impediments were highlighted at stakeholder level much earlier than the usual approach of waiting several days to try fix it.
- * Working in such small teams makes any team member much more mentally Agile
- * I learned the power and value of having a framework to guide tough conversations about value in a time sensitive, resource limited environment.
Attachments:
