The Agile Process: Adding Value Iteratively for MSPs
The storied origins of the Agile process for software development began when the “Snowbird 17” met in 2001 to find a better, more timely way to please customers than the traditional waterfall methodology. The resulting Agile Manifesto formed the basis of the Agile movement—a methodology for working in teams on bite-size projects that get you closer to satisfying customers, faster, with the ability to immediately adjust your target if needed.
Twenty years later, the Agile process still reigns supreme for software development, and is making its way into project management teams across a number of other industries.
“For Liongard, the Agile process is actually part of our DNA,” says Dylan Barth, Liongard’s Director of Software Engineering. It drives four of Liongard’s five core values:
- Execute as a Team: Collaborate to all row in the same direction.
- Focus on Visible Progress: Commit to excellence through iteration.
- Listen and Learn: Focus on learning, not perfection.
- Adapt and Automate: Respond to what’s been learned.
Whether it’s through our Partner Council that meets with the executive team to provide input, our Ideas Portal and Slack Channel, or our Product Research team reaching out directly to partners, we’re always seeking feedback that our software engineering teams can make a reality.
Here’s a peek at how we work iteratively to continuously add value to our platform for MSPs.
The Scrum Framework & Agile Team Roles
“’Scrum’ falls under the ‘Agile’ umbrella,” Barth explains, “and involves the Agile teams working in ‘Sprints’ of time to accomplish a project (or part of a project).” The main goal of Scrum is to ensure we’re always making visible progress.
The Liongard software engineering group currently consists of three Agile teams who work in two-week Sprints. Formally, the Agile framework assigns the following names to each role in a team:
- Product Owner: This is a member of the Product Management team, who represents the “customer voice” and distills their learnings into a long-term roadmap.
- Scrum Master: For our Agile teams, this is the lead engineer, who removes roadblocks from the process so progress can be made. He or she also makes sure everyone follows the Agile process.
- Development Team: These are the engineers who execute on the plan for the Sprint.
The Inner Workings of a Sprint
Every two-week Sprint at Liongard is engineered to be as efficient and effective as possible, following a proper flow:
1. The Product Team distills Partner needs and feedback into ‘User Stories,’ which frame the needs in an easy-to-understand way. An example of a Liongard User Story for a built-in reporting feature might start with, “As an MSP owner, I need a detailed report across all environments I manage for specific systems.”
“With this iterative process, we’re trying to break it down into small enough pieces that we can successfully execute in the two-week Sprints,” Barth says.
2. The Product Owner brings these User Stories to the Scrum team. Each team member then estimates the amount of time and effort it will take to complete this iteration, using a metric called ‘Story Points.’ (Basically, a made-up metric in the world of Agile; this estimating method becomes more and more accurate and meaningful as your Agile team completes more and more Sprints.)
If there is a consensus on how many Story Points are involved, the team moves forward with a Sprint plan; if not, they discuss where the disconnect is.
3. “During the two-week Sprint, we have what the Agile framework calls ‘Rituals’ or ‘Ceremonies,’ which are just fancy ways to say we have meetings,” Barth says. “The heartbeat of the Sprint is the Standup Meeting (or Scrum Meeting). For 15 minutes every morning, each Agile team gives updates, plans for the day, addresses any roadblocks and deduces the most important thing to work on.”
A ‘Sprint Board’ is used to keep all the User Stories and progress visible, and the Development Team refers back to it on a daily basis.
4. At the end of a Sprint cycle comes a ‘Retrospective,’ where the team reflects on the past two weeks—what went well, what improvements can be made to the process, what needs to be re-prioritized, etc.
For more on the formal Agile process, check out Atlassian’s free and thorough guide here.
If all of these formal terms make you feel like you’re playing Buzzword Bingo, rest assured—being Agile is really not complicated:
Listen, work iteratively, and always adjust your aim to the constantly moving target of your customers’ needs.
Customer Benefits of Liongard’s Iterative, Agile Process
First and foremost, this way of working allows Liongard to constantly be listening to and innovating for our customers, at the fastest pace possible. “By using these small, focused movements, you can move quite quickly,” notes Barth.
Aside from getting features and capabilities added to the platform faster, using Agile also shows our partners that we care about what they need. “We’re investing a lot in the feedback process, and then executing on that input. It allows us to be responsive, and also reprioritize based on what we’re hearing,” says Barth.
The Agile framework also helps Liongard team members to have their collective finger on the pulse of what will be delivered, and when. This helps everyone do their jobs better, from our sales and marketing teams, to our support technicians and those working on release notes, documentation and beyond.
“It helps everyone stay educated,” Barth explains, “and results in fewer surprises across the company.”
Experience the fruits of Liongard’s Agile framework—request a demo of our advanced automation platform today. Plus, keep your eyes peeled for Part 2 of our series on The Agile Process, where we’ll show you how your MSP can put this framework to use in your day-to-day processes for stellar results.
Guest blog courtesy of Liongard. Read more guest blogs from Liongard here.