As the team starts working together it is important to set ground rules. How do set ground rules with a team working together for months already??
I propose an Agile Working Agreement instead.
This is my second time in such situation. What teams had in common were:
- Have some Agile ceremonies but not well defined
- Carry items from sprint to sprint is a regular occurrence
- Frequently miss deadlines and are unable give accurate updates
- Team of individuals with high output
- Always chasing tails and constantly being interrupted.
One thing that is 100% clear it was not just a development team problem it was also the business side and how they were communicating.
Understand Current Way of Working Remote Agile Team
In the current situation the Agile team have been working in “scrumban” approach over the past 8 few months and I only 1 month ago. My issue with scrumban is that unless you are well oiled machine it is difficult to execute.
Scrumban is an advanced methodology that relies core principles such as setting work in progress limits and having a prioritized backlog. This was not a team with any of these.
They had sprints but no commitment to actually delivering. No daily stand-up. No estimations. No showcases.
They were delivering some awesome stuff though.
They have been delivering week in week out but priorities changed, tasks were added randomly, scope creep was rampant, business treated them as a service center. Very little feedback was provided.
They are also a remote team and access has been limited to some team members. Most interactions was via tech lead, ux lead and CTO.
Gather Insights on Current Agile Way
As a certified scrum master I could easily came in and demanded that we start all the scrum ceremonies but instead I took a back seat and listened. For 3 sprints I have listened and gathered insights. I gave my opinion when asked.
But what I did do was start….
- Documenting what was being released sprint by sprint.
- Following up with business to provide quicker feedback
- Educating business side on Agile processes
- Held a sprint review session with business and team leaders
My initial insights were
- Business didn’t know their priorities
- Feedback from business was vague.
- Being in a sprint doesn’t not mean will get delivered
- No meeting with all team members present
- Couldn’t track progress of tasks
My next job was to explain to business and development teams why this was important to rectify.
Use Current Agile Ceremonies
There was a session booked weekly on Tuesday for 3 heads of dev (CTO, Architect / Tech Lead, UX) and business team which included head of digital ops, CEO and me (head of digital).
On first Tuesday of a sprint I just started asking the question – what do we plan to do in the next sprint. CTO would list all items of work they plan on doing.
Then I simply turned to CEO and asked does that match your priorities?
They didn’t know.
After this meeting we had a follow-up session where we put everything on a board that was in progress and started building a product roadmap. Two week later. We were at our weekly meeting again. The CTO listed what they plan on doing but I did something different.
I pulled up a slidedeck and suggested lets review what we said we would do vs what we completed before we commit to next sprint.
A makeshift sprint review.
Makeshift Sprint Review Meeting
The sprint review highlighted the huge output of the team but also with a simple check or x next to what we thought we were going to complete over the past 2 weeks. This was a 1 page slide deck. Very simple.
It was obvious business priorities changed, we had ops issues on dev side, clear bottlenecks on individuals, user acceptance testing was actually QA.
No blame just discussion to improve.
We created list of lessons learned and moved forward.
This built up trust between me and the tech leaders. Which was critical to get before I started bringing in more processes. Building trust amongst remote teams is a new skill project managers need to work on.
After 2 more sessions of makeshift sprint reviews. They were ready to include all team members.
Instead of following the same format of what we did vs didn’t I wanted start on a clean slate. I left the team speak about how they found working together at the moment. The conversation took a slight detour about lack of resources and needing more people but everybody has this issue. Its not always the solution though.
Funny enough there was one guy who actually had worked in an Agile team previously and had seen it work before and was very vocal on how we should do it. It turns out they were very frustrated on the current way of working.
After venting I moved the team to discuss on how we will be working together going forward. I kept it simple
- Sprint Length
- Expected Sessions – Planning instead of DSU on first Monday and Retro last Friday of the sprint
- Daily Standup Time – Time boxed to 15mins
- Team Roles (use our RACI template) – Scrum Master (me), Product Owner, Tech Lead, QA
We also agreed to hold our first proper team retro and discuss how the changes worked for everyone.
Why Create a Remote Team Working Agreement
The reason I started creating a working agreement was:
- Shared understanding across all team members
- Enable proactive planning by knowing what is expected
- Encourages collaboration to achieve goals
- Increases awareness of individual behaviours and communication styles
Good Reads
These are good references for understanding Agile Team Working Agreements:
- Agile Team Working Agreements How To Guide
- Creating a Team Working Agreement
- Forming, Storming, Norming, and Performing: Understanding the Stages of Team Formation
- Team ground rules and working agreements
- What is a team ground rule or team working agreement
Make it Visual
