We Need a New Agile

Agile ceremonies are now over 20 years old, they’re from the days when we were all face-to-face in the office & dress down Fridays was the height of employee experience.

I’ve worked in agile software development teams, I’ve worked in agile learning & development teams and I’ve worked training and transitioning teams to move to agile.  Do you know what I’ve never heard developers or content creators say?

"I could get this done faster if I spent more time in meetings."

WHAT IS THE PURPOSE OF AGILE

Moving to agile was the right thing to do, and the ethos and ideology of it still is.  What did we want to achieve with agile?

· Frequent testing, reviews & iterations

· Quick to market through rapid development

· Continuous release and deployment

· Adapt to changing requirements

· Improve on our iterations

As long as we are achieving and aiming towards that purpose, do we have to always do it the same way?  The results and the output are what is important, that is ‘being’ agile.  If we follow rigorous routines and ceremonies, by the book, because that’s the way it’s always been done, then we are only ‘doing’ agile.

As we embrace remote work and collaborative technology, it's clear that spending excessive time in meetings and adhering strictly to traditional agile practices hinders productivity and impedes the completion of meaningful work.  Let’s ‘be’ agile and maximise our outputs.

We need a new agile that is designed for the new working world.

THE WORKPLACE OF TODAY

When we began agile ceremonies, the structures kept us focused and communicating, but they were designed in a different time, before technology advanced and before we had remote, distributed teams.  In today's digital age, the availability of collaborative technology tools has revolutionised the way teams can work together. These tools allow for effective communication, real-time collaboration and documentation sharing, eliminating the need for excessive in-person or virtual meetings. Asynchronous working has become increasingly prevalent, so team members can contribute at their own pace and in their own time zones. We all now have access to a global talent pool of people across the world, we can keep each other updated without having to all be in agile ceremonies all at the same time.  Treat them as the talent they are, and let them work at their own most productive times.

WHAT SHOULD WE DO DIFFERENTLY?

• Re-organise around the purpose of agile, not the mechanics of agile ceremonies
• Centre your working culture for rapid development and meaningful feedback
• Encourage and enable autonomous decision making and initiating improvement ideas
• Flexible and remote working are key to strengthen a diverse team from a global talent pool
• Remove routine meetings and only meet for connection or collaboration
• Embrace knowledge management and asynchronous documentation updates to improve co-working and information sharing across time zones
• Utilise AI tools to accelerate basic code or content creation, using human skills and ingenuity to refine, review and improve
• Utilise Automation software to automate testing, reduce routine tasks and free up your people for meaningful work
• Utilise collaborative technology and data analytics (not meetings) for planning, progress updates, task status, reviews and co-working
• Create a community of super users, customers or beta users who can regularly give you feedback on new features, design and development

But if you must insist on continuing agile scrum ceremonies, there is still a better way…

RETHINKING AGILE CEREMONIES

Standups/Scrums:

This should be primarily done in your team chat of choice, each member provides a simple, concise, and purposeful update.  What they’ve completed, what they’re working on, estimated completion, any blockers.  & then they don’t update the chat again until that update changes.  Let them update when suits them best, and let them stay in the flow of deep work when they need to.

The expectation should be that if there are any blockers, then the relevant people join a call the same day to collaborate on a solution.  If we have new work to showcase or require feedback on, we provide videos or links for people to do that asynchronously. Or you simply say you would like a call to review it with people in real-time.  Trust your teams to know when they need to have conversations.

Backlog Refinement:

Your teams need to know the roadmap, they need to know the priorities, and they need to know where their expertise contributes.  That could be delivered via a short update from leadership or scrum-masters.  A short meeting becomes necessary only when there are significant changes to priorities or new workload.

You should be able to use reporting and your chosen software of choice for capacity planning, and for keeping an eye on any aging stories or technical debt to ensure nothing is missed.

Sprint Planning:

If we’ve communicated our roadmap and priorities effectively, and if we have a transparent and visible board of the work required, then a professional team should be able to autonomously plan their own sprint by bringing in the stories in accordance with their capacity, and in accordance with the deadlines and priorities you’ve advised them of.

Our software, or our team members, should tell us if people have additional capacity or if we need to reprioritise to effectively deliver on the sprint requirements. If so, then we need a conversation with the relevant people only.  A planning meeting doesn’t need to be lengthy with everyone attending. Encourage self-managing teams with the autonomy to plan their own sprints.  Your scrum masters or leadership should then focus on clarifying any ambiguities, aligning expectations, and assigning any remaining tasks efficiently.

Sprint Reviews:

It is still important for teams to showcase their work, for soliciting feedback and for learning best practice from one another. But does it have to be done at the same time each sprint with every team member? Or should we be in the habit of providing demo videos, storyboards or code reviews as and when we complete them, and ask for asynchronous updates?  Are your reviews showcasing new innovative concepts to develop the team or are people just demonstrating their work to prove what they’ve done in the sprint?

By allowing people to review at times convenient to them, it may give us more comprehensive and thoughtful feedback. A sprint review can then focus on demonstrating the value of our deliverables to any key stakeholders outside of the core development team. This is where we get the real value of fast and frequent reviews in an agile development cycle, a sprint review should have the purpose of getting functioning output in front of real users to get real-world feedback.

Sprint Retrospectives:

Similarly, I understand the value of conducting a retrospective to find out what worked, what didn’t, and how we can improve.  But we can do this collaboratively and again asynchronously on whiteboards or documents to capture our comments. It should then be the responsibility of leadership to review and drive the improvement actions into our future ways of working, it’s the output that may require a meeting or a discussion, not the process.

Retro meetings can however, be opportunities to have engaging, meaningful time with the full team which is important as good working relationships are key to being agile. If you do them rarely, and make the format interactive and fast-paced, the time together feels motivational and inspires the team to agree improvement initiatives.  Certainly don’t do them if you’re repeatedly getting the same output from the team, without meaningful action. We want a culture where teams are empowered to put their continuous improvement ideas into play immediately, without having to wait for a meeting or to write it on a board.

If you find you have team members who are not contributing updates, maintaining system data, participating in reviews, or continuous improvement ideas - then that is an individual performance issue that should be detected and addressed by good management practices, not the reason for long team meetings. Long, full team meetings need to be the exception, not the norm, and recurring meetings need to be thrown out down the waterfall.

Sprint Lengths:

Two weeks fly by in the corporate world.  If you are regularly delivering new functional features, or new content, every two weeks, then your sprint length is correct.  But don’t choose two-week sprints because that’s how everyone else does it.  Do you need three- or four-week sprints to effectively deliver meaningful output at the end of it?  Then that’s how long your sprint should be.

A longer sprint length also enables the team to have the time to experiment or innovate, if they have a safe space to try and fail, there is time to try something different and still meet deadlines.  With shorter sprints and the usual velocity or burndown reports being scrutinised, the deadline drives teams to do things the way they have always done them.

Consider using Kanban instead of sprints, which may be a better option for a continuous flow of work towards a longer deadline.

MEETING CULTURE

• Meetings should be held if they are purposeful, educational, collaborative, or relationship building.  Routine meetings should never be a thing, they should be held when required and even then, should be kept short with the aim of reducing workload and increasing output or opportunities for deep work.
• Don’t have meetings for one-way information shares, share the information first and then see if a discussion is required.  Review and collaborate on what you can asynchronously, and meet when more extensive discussions or workshops are required.
• We also tend to fill the time we have available, so make shorter 15 minute meetings the default, providing the necessary information to facilitate decision making in advance.
• Have the right culture in place, with regular communication and updates provided.  Ensure any meetings you do have always have an agenda with the purpose, process and expected outcome stated in advance.
• Encourage people to block time out in their calendars for focus time, and support people in having meeting free days or an expectation to not have too many back-to-back meetings.
• Give your teams a voice in saying how often they want to meet or be communicated with.  Judge people on the quality of their output, not on the hours at a desk or in a meeting.
• Harvard Business Review have a great tool for calculating the cost of meetings, why not see how much you could save: Estimate the Cost of a Meeting with This Calculator (hbr.org)

 

THE FUTURE OF WORK AND POST-AGILE.

As we continue towards remote and distributed work being the norm, we need to re-evaluate the need for Agile ceremonies and excessive meetings.

We also need to reconsider the scrum master role, there are some who are unfortunately just known for facilitating meetings and producing velocity reports, but without ceremonies there is still a place for them, we need the good ones with their problem-solving skills to remove our blockers and get us the key insights and review feedback we need to improve our iterative deployments.

We need to evolve to meet the changing needs of teams and focus on meaningful work. Embracing asynchronous work, rethinking the purpose of meetings, leveraging collaborative tools and utilising cognitive computing trends are key to accelerating productivity and maintaining work-life balance in Agile teams.

Agile is a set of principles, and like any methodology it should be adaptable to the culture of your organisation and of your team. Let’s embrace these changes where it makes sense, teams can ‘be’ agile and continue to deliver high-quality results in the way that suits them. The future of Agile lies in adapting to the demands of the modern workforce, where collaboration is not bound by time or location and the rapid deployment of successful project outcomes is what matters the most.

---