SCRAM, not Scrum, v.2
I have already tried to describe a methodology called SCRAM, but now revising it makes sense. Things have been learnt.
Scrum has Sprints, Scram has Scrambles. We scramble and push and do everything we can do deploy new functionality every day.
Humans and animals move fastest when running from something, not when running towards something.
In the case of Scram, developers are running from fear of being booted from the team, losing benefits, and losing respect. They are in an effort to ‘keep up’ with the best of the team.
Scram is like an olympic-level of development.
The purpose is to get the most out of the team, to push them beyond their usual capacity, and to meet their needs as we do so.
Let me start by just getting on with it.
I know ‘deployer’ is not a real word.
Requirements for Scram:
- A team consisting of: A tester, a deployer, 2-4 developers, and a product manager.
- Company-provided lunches of salad or pasta and varied meats (chicken, beef, pork, seafood, fish – 5 days, 5 different meats).
- Company-provided refreshments available whenever the team needs them (water, tea, milk).
- Company-provided fruit/berry snacks.
- A product to create.
Abnormal focuses:
- Nutrition of the team
- Pressure-cooker mentality
- ‘Natural selection’ evolution of team – the chaff gets booted out quickly.
- Team-members control who is in the team.
- Paired/quartet-programming encouraged.
- No documentation (unless documenter is added as a separate entity to team)
Normal focuses:
- Working towards a common goal.
- Test-driven development.
Roles:
- Tester – Works between developers and deployer. The tester is responsible for testing ‘completed’ work, and giving the go-ahead to the deployer. Developers must inform tester when work is ready for him to test. The tester is responsible for deployed, not-working functionality.
- Deployer – Works between the tester and the product manager. The deployer is responsible for deploying work which the tester approves for deployment. The deployer is responsible for broken deployments. The deployer maintains a deployment record for the product manager.
- Developers – are responsible for creating the product. Developers must understand what functionality needs to be made, and then make it. Developers must inform the tester of work which is ready for testing. Developers are responsible for work which fails testing.
- Product manager – is responsible for itemizing and detailing the functionality to be created. Is responsible for providing goals. Is responsible for released product.
- Documenter (not obligatory) – observes tester and story description from manager, and documents functionality.
Iterations:
Daily routine:
- 15 mins preparation – manager explains what tasks are ready. Developers recap what tasks are in progress.
- 120 minutes development – Major effort. Coding, testing, deploying can all take place.
- 15 minutes recap and preparation – developers explain what has been done, what is yet to do. Tester explains what’s tested. Deployer explains what is deployed and/or will be deployed. Manager observes.
- 60 minutes development – Medium effort. Coding, testing, deploying can all take place.
- 120 minutes lunch – extended lunch. Team should eat together, discussing work and patting themselves on the backs. Stragglers have time to catch up. Impediments and problems are explained to the manager.
- 15 minutes recap and preparation – next phase is planned, deployer recaps, tester recaps, developers recap, manager encourages.
- 120 minutes development – Major effort. Push to get something deployed if nothing new is deployed yet.
- 15 minutes cooldown – Patting-on-the-back, recap, discussing problems. Each team member confidentially writes two names: team member they were most impressed with, and team member they were least impressed with, for the manager’s review.
The manager’s daily routine is somewhat different:
- 15 minutes preparation – manager confirms with team what will be achieved today.
- 120 minutes development – manager reviews yesterday’s work and communicates with stakeholders.
- 15 minutes recap – manager learns the current state of development.
- 60 minutes development – manager plans and predicts outcome for the end of the day.
- 120 minutes lunch – manager joins in, discusses with team, jokes, keeps the atmosphere positive. Glares at slower team members.
- 15 minutes recap – manager explains progress and expectations.
- 120 minutes development – manager starts to plan next day’s work, based on projections for current day.
- 15 minutes cooldown – manager goes berserk if nothing was delivered. Manager praises team is goals were met. Manager collects feedback from the team.
Guidelines:
- Deployment can be made at any time.
- Something must be deployed every day.
- Extended lunch break. Always.
- Team members can be booted out of the team at any moment, at the manager’s discretion (based on team feedback).
- Team members should be the ‘elite’ and be paid and treated that way.
- Unique hats or t-shirts or mouse or monitor should be given to team members to distinguish them from others.
- Team members can break and snack at their leisure.
- Friday evenings of every fortnight should be a major wind-down, possibly with a trip to sauna, gym, massage, or yoga.
- Strong focus on nutrition; physical and mental well-being of the team members. Team members should start to increase their capacity for output the longer they stay a part of the group. Should also result in less sick-leave, which can collapse Scram.
Business-level notes:
The fact is, running with such a team is going to be expensive. The lunches, the benefits, the ‘elitism’ of their salaries, etc.
However, the potential output, and the fact that new features are delivered every day, gives such an approach a high value – a value which in broad terms can be translated into higher revenue for the business.
Being constantly pushed, reviewed, and judged by their peers can result only in the overal improvement of the team members, and a well-oiled team of intelligent and highly-skilled people should result in a high-speed development process, provided that the product functionality can be divided into components small enough to develop in a day.
It remains a fact that this development approach is not suitable nor required for many common projects. Users of systems rarely require new features available every day. Regardless, this approach can be maintained with releases to pre-production environments, which are then passed on to a Q.A. department for monthly deployments into the real world. The goal remains the same – to create the product as quickly as possible.
A note on documentation:
All products should be documented, and the documentation should be written for users. With Scram, an option is to have an additional team member – a documentation writer.
Flaws:
- Quality of work is never checked.
- Automated tests of functionality are not created.
- Unless the team knows each other well, it can be a free-for-all battle to get the ‘easy’ tasks to work on.
- Scope of stories to be completed is only broadly estimated, on-the-fly.
- Bug fixing has to be slotted-in randomly.
- It’s difficult to find team members suitable for such a high-level of output.
- The manager is somewhat hidden with his collection of feature requests and stories for the developers. For the developers, these may seem to come from nowhere.
- Team members have no chance to make suggestions for features.
