Agile Project Management with Scrum: The Kinto Way
Using Agile Project Management with Scrum
You could build the fastest computer around and still get nowhere if you fail to install an OS. Similarly, the wrong management style can doom even the greatest projects. In software development, waterfall used to be the standard. Now? Not so much. At KintoHub we use agile project management with scrum and a little kanban. But, why?
What is Agile Project Management with Scrum?
Before we get too far ahead of ourselves, let’s talk agile, which is often confused with scrum. To understand agile and scrum, it’s also important to understand what the traditional waterfall method is.
In the traditional waterfall project management style, things are developed in large linear stages. You conceptualize something, design it, implement it, and test it before delivering a final product. In engineering this can be great. In software? Not as much.
If you’re developing a piece of software using the waterfall method, you often end up waiting on the previous phase to be completed before the next phase can begin. This can result in a bug making its way to a late-stage product, and end up costing significantly more than if the bug were caught early on. This also prevents you from being able to test multiple features at once, as you’re waiting on the earlier stages to complete.
Agile development follows a similar pattern to waterfall, but on a smaller and quicker scale. Rather than focus on delivering a fully-functional product or piece of software, agile focuses on small, iterative sprints. The end goal of these sprints is to have a minimum viable product that can be tested and broken.
This approach allows for quickly adding in features, ironing out bugs as you go, and changing to meet the market if need be. While not as appropriate for a field like engineering, it’s great for developing software.There is a risk of feature creep occuring when using agile, so it’s important to watch your budget and make sure you don’t get carried away.
Scrum is an implementation of agile which revolves around sprints. Sprints are short periods during which certain goals and parameters are set forth.
Before a sprint the team will discuss what it is they hope to accomplish, how they plan on going about it, and how long the sprint will be. They then set out on their sprint for the determined amount of time and develop a feature or section of the product or software.
Once the sprint is over they’ll review what was accomplished, what roadblocks they encountered, what worked well, and what they learned for the next sprint. This process is repeated until the product is finished and ready to launch.
The biggest perk of the scrum method is that individual features can be quickly developed and iterated upon throughout the entire development of a piece of software.
Kanban is another implementation of agile methodology, similar to scrum. Unlike scrum, Kanban relies on visualizing items in a workflow, limiting the amount of tasks that can be in progress at once, and immediately moving onto the next task when the previous one is finished. There’s no sprint period like scrum, but instead a focus on continuous delivery of work.
This hierarchical approach coupled with Kanban’s continuous delivery and permittance of making changes mid-process results in quick and fluid development.
The characteristics of Kanban make it ideal for environments where work can’t be finished it chunks and pushed aside, but instead must be constantly moving forward. This can be especially effective in smaller companies, where job roles are more fluid and responsibilities are shared.
The Software Development Method of KintoHub
There’s no particular development method that’s wrong, nor is one completely right for every business or project. At Kintohub we deal in microservices, which are themselves made to be agile and flexible.
As a startup, we have to be incredibly efficient at Kintohub, as every moment counts. To make this happen we’ve adopted a unique blend of agile, scrum, and Kanban as follows:
Scrum for Feature Development
In any software development, feature creep is always a looming fear of the team.
Feature creep is the constant addition of features to the point the product either never gets released, or the overall product comes out in an unfinished state because of the features that were added. It’s not uncommon in software development, as new ideas are often thought of throughout the development process.
Unlike Kanban, scrum doesn’t allow for changes to the process during a sprint. Because of this, we use scrum during the feature development process, as it doesn’t leave any room for the addition of new features mid-dev cycle.
This also ensures we stay on track and knock out a particular feature in a set window, as sprints are incredibly regimented with no wiggle room.
Kanban for Bug Squashing
As you can imagine, developing a new feature during a regimented sprint can result in bugs. Bugs are unavoidable during any dev process, let alone one as fast-paced as a scrum environment. In fact, we count on bugs in our agile office.
To squash bugs we use the kanban method. Bugs can be highly unpredictable in nature, so using the regimented scrum structure for bug hunting doesn’t make sense here. Instead, we divide into numerous teams to ensure features are always being developed, but bugs are always being squashed.
Our dedicated bug hunters will pretend they’re the user and use the software as such. They’ll also do everything they can to break the software. (Much like many users!) If a bug is found they then do their best to kill it.
Finding Your Project Management Groove
You’ll likely never perfect your project management style, especially in the software world. You’ll find something that works for you, in that moment, and roll with it until it stop rolling. Even now we’re refining our project management style.
Before we launched we primarily used scrum. In those early, pre-launch stages, getting anything on the board is important. We didn’t want any kind of feature creep to occur, so we made sure we stuck with strict two-week sprints. We would still open the floor for discussing new features, but our focus was on making progress.
Now we can embrace the scrum and kanban mishmash we’ve created. It allows for quick progress but the flexibility to experiment more with new features. To figure out which method will work best for your company, try each one out for a small period of time.
While a trial of scrum can be difficult due to its already-short nature, use it for one or two weeks and see if your team makes noticeable progress. If things feel a little too regimented, maybe kanban is a better fit for your team. Or, like Kintohub, maybe you need to find something in between.
That’s the beauty of software dev: nothing ever works all the time.