In an industry in which the only constant is change, agile is a set of values and principles that help teams focus on delivering the most important increment of business value as soon as possible, knowing that tomorrow’s top priority will likely change. Agile has become the pervasive way to develop software and is largely the foundation for how most business software is built today. The simple, yet effective drive to focus on immediately delivering the most important value has led agile practices to seep into other operational business areas.
Though agile practices have been around since the 1990s, it was not until 2011 that a group of seventeen people met to find common ground and formulate these practices into The Manifesto for Agile Software Development. Reading through the manifesto’s values and principles will shed light onto how agile practices can be more broadly applied to other aspects of a business, even though they were originally created for software development projects.
“Big-A” Agile vs “small-a” agile
Following the inception of the Agile Manifesto, an entire industry was born to provide structure, definition, and training to teams on how to implement agile practices that adhere to the manifesto. Frameworks such as Scrum and Extreme Programming – which existed before the manifesto and helped establish it –have since been joined by additional frameworks and methodologies. Today you can receive a certification in Scrum from Scrum.org or Scrum Alliance and a search on Amazon books for “agile” will have you scrolling for days.
These more formal frameworks that have training programs and certifications are known as “big-A” Agile – a noun representing sets of official Agile practices. While these are certainly important, there also is the other side of agile known as “small-a” agile – an adjective describing the practical application of the Agile Manifesto and official Agile practices to deliver business value.
Think of the difference between the two like making healthy lifestyle changes. “Big-A” Agile would entail reading up on the latest diet trends and exercise programs but will not make a dent until acted upon. Conversely, “small-a” agile is like getting out there and hitting the trail with your running shoes, putting knowledge to work.
“Small-a” agile at Advicent
NaviPlan’s latest release was a huge leap forward with the refresh of our user interface (UI). This project, as we called it, was the Visual Design Update or VDU. Delivering a complete design refresh of a production application as large as NaviPlan is rare and most attempts at such an endeavor end up with only part of the application being updated. The fact that the Advicent team was able to get the entire application updated in an acceptable time frame is a testament to not only our developers’ talent and dedication, but also how we implement agile.
As with most projects, we had been following Big-A Agile practices for a year working on the VDU. Things were progressing steadily, but sometimes one does not realize how much work remains until timelines start to compress. With less than three months to go, we took a moment to step back from the project and analyze how much more there was left to complete. Indeed, without making some changes to our process, there was more to complete than we could get done.
January 24, 2019: 11 weeks away from launch, we pulled together a tiger team of more than 10 individuals to address the remaining backlog of work. This team consisted of a mix of software developers, UI designers, business analysts, quality assurance engineers, and myself as the scrum master. The biggest risks at this point were any additions of unexpected work and adding 10+ additional heads to the project. It’s well known in the software industry that adding this many people this late in a project can cause more chaos than harmony.
February 7, 2019: A foundational agile practice is to deliver software incrementally using time-boxed development iterations. Iterative development supports the fourth value in the Agile Manifesto: “Responding to change over following a plan.” At Advicent we iterate, or sprint, in two-week intervals. As of this date, we had completed a two-week iteration with the new team but were still struggling to know if we would be able to release the VDU on time.
February 8, 2019: At this point, we switched from two-week iterations to daily iterations. This meant that rather than committing to what we could get done in two weeks’ time, we would commit to what we could get done for the next working day. On Friday, February 8th, it meant committing to what we would deliver by Monday morning. Below is a screenshot of the first daily commitment that was sent to our stakeholders. This commitment pace allowed the team to increase transparency as to what was getting completed, allowed for input from stakeholders on any priority adjustments, and to ultimately demonstrate our commitment to immediately delivering the highest value possible.
February 11, 2019: All NaviPlan development work is tracked in a tool named JIRA. JIRA serves our needs well with the previously normal two-week iterations but proved too cumbersome for tracking daily commitments. While not the most elegant solution, we ended up using Excel to track our daily commitments because it was the most frictionless tool we could use to immediately communicate progress. Using the best tool possible to facilitate communications between humans aligns with the first value of the Agile Manifesto: “Individuals and interactions over processes and tools.” Below is a screenshot of the next commitment status email that was sent to stakeholders, complete with color-coded statuses for the previous day’s commitments as well as commitments for the next day.
February 13, 2019: The following screenshot shows a particularly interesting day. The colors indicate as follows:
- Blue - Extra work that was done that was not committed to
- Green - Work completed that was committed to
- Red - Work that was committed to but not complete
In this case, we got nearly as much work done that we did not commit to as work we did commit to but did not finish (red and blue are about equal). While it is good that more work was completed than originally committed to, this shows a slip in discipline. Rather than directing all focus to complete what we committed to, team members started working ahead on new work rather than helping others on existing work. Over the next two months, our daily commitments and these reports would motivate us to increase collaboration amongst the team and not move on to new work unless all commitments had been delivered.
March 3, 2019: All the daily commitments we would make were done at an early morning “stand-up meeting” that often turned into more of a comprehensive 45-minute sit-down meeting. Normally, our two-week iteration cadence would adhere to the Scrum framework which prescribes a daily standup meeting of 15 minutes. This time should be used for the team to touch base and help each other understand where everyone’s progress stands before moving forward.
Our daily standup turned into a much longer meeting because of the detail to which we needed to analyze and coordinate commitments daily. If a team member was not able to complete their previous day’s commitments, we would take extra time to determine what the blockers were and how we could swarm to help complete the commitment today.
This commitment to teamwork even applied to me as the scrum master. March 3rd was the first day I was not able to be present at the stand-up and without missing a beat our UX Manager, Tom, stepped up to take over tracking our commitments and leading the team to make new ones. Having the aesthetic eye that he does, Tom even added his own flair to the day’s commitment update:
April 15, 2019: Launch day. It certainly did not come easy and took a lot of planning and commitment from every member on our team, but on April 15, 2019, we were able to successfully deliver the NaviPlan Visual Design Update.
A few additional notes about our process that were crucial to our success:
- If you look back to our commitment updates, nowhere do you see an individual’s name. This is because we as a team made the decision that all commitments would be collective and the success or failure of the team would not lie on an individual.
- Daily commitments were accepted by the team, not forced on them by management. As the scrum master, I highly encouraged reducing our commitments from weeks to days, but the team could have easily rejected it. Instead, they embraced it.
- The team was never told by management, a product owner, or a scrum master what they would commit to. As a scrum master, I would ask questions about the work to be done and challenge the team to commit only to that which they could get done. Some days this meant challenging the team to take on more, other days it was to take on less. Our goal was to deliver exactly what our capacity would allow for so that we could more predictably plan for a launch date.
Key Takeaways
Following this experience, key takeaways for our process moving forward have been:
1. Stating and sharing our commitments
2. Swarming - helping our teammates ensure we meet those commitments
These items ultimately relate to getting all individuals on the team to focus on the same set of commitments and is one of the most challenging things to do with a group of people. However, in the case of our Visual Design Update, this focus was the key to completing the project.
On future projects we will strive to set firm commitments on the business value we will deliver and share those commitments with the greater organization. Our team will then need to be sure we are limiting the amount of work in progress and to focus on the absolute most important task to deliver the value we committed to. As the example from February 13th shows, we cannot afford to pull in new work if the work value we committed to delivering has not been completed.
I wanted to share the story of the VDU because it is a real-world example of being “small-a” agile rather than following a “big-A” Agile prescription. All of the books and training are important to understand and adopting Agile, but being truly agile, “small-a” agile, is about staying principled to the Agile Manifesto and doing what needs to be done to deliver the highest value as soon as possible. In our case, changing our tooling, meeting format, iteration length, and increasing transparency are what allowed us to deliver a successful launch of the Visual Design Update.
To learn more about the latest release of NaviPlan, click here >