In recent years, agile methodologies have taken root in the software development world thanks to the popularization of techniques like Scrum or Kanban. At Appfluence, we try to ‘eat our own dog food’, and we use Priority Matrix to organize and plan our work. In the past few weeks, we have taken the approach of adapting our four-quadrants tool to a lightweight form of Scrum. But what is scrum? In this post, I will describe the design decisions we took, and how they influence the solution at which we arrived. Be it running a law firm, a heavily automated farm or a suburban gym facility (yes, those are all examples of actual Priority Matrix users), we hope that this article will help you with your project management.
First, let’s begin by explaining exactly what is Scrum and why you should care. In Lean methodologies, activities are classified into two categories: productive and wasteful. A productive activity is anything a user would pay for, like a new feature for your product. On the other hand, a wasteful activity is anything else. This is a controversial point, and a hard one to grasp, because sometimes wasteful activities are necessary. For example, a user will not want to pay for you to write good documentation, or fix a bug, or setup a payment system. Because of this, we further distinguish between necessary and unnecessary waste. The goal of Lean techniques like Value Stream Mapping is to:
- Eliminate unnecessary waste like unwanted features, waiting time, overstocking and other inefficiencies
- Minimize necessary waste
Interestingly enough, most of the work managers do can be safely classified as waste, but don’t say that too loudly around the office! In an ideal, completely efficient organization, everyone would be producing value at the top of their capacity, but managers, by definition, spend their time managing. That is, prioritizing, organizing, planning and scheduling. All of that is necessary to some degree, but no client would pay for it and hence, if you stick to the convention, you can call it necessary waste.
But we digress. The reason we brought the discussion of value vs. waste is because Scrum intends to help reduce or eliminate waste in the form of unwanted features. When you plan the development of a product, you are making a prediction (which is a fancy word for ‘guess’) of what the user will need when the product is ready. By necessity, the further into the future that you plan, the more unlikely it is that you will guess right and actually work on things the user wants. Therefore, one effective way to limit the amount of time and effort wasted on unwanted features is to plan only in short term. And here is where Scrum comes in. The standard Scrum methodology defines a fixed time period, called a sprint, during which you commit to completing a determined set of features. At the end of the sprint, you must absolutely have those features ready, and if you miss something, you know you’ve overestimated your capacity. At this point you stop, figure out what went wrong, and fix it for the next sprint. Sprints are usually one or two weeks long, but this parameter is something you have to determine on your own.
The reasons Scrum works are multiple. For starters, when you plan way far in the future, you can safely assume that things will change along the way (your client, the market, unexpected technical problems), and a significant portion of your effort will be wasted on unneeded features. With Scrum, you limit planning to the immediately following week or two. That way, the chances of something changing so substantially that your work plan is invalidated are much lower. Second, and this is perhaps the most appealing aspect of Scrum for engineers, if your customer knows that they will get updated results every week or two, and they can adjust their requests every so often, they will be much more reasonable with what they ask you to do. If, on the other hand, you follow a waterfall planning model when the client gives you all their input at the beginning of the project only, they have an incentive to throw everything and the kitchen sink, because that is their only chance to influence your work. Not a fun situation.
For these and other reasons, Scrum has become widely used in development teams everywhere. As people adopt it into their workflow, they make modifications to make it work in their environment, and that is exactly what we did. We hold week-long sprints, with daily “standup” meetings and one planning and retrospective meeting on Monday mornings. The one week cycles are a necessity for us, being an early stage startup where things change very, very quickly, and we can’t plan too far ahead. Our standup meetings are also bona fide Scrum elements, where each team member takes a couple of minutes to tell three things to the rest of the team:
- What they did the day before
- What they plan to do today
- Whether they have any roadblocks that impede their work
Finally, we hold our planning and retrospective meetings at the beginning of each week. The purpose of this meeting is to decide what are the team goals for that sprint, but also to realize if something went wrong with the last sprint, and whether we can do something to correct it. For planning, we use our own tool, Priority Matrix. Any time new requirements arrive, either from direct user feedback or from within our own team, we capture them into the appropriate project. If we have time to categorize the task, we might put it into a specific quadrant, but often we just write it down in the 4th quadrant, which we name “uncategorized”. Then during these planning meetings, we go over each project, determining what tasks to work on for the week, and move them to the first quadrant. When we have filled up about 80% of our work capacity, we are done planning for the week. That’s it! The reason why we don’t aim for 100% of our capacity is so that we leave some wiggle room for emergencies that we might have to deal with during the week, or perhaps roadblocks that we couldn’t anticipate. Then, during the week, we keep updating the progress bar for each item we work on, until we’re done with them and we clear the first quadrant. Hopefully, this will happen before the end of the week!
Scrum is a popular planning and scheduling methodology that is being widely adopted across several industries. At Appfluence, we implement Scrum using Priority Matrix, as we try to put ourselves in our customers’ shoes by using our own tools. We try to maintain a fast paced development cycle that matches our quickly changing environment, and these tools fit the bill perfectly.
We hope you find this article useful. If you know a better way to implement Scrum, or simply have anything to share with the Priority Matrix community, please add a comment below. In a future post, we will discuss about the nuances of keeping a short planning and execution cycle while keeping an eye on the long term goal.