"Scrum is the art of doing twice the work in half the time" -Jeff Sutherland
But how does that happen?
Moreover, how can that happen in the world of open source come-and-go-as-you-please projects?
How it happens has two components:
- Soft Skills
- All the Life beyond words
Principles are portable. They do not change.
Practices depend on context. They are unique for each team.
All you need to Agile Scrum is some unordered list.
If you can make the work a list, then you can Scrum it all!
You need no special softwares, though softwares do exist.
You can Scrum quite well with just some post-its and a wall!
But there's a secret sauce to this, without this you cannot Scrum:
Only with right principles, will Agile you become...
- Individuals and Interactions over Processes and Tools - Talking to each other, building friendship, community, and collaboration is valuable. We can't just rest on applications, tools and formalities and call it "compliant".
- Working Software over Comprehensive Documentation - The best way to know if you're on the right track is to build a little something, show it, and get feedback. Spending forever just talking about building something is not building something. The doccumentation is there to serve the software, not replace it.
- Customer Collaboration over Contract Negotiation - If we do the above step right, this takes care of itself. respond to feedback, don't deny it.
- Rsponding to Change over Following a Plan - The whole point of Agile is that things change, and the project needs to adapt with it. This is achieved by focussing on individuals and interactions, listening, getting feedback, and changing before things have been set in stone.
- Focus on what is the most valuable thing the team can be working on right now.
- Respect for each developer's unique perspective and contribution to the team.
- Openness so that everyone can equally inspect, engage, and contribute.
- Courage to speak the truth, to take risks, and to be able to learn from mistakes.
- Commitment to creating value as a team, sharing in ownership of delivering that value.
Practices and how they happen in an OSS context:
The straight practices are found in the scrum guide, which applies them to a dev workshop. A team of full-time developers being paid to make something useful for the Product Owner, who represents the users to the team. Even in a dev shop, each team makes their own unique scrum implementation, but OSS has some big differences to a dev shop.
- People come and go as they please. There's no binding agent to an OSS team's cake the same way money enforces things in a dev shop. Literally no one on my project (including me) works full-time on it. It's all just "Do when you can, and if you feel like it." So how can we even begin to scrum without the commitment which money obligates?
- The team members are constantly changing, which means there's no time to really learn each other's strengths, let alone form the trust necessary to self-organize.
- Since work hours aren't regulated, sprints are reduced to the two hours we have to pair at the fortnightly meetup. That's hardly enough time. Or worse, they're random and scattered. Different every sprint, different for every contributor. We can't form team unity that way. Gone is the metronomic drum beat that is the very life of scrum.
- We are neither space nor time localized, so how do we form the unspoken culture that makes a team? How can we have information radiating, let alone practice openness when time and space effectively puts us each into our own private Idaho? I can't even use my post-it notes! No one sees the wall but me! We're scattered to the winds!
How do we face these challenges in the voluntary transient post-scarcity world of OSS?
If there is one thing Agile is good at, it's responding to changes. If our Scrum can't handle OSS, our Scrum 'aint Agile. But the terrain of OSS isn't all bad. There are quite a few features that play to the strengths of Scrum. And even the bad parts can be fertile ground for Scrum when viewed and approached from a good angle.
The Scrum Team: This is the whole package. It's the entire Development team plus the Product Owner, Plus the ScrumMaster. In OSS, that'd be everyone who has ever commented or made even the slightest contribution to the project, code-related or not.
The Development Team: Any one who contributes working software to the project. (Pretty much everybody.) There is only one title in the Dev Team: Developer. There are no ranks. There are no officially recognized specialists. Some developers are better at A than B, and Developer X may have more experience than Developer Y, but every developer is there to help deliver the product, and is not barred from doing whatever task is needed to accomplish that. The Dev Team is self-organizing. No one tells them how to deliver working software. No one tells them how long it will take. They decide in consensus how much they can commit to doing. They decide in consensus how to go about delivering working software. They are trusted to come up with a quality solution to the needed features on their own without anyone intimidating them into compliance. In OSS, for self-organization, the Dev Team uses GitHub issues, pair programming, and 5-minute planning talks to formally coordinate its efforts. Informal coordination is encouraged, and happens all through pairing, and through other channels, such as slack.
The Product Owner: This is the single person who decides what features are of most value to the users and prioritizes those for the Dev Team. They are in a sense like the boss, but their powers are limited. They are the one telling the team what to build, but not how to build it. Their job is to communicate what the user's needs are to the Dev Team, prioritise the next set of features to be built, and be available to answer questions so that mistakes and miscommunications are caught early, before they become big problems. The Product Owner can optionally be a member of the Dev Team, but has no extra authority in that capacity, nor any less respect than any other Developer in the Dev Team.
The ScrumMaster: This is the person who champions Scrum principles, facilitates the Scrum rituals, coaches the team on how to self-organize, maintains the Scrum artefacts, works with the Product Owner to help the team succeed, removes obstacles to success from the Scrum Team, and coaches the Scrum Team to self-organize in removing obstacles within its scope. The ScrumMaster can optionally be a member of the Dev Team, but has no extra authority in that capacity, nor any less respect than any other Developer in the Dev Team.
The Vision Statement: The vision statement is the north star of the project made or approved by the Product Owner. Everyone needs to be able to see it and read it. When that statement isn't open to dev shop developers, they forget why they're doing what they're doing, their commitment suffers and the code's quality takes a hit. In OSS, developers might not contribute at all without access to understanding the reason behind the project. The vision statement is rarely longer than a paragraph, it's vague on details, but clear on objectives so that it can adapt to technical changes yet remain as constant as possible.
The Working Agreement: The working agreement is a little like a mini-constitution. It announces how work is to be done, codes of conduct, how long sprints will be time-boxed. (For us, 2 hours.) And any other specifics that the Scrum Team agrees to. It can be used to adapt scrum to the environment, but not alter it or delete it all together.
The Roadmap: The roadmap is a view of where the project is headed from 50,000 feet. It is made or approved by the Product Owner. It is a list of low detail features the project will have. Details will be filled in as the dates in the roadmap get closer to the present. In Agile, we wait until the last responsible minute to fill in details. This is when know the most about the challenge we're facing, and can make the most relevant high-value decision.
The Product Backlog: The product backlog is an ordered list of "user stories" that is maintained by the Product Owner. It is a specific list of behaior the software must exibit. The list is ordered with the approval of the Product Owner with the highest value items at the top.
User Story: A user story is basically a work ticket with "Why-am-I-coding-this" information baked-in in the form of a user's need. The format is generally:
As a ___ I want ___ so that ___. Such as "As a new contributor, I want a blog article explaining scrum so that I can get right to work on contributing to the project without wasting time figuring out how things are done." Stories are frequently broken down into check-boxed tasks. If a story is too big, it becomes an "Epic", with its own list of stories. If it's too big for even that, it's a "Theme", and is better a part of the Roadmap. In scrum, you have to keep tasks small and well-defined so that you can focus. In our scrum, they need to take less than two hours to complete.
The Sprint Backlog: When it is time for the next sprint, the Product Backlog is inspected by the Dev Team. The dev team selects however many tasks from the top of the list it believes it can complete within the time-box. These items become the Sprint Backlog, AKA Sprint Goal.
The Definition of Done: A story is not done until the Product Owner accepts it as done. Part of that acceptance is automated by "The definition of Done". Any test that needs to be performed, any documentation, blog articles written etc that need to accompany the working software need to accompany the working software. The user story is only done when it meets the definition of done. Then it is "Done" done. The definition of done is often a part of the Working Agreement.
The Product Increment: Completed, Accepted, "Done" Done Stories become part of the product increment, the next working iteration of the software. Rejoice!
The Sprint: Sprints are evenly time-boxed working periods. At the front end of them is sprint planning. At the back end is a review and retrospective. In between, working software is created. Each sprint produces a new working version of the software that can be tested by users, who can then give feedback. A typical sprint is 2 weeks. They are sometimes as long as 4 weeks or as short as 1 week. Ours are effectively 2 hour Micro-Sprints.
Why 2 hour Micro-Sprints? We could have done it so that each 2 week period between meetups was a sprint, but that would have put the wrong emphasis on the work and cause people to be isolated as they work. In many cases, this isolation isn't enough to destroy the srum, but there are very real intangible benefits to being in the same room as another working on the project. For that reason, Even if you are not at the meetup, I hightly recommend getting together with a buddy and pairing rather than trying to do it all solo. You will each learn a lot from that, and the project will have a stronger code base for it. That's why 2-hour Micro-Sprints are done as opposed to 2 week sprints. The co-location factor makes it worth it.
Sprint Planning: At the start of a sprint, the Product Owner presents the features that have the most value to be worked on in order from highest to lowest. The Dev team spends half of that time coming to a consensus on how many of those features they can accomplish. The second half is spent figuring out how to deliver those features by assigning stories, identifying dependencies, breaking large stories into smaller tasks, and whatever planning is needed to deliver those stories as part of the product increment at the end of the sprint. In a standard sprint this takes 4 to 8 hours depending on the length of the sprint. Ours will last 10 minutes in our micro-sprint.
Daily Scrum: At the start of each day during a sprint, the team stands up to self-organize, inspect the team's work, and adapt their own work to respond to any changes. This is sometimes called a "Daily Stand-Up", since it should not last so long that it becomes uncomfortable to keep standing. It's usually time-boxed to 15 minutes. For micro-sprints, we won't need a Daily Stand-Up. Our sprint planning is the only Stand-Up we need.
Spikes: A spike is a brief aside where a developer or a some portion of the team experiments with something that will likely happen in the next sprint as a proof of concept, and to discover any unexpected complications. In general, we will not have very much time for spikes, but they may be done outside of our micro-sprint in preparation for the next meetup.
Backlog Grooming: This is something the dev team is encouraged to participate in, but is the final authority of the Product Owner. Backlog grooming is where the Product Owner and others can add discovered high value stories, remove unnecessary stories, or reorder the stories to reflect what is most valuable at the moment. It is never done for the current sprint, always for upcoming sprints. The current sprint is set. No new stories should be added without very good reason.
Sprint Review: At the end of the sprint, the developers give a presentation on the new features they built, answer questions and get feedback from users and the product owner. They can then use this information to further adapt the product backlog for the next sprint. This is usually time-boxed to 2 hours depending on the length of the sprint. For our purposes, we will do a 5 minute review at the end of our micro-sprint. The details of the review will go into a blog article after the meetup.
Sprint Retrospective: After the Review, a retrospective is had where the team's processes are evaluated. Lessons learned are recorded, problems addressed and solved, and action items determined so that next sprint the team's performance will improve and iterate along with the software they are incrementing. This is also usually time-boxed to 2 hours depending on the length of the sprint. Ours might include a 5 minute retrospective just to get a quick recap of the action and lessons learned. The details will go into a blog article after the meetup, likely incorporated into the same article as the review.
- If money is what binds the team together, you have a problem. Open Source cannot hide behind salaries in order to pretend its team is committed. Money can win people's hands, but to win their hearts and achieve the hyper-productivity scrum is advertised as having, you need something more. OSS projects have to focus differently. They have to win developers' hearts so much they wins their hands, too. Money can lie to you and make you think you've won hearts when all you've won is hands. Quality software comes from committed developers, so when the commitment is there in Open Source, it's real. When it isn't there, there's no hiding behind pay.
- This is where good docs and superior culture come into play. In OSS, you need these things in order to bring the community together. You can't do it though money, so the only other bonding agent is culture. Culture, Service, Arts, Communication, Docs. This is the OSS stack. No one yet has done it to a shining degree of excellence. But it can be done. For OSS, these need to be geared toward quick, efficient and easy on-boarding. People come and go. A good culture can retain some of them, but good docs is what scoops them up, and gets them ready.
- Maybe 2 hours is all we get. We can encapsulate a micro-sprint within that time-box. Backlog Grooming is handled outside that time-box. Sprint planning and daily scrum are combined into a 10 minute session before pairing. Pairing happens throughout, so collaboration and communication never ceases. After the pull request is sent, Review and Retrospective come in the form of blog posts and lightening talk. Those go on to contribute to the docs and culture of the project, which themselves go on to improving on-boarding and contributor retention. 2 hours is the shortest sprint I've ever heard of, but it's still iterative and still retains a rhythm, which is why it's a better choice than 2-week traditional sprints in our circumstance.
- If there is one thing that open source is good at it's being open. If there's one thing the internet is good at it's bringing scattered people together. Post-it notes can be reproduced over walls wherever a contributor may be (and I highly encourage that!), but the culture is transmitted though the right kind of documentation, artful documentation. Not docs that serve as spec, ones that serve the individuals and interactions of OSS, that help to encourage, excite, and inspire people to contribute value to a project without the need for bribery.
With OSS and Scrum, value is added to the world, and we get to build both that value and a strong community together.