I love agile, I am a huge advocate, and I feel the language we use when we talk about agile is important. The language we use should help others to understand and convey the sentiment, mindset and approaches of being agile.
Agile Buzzwords convey meaning and sentiment and while some are very much aligned to the agile mindset, some I feel could change and improve to better convey an agile mindset, reduce ambiguity and improve inclusivity within agile teams and organisations.
Skip ahead to 5 minutes if you just want to know which words I would change!
The word adaptive summarizes agile beautifully, being agile is about an adaptive mindset and adaptive methods to help us deal with change and uncertainty.
Retrospective is one of my favourite buzzwords and one of my favourite things to do in agile. If you’re going to take a piece of agile and adopt it, then I’d suggest having a regular retrospective because it’s a really powerful way of shifting our thinking into a reflection mode, and seeing opportunities for improvement while its still possible. There are a huge array of activities, games and tools that you can use. Have a look at Retrospective Sailing, or the Retrospective Wheel.
Flow, another one of my favourite agile buzzwords! Being Agile is all about finding flow, it’s not about doing things as quickly as possible. It’s optimising and maximising our flow, which in turn optimises the cost and the time taken to deliver, and maximises the value delivered in the time and budget available. When we find our flow things flow more smoothly, effectively and sustainably
I love the word iteration, often when introducing agile it’s a word that people haven’t heard before. For me iteration is different to repetition. Repetition is doing something the same over and over again and aiming to get the same result each time, like on a factory line. Whereas iteration is doing the same thing again and again but looking for ways to improve and scale each time, and getting better and better until we find the optimum.
Sprints – The idea of idea of running Sprints rather than marathons is great. Short Sprints of work rather than one long Marathon. It’s a really lovely agile buzzword that people get really quickly.
Slack is an important buzzword that isn’t used enough! Making sure that we’ve got that slack in our sprint for change and improvement as well as the day to day. Slack for ad-hoc work requests that cannot wait until the next sprint, account for a degree of uncertainty in the tasks we have planned to complete, allow time for things that are going to take longer than we first thought.
Swarming a problem. I love the idea of swarming a problem in a positive sense. We’ve got a challenge and an issue on the team and we’re going to swarm that as a team. We’re all going to work together to find a solution to this problem so we can all move forward collectively as a team.
Pivot! It’s perhaps now become one of those agile buzzwords that people aren’t as keen on because it’s a bit overused. Yes we need to pivot, but sometimes we need to persevere too. I do love the sentiment of pivot and persevere which Eric Ries has in his Lean Startup book. I think we need to acknowledge that need to Pivot, but not over-pivot as such and not overuse these things to a point where they become disruptive and hold negative connotations for the team.
MVP, the minimum viable product I often talk about minimum viable solution just because the nature of the teams and organizations that I work with aren’t always using agile to build products. Viable is the keyword for me, that it’s not just about the cheapest, quickest thing that we can get out there. It’s about creating something that’s viable and delivering value and meaning for the customer. I like the idea that an MVP should help us achieve the maximum amount of learning for the least amount of effort. Pareto is a great way to think of this, what 20% of the solution, delivers 80% of the value?
There are lots of great little acronyms within agile. TDD Test driven development and BDD Behaviour driven development are great for encouraging an agile mindset. I love VUCA volatile uncertain complex and ambiguous. Moscow as an acronym the must, should could and won’t or would like to haves as an importance and prioritization planning tool. T-shirt sizes to size things is good fun and a simple way to estimate and gauge the options early in a project.
The Build Measure Learn cycle is really great again and especially if you’re starting something new. I tend to think of it as learn, then build, then measure, then we’ll learn some more from that measurement, and we’ll build more, and we’ll measure it and so on. Eric puts Build first and I think there is a good reason for that because often when we start something new we can get caught up in planning and learning and research. To have that sentiment of building that minimum viable product and getting it out there quickly, and then using that to learn and gain experience to understand and validate our idea is a really great approach. CI, Continuous Improvement, CD, continuous delivery are also great for conveying that sentiment of our projects continuously delivering throughout their lifecycle, not just at the end!
I could go on because they’re so many great agile words and acronyms I love in agile, but really this article is about some of the words and language that I would like to change!
I mentioned VUCA and I think ambiguous is a really good word to explain why I would like to see agile language evolve, because some of the buzzwords, names and phrases used are not quite in tune with the sentiment behind the agile mindset and a culture of agility within a team, the words are ambiguous and can be taken to mean different things.
A title I have wanted to change for a long time is Scrum master. I’ve got nothing against the role of Scrum Master at all, I think it’s an absolutely brilliant role, but I do think it’s misunderstood and I think one of the reasons it is misunderstood is because of its name.
I often talk about Sprint facilitators and somebody who facilitates the Sprint because I think that is a better descriptor of the role of what I feel a Scrum Masters role is. Somebody who helps to support the process of a team being agile, they help to coordinate, organize and facilitate the sprint, but they’re not really involved in deciding the content of the sprint, rather helping others to decide that. They’re not master of anyone, I don’t really know where the sentiment of master came from when the job title was made up. I think of chess master maybe it’s kind of Chess Master and makes me think of the Queens Gambit, somebody who’s a master of a game. Or master as in servers and master server in the technical sense perhaps. Dan North spoke at Agile on the Beach many years ago about Software Mastery in the sense of becoming a master of your trade. Somebody who is really well versed in the the methodologies and the tools and the mindset of agile, a master of agile, agile mastery.
I think role title is ambiguous and not in tune with the sentiment of the role. Master can also imply control and power, it can infer that person is in control of the Scrum. I often meet teams that have a Scrum Master who is setting the team’s work. They are getting involved in deciding the content of the sprint, setting and scheduling work for the Sprint, and for me that’s not the facilitating role of a scrum master. It is also a very masculine title which has always felt odd to me, especially as I know so many women in the role. The job title in itself is misleading and ambiguous and misleading assumptions can be made. For me the title Master is full of ego, it doesn’t say, this is a team player or a facilitator to me. It doesn’t feel equal or inclusive. I would prefer to use the name Sprint facilitator.
Another job title I’d like to change is Product Owner. When I first heard about the role, and we started talking about product owners as a new role idea at agile conferences. The sentiment was that we needed the customer on the team, if we really wanted to be a cross-functional agile team that was inclusive and collaborative, and worked really closely with the customer and the users.
Agile is very orientated to delivering value for the customer and with this in mind the consensus was that the Customer should be on the team, so the owner of the product, the Product Owner would be on the team advising on the priorities of the business and what they wanted next. Informing the team what’s urgent and what’s important, to inform the sprint planning and product development roadmap.
Initially it was it was a good name but the thing is what I’ve seen more and more now is Product Owner as an internal role rather than external role. So you get a product owner on the team who is within the the organization that’s building the product, not the customer, but a representative of the customer.
‘Owner’ as a word and title has power and ego attached to it. I use the title Product Guide because I feel like they are guiding the product and so this is a more descriptive title for the role. If we have got somebody who’s the actual customer in on the team, that’s great, call them the Product Owner, but if they’re don’t actually own the product, it’s an ambiguous word that is misleading. Assumptions are made based on the words that are being used. As the ‘owner’ I may assume responsibility and overall decision making power, I may act in a directive way rather than a collaborative way with the team.
Servant Leader I love as a concept but I have had this title misunderstood many times. Assuming it means, I lead, and the team serve me, I am the leader, they are my servants, rather than I am serving my team. My idea of a servant leader in my mind, is I am here to make sure my team have the resources, skills, environment they need to do their jobs and then trust them to get the job done.
Another one, again a job title is Agile Coach. If we’re thinking about the coaching in the sporting sense the coach isn’t doing the running for the athlete, they are helping them to be the best athlete that they can be, they can’t do it for them, they can’t exactly tell them what to do. What they can do is help them to continuously learn and improve and work it out for themselves, which to me is coaching. If they were telling them exactly what to do they’d be putting a Consulting or Management hat on, or a Mentoring hat if they were sharing their experiences to help inform decisions. So the use of the word coach can be a little bit ambiguous and often agile coaches are more like consultants or managers. I feel if we are there to help a team to be agile then Agile Guide is a better title as it allows us to wear different hats!
I could write a lot more as well about the about some of the job titles in agile and how I think that they could be improved, I have written an article about the various hats I wear as an Agile Guide.
I feel we could change and improve these titles to be more descriptive of their purpose and inclusive in the terminology used.
So moving on to a few other words in agile that I would like to change or improve
It seems somewhat ironic to me we are so adverse to changing agile. The word manifesto I would like to change. I’d rather we use code or guide or guidelines or something like that because manifesto as a word is very absolute and also again ambiguous in its definition. As a word, Manifesto is often used politically. I think we could use a softer word that is a more collaborative and purpose led.
Within the manifesto there is irony because it says that you must not change the manifesto, you must replicate it exactly, you mustn’t change it. Yet agile is a methodology all about continuous change and Improvement. Working solutions over comprehensive documentation, Responding to change over following the plan.
There there’s one keyword that I would change in the manifesto and I have had feedback that that there is agreement on this from people who actually created the manifesto which is that it should be solution in place of software because it makes more sense if we use the word solution rather than software, there is more to a product than software, and it makes it applicable and easier to understand more broadly.
Another thing in the principles that I would very much like to see changed is creating a Constant Pace to maximise performance. I would like to see that change to creating a sustainable Pace to maximise performance, because I don’t think an agile team is about creating a constant Pace. I think it’s about creating flow, and I think it’s about creating a sustainable pace to maintain growth, well-being and performance. We cannot all work constantly all the time, there is a natural ebb and flow to work, sometimes it flows well, sometimes it gets held up. Trying to maintain a constant pace means we are seeing so much burnout happening in tech, its only possible to sustain a high constant pace short term, not long term. We need to be looking at creating a sustainable pace that boosts our growth and our productivity but also sustains our well-being and the quality and performance of the solution.
Stand up meeting I do love the original sentiment of stand up meeting and I used to use it a lot, but I think in the world of remote and hybrid working it doesn’t quite work as well and also again it’s quite ambiguous it has quite negative connotations. Whenever I’ve introduced it as stand up quite often the team will end up changing it and and calling it something else and actually check-ins sticks really well with a lot of teams. Also it doesn’t have to be a daily stand-up every day of the sprint, if you’re only working on a project once a week then you don’t need to be having a daily stand-up.
Agile needs to be moulded to fit and work for your organization and its work, it needs to adapt, change and evolve, that is after all the essence of agile.
Another Agile Buzzword, not in the video, but another that causes confusion is Technical Debt. It is another buzzword I find teams find difficult to grasp the meaning initially and I don’t find that helpful. My understanding is Technical Debt is it is work in the backlog, work we have committed to do but has not been completed yet. It’s unclear to me whether the work has been paid for or not, and whether this is relevant or not to the definition of the phrase. It is work that has been scoped out but that hasn’t yet been delivered, therefore we are indebted to the customer, we owe them, I think this is the source of the phrase. Debt, is a fairly negative word that infers the backlog is a bad thing, outstanding work the team has not completed. However in agile we may not complete everything in the backlog, the backlog for me is a series of options to choose from as we iterate building the solution. We may swap things out if something better comes up we hadn’t considered, we may add to the backlog or we may reduce it.
I tend to lean away from the word Backlog too, it infers delayed work to me. I use the phrase ‘Future work’. In the sense of technical debt, a good use of this would be when we are looking at whether the work will be profitable. Comparing what we have to still build in the backlog to complete the solution for the customer, to the time and money remaining. If there is more in the backlog than time/budget available we are in debt, but if we still have time and budget available after accounting for what’s still to be done, then we are in credit!
We need to be careful about the language and buzzwords that we are using and their varying definitions. How assumptions can be attached to those buzzwords and the different perception and interpretations of the words and language we use.
Agile has been around a long time now and I think we need to have a look and see what we need to change and improve and start to make some of those movements to make sure that agile is diverse inclusive and it thinks about the well-being and the sentiment of agility and the mindset of agility as well as the methods, tools, productivity and performance.
Thanks for reading, please do subscribe to my email below, look me up on LinkedIn and connect, and tune into our YouTube channel.
Start a conversation