An Agile Health Check is not as simple as scoring User Stories and Acceptance Criteria out of ten (although those materials are definitely a part of the health check analysis).
An objective approach is the driving force of the health check – for example attending Stakeholder meetings where Epics are created, sized, prioritised and elaborated. In addition, Agile Unpacked takes an empathetic view of how the daily Scrums are working, how the Product Owner works with the Agile Team members to decompose Epics, and how they interact and challenge Stakeholders.
The outcome of the health check lists the factors we believe are key to a highly performing Agile Environment, annotated with what’s great, what’s ok, and what needs improving.
In addition we highlight the key items which need addressing to deliver the most impact which can typically be things like communication between PO’s and Stakeholders, articulation of success, and effectiveness of the daily Scrum.
Scrums can be rushed, stressful and a minefield of opportunity to annoy someone else in your Agile team.
Avoid phrases such as “You said …” and “You did …”
One way to avoid this stress and to contribute towards a constructive Scrum is to adopt the “SBI” way of giving feedback – Situation, Behaviour, Impact.
Describe the situation and be clear and objective about where and when it happened. For example “During this sprint twenty bugs were fixed but ten new ones have been introduced”.
Describe the behaviour your think contributed to the situation but again, be clear and objective. Don’t get personal. For example “The dev team are down two people this month.”
Describe what you think the impact has been and ideally contribute ideas which may help resolve the situation. For example “This has led to a degradation in the dev teams ability to fix bugs and deliver new functionality at the same time. One idea is to focus on bugs for the next Sprint, or reprioritise the new features.”
Agile Mind Set
As part of the Agile mind-set, keeping it real, objective and positive contributes significantly to success of individuals as well as the team and hence organisation.
The format “Given, When, Then” is a way of writing Acceptance Criteria for a User Story.
It works like this: Given (context), When (an action), Then (an outcome).
Given my car has a full tank of petrol which should last 300 miles,
When I take a journey of 100 miles,
Then I will be able to drive without the need to refill
A User Story would typically have one Acceptance Criteria but may have more depending on the complexity of the User Story. If, when writing Acceptance Criteria, it turns out to be complex – you may want to consider breaking your User Story into smaller pieces.
A framework of people, processes, actions and materials which deliver the desired outcomes.
An anti-pattern is in effect a solution to a problem, but where the solution (which may appear to be useful at the time) may actually not be very effective and worse still, cause further issues.
The backlog is list Epics, User Stories or Features which have not been prioritised in the current / upcoming Sprint. The Epic backlog is maintained by the Stakeholders which defines which User Stories or Features the Project Team should prioritise in turn.
During a Sprint an emergency may cause a User Story from the Backlog to be promoted into the current or next Sprint. Similarly, a User Story which suddenly becomes unimportant, or has a dependency on a 3rd pty and cannot be completed in the current Sprint may be demoted to the Backlog.
Typically in a bi-weekly meeting the Backlog is reviewed, prioritised and sized in readiness for the next Sprint. Once refinement has been completed and your team are clear on the contents of the next Sprint, it should ideally be replayed to the Stakeholder(s) for approval.
Behaviour Driven Development (BDD)
Behaviour Driven Development is the method which encourages Acceptance Criteria in using the “Given, When, Then” format.
The Burn Up Chart shows the number of User Stories which have been delivered vs the number of User Stories. It is normal for some User Stories to be added and some to be removed from a Sprint while it’s in-flight – see the example below:
Signs of poor mind-set and engagement include lack of attendance, lateness of attendance, overly brief summaries of where an individual is in the Sprint and lack of progress – e.g. continually rolling User Stories from day to day and then into the next Sprint.
At Agile 7 we can conduct a one-day health check on your Agile implementation as well as a deep dive which includes 1:1 discussions with individual Agile Team members including Scrum Masters and Product Owners.
The difference between firing and not firing on all cylinders for an Agile team is enormous in terms of collaboration and delivery.
The Scrum Master is not a Project Manager and is not your manager if you’re in an Agile Team. The Scrum Master is there to facilitate the daily scrums, to work closely with the Product Owners and to help facilitate all Agile ceremonies as well as helping with any escalations to Stakeholders and the management Team.
If a Scrum Master starts project managing, that’s a danger sign.
If a Scrum Master starts telling you what to do or how to prioritise your work, that’s a danger sign.
One way around this is to rotate the role of Scrum Master within the Agile Team – ideally with an Agile consultant helping out once or twice a week to make sure it’s all running well. The benefit of this is that everyone gets to understand what the role is and how to facilitate all the meetings required to make the Agile Team fire on all cylinders.
Each Agile Team member can take on the role for one Sprint then pass on the batton.
Sharing the role helps to demystify the role and also helps each Agile Team member to better engage with Stakeholders.
Of course, it should never be compulsory for every Agile Team member to take on the role.
This an unsatisfactory state for an Agile project and can lead Stakeholders to ask questions about why you’re implementing in Agile at all.
There are several ways to fix Agile Creep – here are a few suggestions:
Make sure User Stories are well written, clear, concise and have been elaborated with the help of Stakeholders if required BEFORE THE SPRINT STARTS.
Make sure User Stories have been sized correctly ideally using Fibonacci sizing numbers.
Make sure the Acceptance Criteria are well written, clear, concise have have been agreed with Stakeholders, as above, before the Sprint starts. You don’t want to get to the end of a Sprint and realise, “Oh, you didn’t want this, you wanted that!”. Then bump it to the next Sprint. This is a great way to help Stakeholders lose faith in what you’re doing.
Make sure the right person or people in the Agile Team get the right User Stories. It’s of limited use asking a developer to write a legal document for a 3rd party as is it to ask legal counsel to develop some code (unless your team consists entirely of super-heroes).
Make sure that User Stories which get stuck are discussed in the daily Scrums. This enables the Product Owner and Scrum Master to work out if a User Story is worth parking for now awaiting elaboration e.g. from a Stakeholder or 2rd pty, and if extra bandwidth becomes available in the team to take the next most highly prioritised User Story which makes sense to tackle.
It is common for Stakeholders to write vague or incomplete descriptions of desired outcomes which eventually end up as Epic text in JIRA. The Product Owner should not take Stakeholders’ Epics as being complete until they make complete sense and have Acceptance Criteria.
It is useful for the Product Owner to help Stakeholders complete their Epics, how they relate to the overall vision, and how they break down into User Stories.
It is also useful, once elaborated and clarified, for the Product Owner to replay the Epic, Acceptance Criteria and the headline User Stories back to the relevant Stakeholder(s) if not to gain sign-off, then at least to gain consensus and agreement.
Business outcomes are just as real as software outcomes.
In software development your outcome might be to source and stream data in a meaningful way online.
In business an analogous outcome could be to run an RFP with vendors which may result in a Proof of Concept delivery back to Stakeholders to make a decision on which vendor to onboard. The outcome will have clear Acceptance Criteria and will decompose into User Stories for delivery over a number of Sprints.
Sprints & 3rd Parties
However, User Stories which are dependent on a 3rd party should be at a low enough level with useful Acceptance Criteria to enable progress which can be parked if need be for a Sprint while awaiting elaboration from the 3rd party.
A good example of a Scrum is where everyone gets together in person or on a call and there’s a quick round-robin where everyone gets to say what they’re working on and if they need any help. The process should be light touch. The Scrum Master should not overlay unnecessary layers of process, reporting, documentation or reporting on top of this (which is usually the case).
Remember that the Scrum Master is there to facilitate the daily process and to help escalate any issues especially to do with the Agile process itself to the Management Team.
If you think or feel that the daily Scrum is an unnecessary waste of your time each day then you’re Agile Environment is ready for a health check.
A T-shaped Agile team member is someone who has broad experience (the horizontal bar of the “T”) who also possesses subject matter expertise in one area (the vertical bar of the “T”).
An example might be a developer who has deep experience in coding and who also has broad experience in banking – e.g. knowledge of how equities and bonds are traded and has good knowledge about trading systems etc.
What are the benefits of T-shaped Agile team members?
The main benefit of a T-shaped person is they can not only deliver against User Stories in their domain, but can also contribute during Sprints to help others who may lack bandwidth or expertise in other areas. For example the developer could help a PM write an RFQ.
What are the drawbacks of Agile teams comprising T-shaped team members?
The main problem with building an Agile team comprising T-shaped people occurs when the majority of work in a Sprint or across a series of Sprints falls to one area of expertise.
Imagine a team of six where everyone is T-shaped and their subject matter expertise is;
Imagine that the team has a huge amount of legal work where the lawyer has to read, evaluate and revert to external counsel in preparation to meet a regulatory body.
Now imagine that the Management Team has prioritised the legal work over everything else, so this Agile team gets 40 User Stories for the next Sprint, knowing that the team members are T-shaped.
The problem is, the team only has one lawyer. That person may be able to hand over proof-reading etc to other team members, but it would not generally be possible for the other team members to do the specific work of a lawyer to the standard required especially when sharing materials with 3rd parties.
This is were cracks can form in Agile teams.
When is it better to silo expertise into a single Agile team?
An organisation should build generalist Agile teams as well as building teams of excellence – e.g. in fields such as IT development, law and marketing.
The important thing to realise here is, that when work is transferred between Agile teams or even between T-shaped members in the same team, there is a cost associated with the handover – depending on the gap in skill-set between the team members.
Agile Team Health-Check
Please contact Agile Unpacked if you think you could benefit from an Agile health-check, whether it be in the Agile Framework as a whole or with your teams, processes or materials.