Scrumfall [skruhm-fawl] noun
1. a mixture of scrum and waterfall software development
2. the speed of agile software development being chained down with waterfall software development
When I became the leader of a development team, the company I was working for used a mixture of waterfall software development and Scrum software development. This mixture coined “Scrumfall” was probably 30% Agile and 70% waterfall development. All the different roles were on the same development team working together in four-week sprints. The team did work in task-based assignments that had hour estimates. This was a great start, but there were three significant problems with this approach:
- Requirements, feature design, and test plan followed waterfall where each stage blocked the next one
- Task-based assignments with hour estimations were always padded
- A four-week sprint was too inflexible and difficult to plan accurately
The transition journey took a few months, but my team aligned more closely with Agile and Scrum methodologies.
Agile Development Values
1. Individuals and Interactions Over Processes and Tools
2. Working Software Over Comprehensive Documentation
3. Customer Collaboration Over Contract Negotiation
4. Responding to Change Over Following a Plan
In the waterfall process, there would be a requirement gathering stage where a manager would talk to the product manager to work out the requirements. Then the team would review the requirements and maybe adjust them a bit. Eventually, the design starts as one senior developer would write up a design doc. Then the rest of the developers would read, comment, and ultimately sign off on the design before any development could start. If the feature was very complicated, the design might take days to write up before reviewed. Then a test plan is written according to requirements and the design. The rest of the team would read, comment, and ultimately sign off before the QA engineers created tests.
Each of these stages is done serially, which leaves a few engineers with nothing to do. What the engineering department did to optimize this problem was to work on multiple features at once. The solution solved the serial timing issue but splintered the team into numerous isolated tiny groups or even a single person working alone for an entire sprint. On average, the team could be working on four or five features simultaneously. This strategy created tribal knowledge and did not foster a sense of knowledge sharing or working together as a larger team.
To fix this issue, I transitioned the team to focus on one or two features at a time and having design meetings where everyone would contribute by debating on potential solutions. The team hashed out enough details to get started, which significantly lessened the time spent on requirement review and design write up. Ultimately, this process raised the quality of code because many people were contributing instead of a single person designing the feature. People would think up of different ways to implement the feature and debate on what approach to take. Sometimes, the design would look drastically different from when the team started on it, but the code quality was much better. People were focused, began to work together more often, communication improved, and knowledge was being spread.
Story points are abstract units based on complexity. They have a steep learning curve as many people find it difficult to let go of the hour estimates because time is a tangible concept. A person can look at the clock and see the seconds, minutes, and hours passing. A pattern I noticed was some people used story points as time. The first common issue I saw is using story points as hours of work, and the other problem is translating story points to hours. Both of these methods are common pitfalls because they are incorrect ways to use story points. To get my team passed the hour issue, I chose the Fibonacci number sequence and started with planning poker to abstractly establish what the user stories were worth. The first sprint was rough because the estimates were all over the place, but they began converging over time as people grasp what the worth of the story point values are.
The big secret is there isn’t a generic story points value system. It’s a perceived value that the team establishes and the critical point is to keep the group relatively the same and estimating the same way over and over. Adding or subtracting team members affects the value of the story points because there’s a different group of people. The estimation will be different, but it will stabilize over time again. The other crucial concept is to use metrics especially the sprint velocity. After a few sprints, the average sprint velocity gets established which is the key to forecasting the number of story points the team can burn in a future sprint. The essential concepts are: keep the team members relatively the same, estimate in the same way, and forecast based upon average sprint velocity.
Another steep learning curve is going to user stories from task assignments. It’s another concept that people have trouble adjusting. A task is something like “create a database to hold passwords for the application” while a user story is more of a description of a feature from a user’s perspective. Does this user directly interact with the database? No? That’s not a user story.
User stories follow a basic template of:
As a <role>, I want <something> so that <reason>
An example is: “As an administer, I want the ability to change user passwords so that I can help users reset their passwords.” Underneath this statement, it implies that there are components such a database, user accounts, and maybe a UI. Wait. There isn’t a user story for user account types or UI? Time to create them. “As a user, I want to be able to log into my account so that I can access my customer data.” Writing user stories is a great way to brainstorm what needs to be done to complete the feature/epic.
A recent evolution to user story is acceptance criteria that specifies what the conditions for getting the story done is, which is great because they replace requirements in the waterfall model. The acceptance criteria have a clear fail or pass case which aligns everyone to what must be done for the user story to be accepted. Examples are “non-administer accounts cannot change passwords” and “administer accounts can change passwords successfully.” This change is great because it eliminates the need to write requirements and reduces the time for writing test plans.
Transitioning to two-week sprints was met with initial resistance as some team members felt there would be too much planning overhead, but the change turned out to be one of the easier ones to see the immediate benefits. With a shorter sprint, the time spent planning became shorter because there were fewer items that needed to be discussed and estimated. There was time to react to changes in priorities or even when new information is found. The shorter sprint gave much-needed flexibility in adjusting to problems as they come up.
Initially, productivity dipped in the first few months as the team was adjusting to a new paradigm and process. Some of the hurdles needed Agile training to help move the team over from the waterfall method, but the benefits became apparent as the team became more reliable, flexible, and faster. Features were estimated more accurately with story points. Planning was reduced with user stories and changes to the design process. The shorter sprint allowed more flexible adjustments to priorities or information discovered. Overall, the team was given more autonomy and performed much better than it did before the changes.