Somewhere have read “The art of coaching is to do with the context of your coaching and the dynamics of the way you engage together with Team.”
This article is my coaching experience with few teams who were Doing Agile and later transformed themselves to Being Agile.
This Simplest way to put this is by asking a question, do we just work as its said in Scrum or do we follow it by the Soul.
Let’s take examples by looking into the Ceremonies Team are running in Scrum
Daily Stand-up
Doing Agile:
A call which runs without time boxed, it is a status call for Management. Solutions are being sought on the same call.
Few Scenarios which would like to share when was working with different teams
Scenario 1: A team which started a meeting wherein the participant where not only Team members but also Project Manager (people reporting). The discussion starts with status and after every point Manager started pitching to ask questions. This made the call go longer without timeboxed as well made this more of a Management status call.
Scenario 2: A team started a meeting by sharing the updates and later also discussing the same in detail. Impediments where discuss in detail with a focus to find the solution within the call.
Scenario 3: A team started a meeting by sharing the updates and later Coach started sharing the best practices of doing the call in the better way.
Scenario 4: A Distributed/Different Vendor team started a meeting by sharing the updates and later arguing on the assignments/defects in a queue as well requirements.
Being Agile:
A time-boxed 15 mins call which helps team to get to know what other team member have achieved till now, what they plan to achieve till next discussion as well if any impediment’s they have.
Not only this has saved time for themselves but also has helped them to improve productivity as they were able to focus on value driven activity.
This also helps team to focus on impediments.
Sprint Planning
Doing Agile:
A meeting where leads discuss on the deliverables and make assignments within the team. This is more of a Push approach wherein team has a hierarchy defined.
Scenario 1: Leads with PO discuss the requirements and further breaks it down to make estimation and assign them to team members. Team get to know the assignment and has no say in the estimation. The deliverable has to be completed in given estimation and explanation is sought if not able to achieve it within estimates.
Scenario 2: PO/PM (Project Manager playing Proxy PO) inform the requirements and breaks it down to estimate. Assignment of the work is done to team members by PO/PM.The deliverable has to be completed in given estimation and explanation is sought if not able to achieve it within estimates.
Being Agile:
A collaborative discussion by the whole team with PO on the deliverables, estimating them with story points and self-assignment of deliverables to bring ownership/accountability within themselves (a Pull Approach). Detail discussion to break down at task level to understand the deliverable feasibility as well help them understand Business Value to be Derivable with Sprint Goal.
Sprint Review
Doing Agile:
A meeting to inform Management that the Sprint is completed.
Scenario 1: A lead sends a report of stories completed to PO/PM and informs them the Sprint Closure.
Scenario 2: The team works on the Sprint and create all the documents. A walkthrough is done with PO/PM on the documents and Sprint is closed.
Scenario 3: The team is not focused on the Working Software as per the acceptance criteria.
Being Agile:
A forum for Team to showcase the capability/product/feature build during the Sprint. This is showed against the acceptance criteria which helps understand the business value to be delivered. Also, help PO understand the capability is built with quality by showcasing DOD.
Sprint Retrospection
Doing Agile:
A session talking about others mistake and pinpointing about failures.
Scenario 1: The session is full of chaos and team is just focus on failures.
Scenario 2: Team are skipping this session as this is not adding any values
Scenario 3: A team is not focused on closing any actions which are listed after details discussion which leads to repetitive issue’s problems.
Scenario 4: The team is not focused on articulating the Problem statement which will help them come up with the action list.
Scenario 5: They treat this as another meeting and are silent though the whole session as PO is from the Client side. Also, have seen they only talk about good part rather than sharing the issues and challenges.
Being Agile:
A collaborative discussion on what has went well during sprint, what can be improved. This is the best approach for sharing the feedback and focus on the Continuous Improvement. There have been many ways to approach retrospection Boat/Theme/Top 5 etc.
Being Agile is to understand what values can be brought out from every minute we spend on the job. If we see no value in doing the action, we should ask ourselves shall we do it?
Being Agile also help bring Ownership of the derivable and accountable of the quality expected by the client. It helps teams to come out of Hierarchy within, which paves a path for the self-organizing team. It also helps a team to showcase the Working Software rather focusing on Documentation.
Best part of Being Agile is it brings Joy at Work.
