RetroOnAgile helped us learn about what works and what could be improved about agile software development. Read about our findings and the Agility project.
On May 10th, 2018 one of the authors of the agile manifesto stated publicly that “Developers Should Abandon Agile.” The author, Ron Jeffries, says that “named” agile frameworks, like scrum and kanban, have strayed far from the agile principles and no longer serve developers. He wants developers to refocus on the agile principles, and abandon such agile frameworks.
After spending the last six months asking customers about agile practices, we discovered his insights to be prescient. Having these conversations is an ongoing effort for us, something we call the #RetroOnAgile. We’re asking people at events, online, and on social media to reflect on their agile practice and engage in a massive, global retrospective. The response has been overwhelming!
Our exploration started innocently enough. We wanted to know what worked well and what could be improved about agile software development. We wanted our customers to share their successes and their struggles. As the makers of an agile tool, we thought we might be able to make the highs a little bit higher and lows a little less low. While many of our customers took this opportunity to give us feedback on Jira, Bitbucket, and other products, many more did something else entirely.
This is bigger than us
The vast majority of participants shared their frustrations with agile at the highest level. Michelle wished that, “Agile was re-branded/re-named so people don’t assume it means “work really fast without thinking.” Amy wished that “more folks followed the Agile principles and values rather than trying to hammer away on process and methodology.” Charles wondered “What if we stopped using ‘agile’ as a f@!king noun?” Guilty as charged 😂
#whatif more people believe agile is more about the principles than having daily standup meetings… #RetroOnAgile
— Lizzie Darville (@ledarville) January 9, 2018
There were hundreds of positive messages too! Mike liked “that our agile process involves hypotheses, experimentation, measurement, and outcomes other than “we’ve shipped it.” MJ likes, “that the focus of software development has changed from delivering software to delivering value.” Richard likes, “working smarter and seeing solutions evolve through collaboration.”
#ILike the conversations that we have as a result of our agile process, which help us clarify assumptions and gaps in reasoning #RetroOnAgile
— e dub (@NearSideSays) April 16, 2018
And then there were the ideas. From the super-tactical to the mind-boggling, our customers entertained us and the world with some fantastic hopes for the future. Gonzalo wonders, “What if some agile techniques were taught early in schools so kids could benefit from them and learn how to plan homework efficiently?” Esther pondered, “What if we could make our agile board three dimensional? What other dimension would we add?” Nicole echoed dozens of others when wondering, “What if the whole company practiced agile, not just the developers? What would our teams look like? What could our teams accomplish?”
https://twitter.com/BuiWonder/status/976616447467122688
The little big thing
One of the main things people complained about were agile frameworks. This is the what Ron Jeffries was talking about. Frameworks, like scrum and kanban, are guidelines for practical implementation of the agile principles. We learned that each of these frameworks come with a lot of baggage. To do scrum you had to hire a scrum master. Kanban boards should be pull systems only. These structures and processes, while excellent for some, don’t work for all teams. Being agile is so much more than doing scrum, and therein lies the little big thing.
The little big thing is giving people another option. So we launched an experiment. The experiment was creating a third choice, in our products, that borrowed the best from scrum and kanban. This third framework was new, free from any rules and dogma. Free to be whatever you made it. We built this framework with one goal in mind, helping teams move quickly and easily. That’s why we called it Agility.
How Agility Boards work(ed)
Agility was a beta experience. We gave teams a simple and flexible board–a board that’s designed to get everyone in and moving. Then, as the team became more comfortable with the board, we made it dead simple to add and remove structure and modify processes. Teams could now adjust any aspect of their team’s style of work in seconds, giving them speed and confidence from the moment they jump into their first project. Compared to a scrum project template with a bunch of built-in process, agility projects felt light as a feather.
Agility projects began with a minimalist board that allowed teams to create their workflow in context and on the fly. These boards also came out-of-the-box with smart filters, swimlanes, and the ability to create new issues, all without leaving the board itself.
By bringing features and functionality that were previously housed elsewhere in Jira Software to the board, teams using Jira Software (and especially newly formed teams, or teams new to the product) saved valuable hours as they learned how their team was most efficient. Any team member could make changes to the team’s workflow, meaning less time digging around in project settings and more time focused on the work at hand.
Applying what we learned
After months in beta we were ready to roll what we learned into Jira Cloud. Agility projects taught us that the board is the source of truth, so teams should be able to make important, even structural, changes from the board, not a settings menu. We saw teams be more successful with a flexible agile tool, not a rigid one. We’re now rolling additional flexibility into Jira. We saw that teams stuck around longer with the Agility project, and that they mastered the basics quicker. That was the kicker.
We were very pleased. We didn’t just find a way to get more people to use Jira, we found a way to introduce more people to agile. We believe that way that these boards encouraged people to work brought them closer to the agile values. We no longer felt like we were helping scrum teams do scrum, we are helping all teams do agile.
Making Agile agile again
Internally, we have a phrase we throw around, “Capital-A Agile.” We use this phrase to call out things that add unnecessary overhead or complexity to an agile project. The phrase reminds us that agile is not a proper noun, with proper rules and requirements, and that we should do what right for the team. We learned that Capital-A Agile is effecting people outside of Atlassian, and that we are in a great position to inspire change. We initially tackled this with agility projects in Jira Software Cloud. Nowadays, it’s just Jira.
And we need your help. From seasoned agile practitioners to newbies, we need people to try the new project experience in Jira Software Cloud. It’s free to sign up and trial, and we’re anxious to learn even more. We’re monitoring the #RetroOnAgile hashtag on Twitter and have an Atlassian Community group specifically for Agility feedback. Chime in!
Go play around. We hope you like what you see.