Ten Experiments Every Agile Team Should Try Once in a Lifetime
In the universe of The Witcher, written by Polish author Andrzej Sapkowski, the mages ran tough experiments on a selected group of their population. The idea was to create courageous warriors who could use their magic to confront and exterminate the numerous monsters threatening them. Through trial and error, the first five ‘witchers’ were made. Each ‘witcher’ then started their own school and trained the next generation to be even stronger and more ruthless than them, in preparation for times to come.
Experiments are an incredibly powerful tool in any field. When carrying out an experiment, failure is allowed. Nobody really knows what the result is going to be, and nobody can guarantee the expected outcome. We often live in fear of uncertainty and the unknown. However, when experimenting, these are things you are forced to accept and embrace.
There is a very well-known list of agile patterns and key premises that every agile team is familiar with, being the customer the primary focus. This is true during both the early stages and then the continuous delivery of valuable software.
Instead of a command-and-control mechanism, there is a continuous collaboration. This means ‘internal’ collaboration within the agile team, but also collaboration with the customer and stakeholders. It involves constantly measuring the success of the working software. It means accepting change as a source of innovation, a fundamental part of the iterative and incremental processes.
Embracing change means we avoid following the same rules and playing by the book. It means moving away from old behavioural habits and starting new ones. With that idea in mind, this article provides an interesting list of experiments to try.
When carrying out all these experiments, it’s important to ensure you keep them isolated so you can measure the real impact. It’s also important to be aware that they may or may not work within your team, depending on their maturity, experience, and knowledge. The main thing is precisely to try. So, here are ten inspiring suggestions for your agile team.
No Estimates
The ‘No Estimates movement’ is the idea that there is no need to estimate tasks within an agile team since this is mainly considered ‘waste’.
It’s obvious that estimations promote understanding about the task in question. They clarify missing requirements and are a starting point for valuable conversations.
However, whilst your team may be giving estimations of efforts in time, T-shirt sizes, or Story Points, estimates are difficult. Accuracy becomes practically impossible most of the time. So, why not, at least temporarily, join the ‘No Estimates movement’ and see what happens?
Team alliances
Agile teams often undergo change. This can be either because a new team is being created due to an emerging need, because a new team member is added to an existing team, or because members leave. So, wouldn’t it be better to establish a team alliance to ensure strong and healthy boundaries within the team itself?
People have their own beliefs and values so it is unlikely that different people will automatically form an effective team without creating some ‘ground rules’ and working agreements. Team alliances help to avoid future conflicts and increase a sense of team commitment.
Teams can benefit substantially when agreeing on the guidelines related to the following:
- Decision-making, to choose between either a majority or a consensus approach, depending on the topic.
- Behaviour, to determine the team atmosphere and the day-to-day dynamics.
- Conflict management, to know how to face internal or even external issues.
1–2–4-All Liberating Structure
Liberating Structures are a collection of group processes, techniques, and methods. They make it simple and quick for groups of any size to radically change how they interact and work together. 1–2–4-All is currently one of the most popular by far.
This Liberating Structure allows you to create safe spaces where everyone is talking, and everyone is listening. This is preferable to having just a few loud voices taking up all the airtime. You can immediately include every single team member, regardless of how large the team is. This stimulates creativity and increases engagement.
Now video communication tools integrate ‘breakout rooms’, its use cannot be easier. But how does 1–2–4-All work?
- Silent self-reflection by individuals on a shared topic, challenge or issue for 1 minute
- Generate ideas in pairs, building them on from self-reflection for 2 minutes
- Share and develop ideas from your pair in foursomes for 4 minutes
- Each foursome shares one important idea with all for 5 minutes
Scrumban
You are probably very familiar with both Scrum and Kanban, but what about Scrumban? Does this bring the best of both worlds together?
This agile approach uses Scrum as a framework and Kanban for process improvement. This means combining the iteration-based structure of Scrum and the fundamental principles of visualisation and ‘Work in Progress’ limit of Kanban.
Teams work in iterations but there is no need to plan tasks for each; they simply pull items from the Product Backlog based on priority. This way we will have a continuous flow of work with short planning cycles to add more tasks to the Product Backlog, as required. With regards to team roles, there are no predefined roles in Scrumban, but the team may choose to keep those they already have.
Bear in mind that Scrumban is not an ‘official framework’. Therefore, there is no single definition around it. In fact, you may find other interpretations where iterations are not used at all.
Pair programming
Pair programming is widespread nowadays but, unfortunately, most teams are doing it wrong. Pair programming is a social skill that takes time to master. Don’t expect people to be good at it from the start.
Did you know there are different pair programming techniques?
- Driver and Navigator, which means one person is coding (Driver) and the other is offering guidance (Navigator) switching roles regularly
- Ping Pong, where on developer writes a failing test (Ping) and the other developer writes the implementation to make it pass (Pong) and vice versa
- Strong-Style Pairing, being the most ‘Navigator’ always the most experienced person meanwhile the ‘Driver’ is a novice
Lessons learnt from my experience include avoiding doing pair programming over every single task. This way you will also avoid going mad. In addition, you should agree in advance on how disagreement will be resolved and who will have the ‘casting vote’.
You can also do Mob programming where the whole team may work on the same task at the same time, instead of working in pairs. This fosters positive team dynamics and collaboration.
Dual Track Agile
Dual-Track Agile means a continuous flow of product discovery and product delivery by the same team. Designers should be focused full-time on the team. This ensures scalability and better ‘time to market’.
The discovery lane identifies the problem. It works on solutions. It creates designs, and then when those are validated, they go to the delivery lane. This is where product development begins.
Although both tracks seem to be separated, interaction will still happen daily between designers, developers, and other roles. This is not only to ensure that designs are being implemented properly. It is also to ensure that those solutions are technically feasible.
Give Kudos
This popular agile practice is about giving positive feedback to your colleagues. Kudos is a written and public recognition of a teammate for something they have contributed to the team. In fact, Kudos may be given across the whole company. Anyone can recognise someone else’s work. This is a practice which has high intrinsic value for the team.
Some organisations are creating a kudos wall, proudly on show all the time. Others are looking to build a physical Kudo Box, in which they store the Kudo Cards. In these Kudo Cards people give thanks to others, praising their achievements.
Every now and then this Kudo Box (or other online mechanism if the team is working remotely), is emptied and the team members celebrate those who have received a card, reading it out loud. This may be once per day, or once per week, the implementations vary across organisations.
In summary, this Management 3.0 practice will help to promote a culture of appreciation and positivity. Kudos recognises the individual accomplishments. It also reminds us that when we combine our individual successes, we create a successful team.
Limit Work in Progress
Either using Scrum or Kanban, limiting ‘Work in Progress’ will help to identify bottlenecks more effectively. This increases focus , and ‘cycle time’ will be drastically reduced.
When limiting the total amount of tasks already ‘started’ through a fixed constraint, the team will have a better understanding of the work that needs to be done within a stipulated time frame, typically a Sprint. This way they can predict more accurately how far they are from getting there.
Note that the ‘Work in Progress’ limit should remain as it is being inspected and adapted, if needed, after every iteration. However, there is nothing stopping the team from adjusting it at any point during the Sprint.
Scrumming the Scrum
Process improvement is a primary goal in the Scrum framework. Therefore, one of its authors, Jeff Sutherland, came up with a small twist on that.
The ‘Scrumming the Scrum’ agile pattern is aimed at identifying the single most important improvement at the Sprint Retrospective and getting it done before the end of the next Sprint.
To do that, add the improvement to the Sprint Backlog like any other Product Backlog Item. This includes the Acceptance Criteria, which will determine when it is ‘done’. Then, evaluate the status of the issue in the Sprint Review like any other item.
You may want to use the next Sprint Retrospective to review how useful this was and if improvements are being addressed in a more agile way.
Team happiness
Happier teams, whether they deliver software or not, are far more productive. This has been demonstrated over and over again.
According to Jessica Pryce-Jones, author of Happiness at Work, happier teams are 50% more motivated. Their engagement and commitment are greater. Team members will be more motivated to do creative work more efficiently. In short, they perform much better.
There are multiple ways of measuring team happiness, either using a scale from 1 to 5 or from 1 to 10. You can track happiness daily or every certain time, taking advantage of the Sprint Retrospective if you are working with Scrum.
You could even use a Niko-Niko calendar, consisting of a calendar with a row for each team member and a column for each day. Here members will draw a face in the corresponding box to indicate their daily mood, which will be ‘happy’, ‘so-so’ or ‘sad’.
Happiness may provide only a very limited understanding of a team’s perception of their well-being, though. Team morale may be a less biased measurement. It is less subjective, more task-oriented and less susceptible to mood.
Is there a better way to embrace change?
One of the four values of the renowned Manifesto for Agile Software Development says that responding to a change should prevail over following a plan.
Is there a better way to embrace change and innovation than experimenting? There are so many different paths to accomplishing the same goal. The only way to get there is trial and error.
I encourage you to give these ten agile experiments a go. Test them, tweak them. Try to get them to work for you, your team, and your company. It means time, some sacrifices, and trade-offs, but the outcome might well be worth it!
