Lessons from Scrum

There is a notion in the software industry that teams are either “doing Scrum” or not. That is true in some cases, but the majority of teams are using a hybrid of methodologies based on their experiences and situation. Some of this apparent isolation is linguistic: Scrum has its own terminology for some notions that are not strictly Scrum-specific. This article will dig into some software project management ideas that can be used by any team, regardless of methodology.

Dedicated Research Time

In Scrum, a Spike is “A time-boxed period used to research a concept and/or create a simple prototype.” Aside from the fact that a Spike is also a Sprint, there is nothing that says you need Scrum to justify R&D. Does your team take Dedicated Research Time when it’s needed?

Full-Stack Prototypes

In Scrum you would call it a Tracer Bullet. This concept refers to code built with the chosen technology stack to test the integration between all the layers without building out functionality in earnest. This is smart because often integration points represent the greatest uncertainty in a software project.

Have you ever said “It’ll be easy, they have an API!” Then after starting work realized “Oh my, this API doesn’t have one critical feature we need!” This technique lets you find these types of problems and revisit the plan early on. The “Tracer Bullet” terminology often comes with the assumption that the code should not be thrown away, but rather should serve as the foundation for the application to be built on. Opinions vary on if the term “prototype” implies throw-away code. What would you call this technique?

Offline

I like to say “Let’s take this offline” while in Scrum parlance you’d say “Let’s sidebar this”. To keep meetings short, any discussion that isn’t relevant to everyone present should be moved to a “sidebar” aka some other time. The sidebar may even be a conversation in the hall or an email rather than another meeting. This is a great way to avoid wasting peoples’ time.

Status Meetings

Scrum recommends daily meetings called Stand-up meetings, Stand-ups, Daily Scrum Meetings, or Daily Scrums. These are generally held in the morning and are strictly time-boxed. A common duration is 15 minutes. During a status meeting, each team member answers the following three questions:

1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way?

To keep the meeting short, all planning and problem-solving discussions are sidebarred (per above). One of my colleagues at Bocoup has had success time-boxing each person’s answers. No one is allowed to interrupt during that time. Again, this helps keep the meeting short and encourages sidebarring.

Even if you don’t have daily stand-up meetings, you can use some of the same practices to help keep status meetings productive:

• The three questions above are great for any status meeting. I use them in weekly project check-ins.
• Strictly time-box status meetings to encourage the best use of everyone’s time, especially if your meetings frequently run long.
• Sidebar any technical or problem-solving conversations. Status meetings are good for raising issues, but usually it’s better to resolve the issues in another channel.
• Sidebar any conversations that are not relevant to everyone present. I recommend this in all meetings.
• Give everyone dedicated time to talk without interruption.

Product Owners

In Scrum, a Product Owner is a well-defined role. Wikipedia sums it up pretty nicely:

Communication is a main function of the product owner. The ability to convey priorities and empathize with team members and stakeholders are vital to steer the project in the right direction.

In this definition, a Product Owner acts as the interface between the development team and the business stakeholders. You don’t need a Scrum-style Product Owner role for there to be healthy communication between the development team and business stakeholders. Who has been responsible for this on projects you’ve worked on? What happens if this communication is poor?

The Backlog

Do you have an issue tracker? Then you have a backlog! Scrum suggests specific practices about how it is managed and used. Here are some of the practices that anyone can use:

• Put “knowledge acquisition” tasks in your backlog in addition to bugs and features. Any task that takes time should be tracked so that time can be prioritized.
• A formal “backlog pruning” (aka “grooming”) is useful. This is a dedicated time to go through the backlog, assign priorities, close obsolete issues, and so on. If this isn’t done regularly backlogs can become unwieldy over time, which makes it hard to find and prioritize the work at hand.
• In Scrum, a Product Owner is often responsible for backlog pruning. Even if you don’t have a formal Product Owner role, it makes sense for the project’s business stakeholders to be represented in backlog pruning. Maybe invite someone who isn’t on the engineering team?

Increments

An increment (or product increment, or potentially-shippable increment, or PSI) is a state of an application that could theoretically be published (or shipped or launched or deployed). In Scrum, the idea is that every Sprint ends with the code in a state that could be published. If you’re not doing Sprints, you should still strive to keep your code in a state that could be published. In fact, why should it only be every 2 weeks? How about continuous delivery? Maybe you should Always Be Deploying?

Self-organization

Self-organization is a principle touted by Scrum that is often hard to nail down. It encourages individual proactiveness and self-management rather than heavy hierarchical management. Team members have to be responsible for their own day-to-day productivity, and managers have to provide higher-level guidance and direction. This is necessary for any healthy software team.

I want to point out a specific principle of self-organization is a lot more specific. Wikipedia says:

Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed according to the set priority and the Development Team member skills. This promotes self-organization of the Development Team, and developer buy-in.

The team can decide how to divide the work if the backlog is prioritized properly. This avoids the unhealthy behavior of a 3rd party guessing who is best equipped to do certain tasks: each person already knows the answer! At Bocoup, we pitch projects to our engineers rather than just assigning work. This promotes a sense of ownership, autonomy, and accountability.

I hope these tips are useful regardless of how your team is organized. Ultimately we all want the same outcome: happiness and productivity!

How have you used these techniques in the past? How did it go? We’d love to hear more project management thoughts in the comments!