Agile is more than just a fancy Buzzword. Where did it come from? What does it really mean? How can you best use it to maximize success?
In early 2001 (I still say that in my head like it was a few years ago), a group of developers met in a ski lodge in Utah to draft what we now refer to as the Manifesto for Agile Software Development. Now this might sound like a ski vacation disguised as a corporate retreat, but what came out of that weekend was much more than some guiding principles. For developers, this is their Declaration of Independence and their Constitution. The Manifesto has stood the test of time and is more popular today than ever, but is it being used as the Founding Fathers intended? Too often today companies like to throw around words like Agile, Scrum, Waterfall, and Iterative development without fully understanding exactly what those terms mean and more importantly how to successfully execute them.
For the sake of our discussion, we will focus on Scrum: an iterative and incremental branch of the Agile Development Framework. Admittedly, that is what we practice here at stable|kernel. Note that I said practice because operating within any development framework is a continued commitment that takes work. I always attempt to abide by the 80% rule; if you can follow 80% of the guidelines, you are doing a damn fine job. You should always strive to become more disciplined with the process, but primary adoption of the foundational framework is the key to success.
Let’s start with some basic details to make sure we are all on the same page. First, we must understand each individual’s role in the Scrum process.
Product Owner (PO)
This is your product master. The information expert. POs are responsible for delivering value to the business through end-user features and satisfaction. They represent the business side of the development, and they understand the stakeholder’s needs and concerns. Their job is to constantly convey the priority of features/functionality to the development team. The PO understands the roadmap and the stakeholder’s long-term goals and therefore, they will negotiate and educate stakeholders to set priorities, balance funding, and track the schedule.
The PO is not a stakeholder. Companies tend to mistakenly blend the Product Owner role with other positions. Sometimes enterprises assign a stakeholder or a lead developer to a PO role; they think this person can fill these shoes. Other times the project manager will absorb the responsibilities of this role. It’s important to understand that the Product Owner needs to be able to both push back and empathize with various individuals within the project. He or she needs to understand all sides and guide the group to the greatest outcome. For these reasons, it’s best if this is a dedicated role so the Product Owner is not conflicted with other obligations. They can be thought of as an air traffic controller. PO’s have eyes on everything; they queue every item up, understand priorities, dependencies, and overall keep everyone on track. When you understand their responsibilities it helps to clarify why you need their undivided attention.
I hope this one is pretty obvious. This is your team of developers, you know who… well…. develop. Honestly, we all know they do far more than that. Make no mistake they give you exactly what you ask for. There may be several different roles within a developer team, but the team operates as a single unit. For Agile it’s important to keep your team small; 3-9 is recommended. If a larger team is needed then it should be broken out into two unique teams. The development team needs autonomy, it’s important for them to step aside from the entire project and make democratic team decisions. They should have clear, concise and achievable deliverables.
A few important things to remember about your development team(s). These individuals are humans. They are not the make or break of your product. If they are not delivering more often than not, it’s a break further up the chain and the accountability falls on a different team. Development teams are often the catch-all for upstream mistakes, shortcuts, poor communication, and the list goes on. Maximize your attention and input to the development team and they will maximize their output.
Think of the scene in Office Space and you, the Scrum master, are sitting across the table from “The Bob’s” trying to explain what it is you do, “I’m a people person dammit.” Ok so it’s not exactly that bad, but the point is this role sits right between the project managers and the development team. Think of a clerk at one of those self-checkout registers (stick with me, their role is more important than that). The clerk, for the most part, keeps an eye on you, ensures the machine isn’t holding you up, makes sure you aren’t trying to sneak one by the machine and maintains a frictionless interaction between both parties. Imagine I take that clerk away. Now it’s just you and the machine. Things might be going smooth for a bit and then all of the sudden BEEP, “place your item in the bagging area.” Screen freezes. You can’t do anything. Can’t go back, can’t continue forward. “I put the item in the bagging area you (favorite curse word)!” Next thing you know, you are having a full-blown, toddler-style meltdown in the middle of Home Depot. “I need help over here, someone, anyone, please help.” Let the Scrum Master help you, they will maximize your team’s harmony.
The saying goes something like; Anything worth doing is worth doing right. Enter the Scrum Master who is responsible for ensuring the process is followed correctly. They have been referred to as a “servant-leader.” As rough as their role may sound, it is a key part of the entire framework. They act as a buffer or facilitator. Think of them as a guide leading the entire group (development team, stakeholders, POs, etc.) and facilitating the maximization of everyone’s individual performance. They use their intelligence and well-versed knowledge of the process to constantly maintain awareness of every moving part. The Scrum Master is the person in the meeting capturing all action items, remembering who they are assigned to, when they are due, who is dependent on which specific action item, and so on. Having a Scrum Master shifts the ownership of the micromanagement from project managers and stakeholders thus allowing them to focus on the big picture. Companies often attempt to absorb this Scrum Master role into existing roles and/or add the responsibility to a current team member. When companies shift to Scrum too often this is the first position to be overlooked.
Next, let’s better understand the workflows that take place. Scrum focuses on an iterative approach. Simply put, Scrum aims to deliver smaller chunks of shippable functionality. Think of it as chopping down a tree. Rather than saying by the end of this month I am going to have this entire tree chopped down, I am saying that this week I will chop off all the limbs, next week I will cut down the trunk, then in week 3 I will pull the stump, and finally on the last week I will haul all the debris away. Sounds simple right. Well maybe with the tree, but once you start talking about software, things get complicated. Understanding the priority of smaller tasks and their impact on the whole deliverable can get confusing. With a tree, it’s easy to understand you aren’t going to haul the debris away before you have made a single cut. But you do have some flexibility in the priority. Maybe you want to cut the whole tree down, then pull the stump, then cut the limbs off, then haul it all debris away. The point is that there is a freedom to prioritize things according to any unique requirements. Everyone, every team, and every project is different; this flexibility allows each to work in the most efficient way for them.
When it comes to software, the aim is to dissect the whole project into small achievable tasks that are prioritized and when combined deliver the entire functionality. These smaller chunks are what we call ‘sprints.’ A sprint represents a couple of things. First, the sprint is a predetermined allotment of time, and second, it is an agreed upon chunk of “shippable” functionality. The first point is pretty straightforward. Basically, the team commits to working on the iteration for however long the sprint is, traditionally 1-4 weeks. The second point is where the complexity starts to come into play. To keep it simple for now the chunk of functionality is committed by the entire team as an achievable goal. A few things are important regarding this item. First, the entire team must buy into the commitment. Second, the deliverable is shippable. Shippable means that at the end of the sprint, it is ready to go. No more testing, no more dependencies, nada. It is ready to roll. That doesn’t mean you have a fully functioning app per say. Maybe all you can do is sign into your app, but beyond that the app may do nothing, though the sign in works. That slice of functionality is done. With every subsequent sprint, functionality can be added and expanded.
Why we do it
The intention of this approach is to help break things down into digestible bites. For a development team and a project as a whole it gives better insight and understanding into how things are progressing. It also protects everyone from overcommitting. Assuming our sprint is two weeks long we start it by saying, this is what we are doing for the next two weeks and we will deliver this by the end of it. The development team, for the most part, will not look further ahead than that sprint’s commitment, in this case, 2 weeks. We are not saying we won’t commit to a larger, future deliverable, we are just focusing on the smaller steps that lead us to that goal. Teams will use this narrowed focus to deliver on the highest priority tasks quickly and efficiently. Any discovery or feedback during that sprint may minimally or drastically impact the subsequent sprints. When the team is only committed to one sprint they are flexible to adjust to any changes or reprioritization of the next sprint all the way up until the point when the next sprint starts.
For us at stable|kernel, practicing Agile allows us to continuously refine our process, deliver greater value to our clients, and build some amazing apps. We are always asking ourselves; does what we are doing makes sense and does it add value for our clients? Agile allows us to validate those questions continuously throughout the lifespan of the project. For our clients, it means that we are building the right things at the right times to support their needs. It means that we are putting value back into their company faster and aligning them for future success.