Agile gotcha's - The event version
Updated: Sep 26, 2022
Introduction
Agile, just the word alone, with 0 context, appears to polarise opinions within software development circles.
The way that some commenters opine you'd think it was only second to the pandemic as the greatest evil to befall software development.
The Agile manifesto is 22 years old at this point and I've never seen such a backlash or hand-wringing over what, on the surface, seems to be a relatively simple approach to software development based off 4 values and 12 principles.
If you're interested, the manifesto is here: Manifesto for Agile Software Development
Much of the backlash appears to stem from the monetisation and snake-oil peddlers / consultants that appear to plague the industry promising cure-alls.
The development equivalent of fairground barkers selling a miracle cure.
A lot of these seem to stem from the simple fact that teams and orgs are taught (where they are taught) to observe the values and principles enshrined within the manifesto as if they are a sacrosanct set of rules to be adhered to without question or thought.
Just drink this / read this / apply this / attend this and all your development troubles will miraculously melt away, welcome to dev nirvana.
Your releases are seamless.
Your features are high quality.
Your dev practices are a union of hope and applied expertise.
Your product offers value to your target market.
Your customers heap praise on your efforts.
If only.
This isn't about testing specifically; this is about tangential causes that 'could' have an effect on the quality of what your teams' output. I've seen what happens when a team embrace respect, the intent behind the principles and apply both their individualism and collective wisdom in pursuit of a collective excellence in what they deliver.
It's amazing, it's truly the best experience I've ever had and one I've never experienced since.
What does any of this have to do with quality?
Everything.
As a SM / QA / QE / Alphabet title, your role is to be aware of those behaviours which could impact quality, it isn't just about demonstrating that a product fulfils some defined requirements articulated in user stories.
It isn't about some pseudo-random green tick on a pipeline.
It isn't about a coverage percentage based on not actually knowing what 100% looks like.
It's about team behaviours. They can, and do, impact every facet of a team's output. They will have a corrosive effect on the quality of what your team produces.
I'll look at what hinders teams from being truly agile (not in the context of airy-fairy-post-from-the-comfort-of-twitter-look-aren't-I-on-the-edge) but real missteps I've encountered as a team member in the Daily Scrum, driven by Scrum Masters and Product Owners who should really know better, as a team member helping to drive quality into our releases and as a Scrum Master helping teams to be truly open, transparent and effective.
Basically, how do you identify when Agile turns into F'ragile?
None of these are explicitly called out in the Agile manifesto. You wouldn't expect that though, they were created as aspirational, not a rulebook to live and die by as some would have you believe.
Quality engineering is an activity embedded within the manifesto, it should never be a tick-box exercise that is solved by attending events, demonstrating a feature or constructing lots of scripts that run without manual intervention. It is by and large a community effort.
My Agile gotcha's - The Daily Scrum perspective
You may have experience of these, you may identify with these dysfunctions right now. These are the gotchas I've experienced the most and the ones that will directly affect the quality of your deliveries.
YMMV.
I'll add what has worked for me and the teams I've been involved in.
This mainly focuses on the Daily Scrum / Standup though these can be applied to pretty much any event. Quite a few anti-patterns can (and do) surface in other events, and during the course of a sprint.
Pointless meetings
Lots of people moan about pointless meetings, ceremonies (events) get bundled in and derided with the resultant demotivating attitudes.
This becomes a circular descent to team dysfunction.
They have a valid point; pointless meetings are counterproductive.
Quality impact
Meetings without a clear, pre-published agenda result in spectacular talking shops that wind through numerous topics without any resultant value.
Meetings without actionable, measurable outputs result in fractured activity, not really knowing if the 'what' you're doing is answering the questions (if any) outlined in the original meeting.
Meetings organised and/or run by someone who does not facilitate. This normally results in grandstanding / the appeal to authority fallacy / loudest voice wins.
Do this:
Every meeting is communicated in advance as far as practical with a structured agenda. This allows invited participants to prepare. It allows those invited to work out if they need to be there.
Attach an agenda
Capture actionable, assignable, measurable outputs
Control the meeting.
Set ground rules (In advance or when the meeting starts)
Vote with your feet (or virtual feet). If you aren't getting anything out of the meeting, leave. Contact the organiser after the meeting and explain why you left. Any mature facilitator will be grateful of the feedback, chances are you weren't alone, you just had the courage of your convictions.
Status Updates
The Daily scrum is an opportunity to tell a story, to identify what you've done and how you're doing it.
It's not a point and click exercise.
It's not a by-the-numbers event.
It's not about calling out a ticket by it's number. "Where are we on 16656?" doesn't help anyone. It's not about calling on people to provide an update.
Giving soul-less status updates don't help anyone, let alone your team.
Quality Impact
Providing an unengaging 'what I did yesterday, what I'm doing today, my blockers' update leads to 0 engagement and 0 interest. They are robotic in nature and all too frequently devolve into single line sentences that offer no nuance.
It allows people to switch off until it's their turn in the spotlight where they can then follow the same uninspired formula whilst everyone else switches off.
Do this
Walk the board, describe what where the story is in relation to getting to done.
Describe what the feature is designed to accomplish.
Describe any testing that has happened.
Describe any obstacles and how you overcame them.
Describe how your activity progresses the ticket.
Describe what the next step is.
Engage other team members.
Give enough information to be helpful to the team without devolving into a stream of consciousness.
Tell a story.
The team should engage, ask questions, offer opinions, help and advice.
The team should have enough information to know where the story is.
All in the name of progressing the story to done.
You aren't a time lord
Respect probably lies at the heart of being Agile, respect for your time and the time of others in your team.
Time-keeping is one of the biggest drivers in any successful ceremony.
Daily scrums / Stand-ups should happen at the same time every day, this isn't death by process. It means that they are predictable in their occurrence and duration, it means that teams can effectively plan the next 24 hours of effort to help get the stories in play to done.
It helps ensure that context switching is kept to a minimum and only those things of value are discussed.
It helps to focus the team and the contributions of the team as a single entity towards successful and timely deliverables.
Quality impact
When team members are late to ceremonies it is indicative of a team that doesn't respect each other's time, it is also indicative of a general lack of interest. It has the effect of signalling to others that this isn't something to be taken that seriously, this can and will have a ripple effect on the engineering activities that happen during the course of a sprint. If a team member turns up late, how much have they missed, what insight is lost that could have mitigated an issue or mitigated a bug or observed a flaw in a test idea or suggested a further test activity or clarified a misunderstanding. You can never get that time back.
Do this
The solution is relatively simple.
Be on time for events.
Be mindful of your responsibility to the team.
Set a reminder 5 minutes before, aim to be there a minute or two before it starts.
Respect those team-mates who do turn up on time.
Your time is no more valuable than theirs.
No, you can't pick and choose other stories...just because you want to
Kanban boards are usually structured in a top-down, highest priority first manner.
This means that those stories at the top have a higher priority than those lower-down.
All too frequently I've seen team members complete a task that they're comfortable with and then pick a task from another story lower down in the stack whilst there are still stories in play above them.
I understand that there are many talented developers on teams, I also understand that there are individuals that don't feel the need to play by any defined set of team behaviours.
Quality impact
It doesn't show joined-up thinking. It shows that 'your' work is more important than the teams work.
Each team member has a responsibility to the team to progress the current stories in play.
Attention is diverted from the most important stories, valuable time is spent discussing the details of a task that, at that present time, isn't that valuable to the team and the overall goal of getting stories to done.
It shows a siloed mindset.
Do this
Once your assigned task has been finished, ask if anyone on your team needs help with theirs.
Be aware of people strengths and weaknesses, be empathetic.
Offering to help someone else is a good thing.
Be okay with stepping out of your comfort zone to learn something new about the feature, a way of thinking, a new technique, an approach.
A QE is working on an automated test, you're really good at design patterns and code, they are really good at test design. Pair with them, share your expertise.
You're also not as good at test-designs, pair with them, ask them to walk you through their thinking, look for inconsistencies and flaws in their model.
The task you help someone else with may be completely alien to you. That's a good thing. Whatever your level of expertise, you will know more about the thing than you did before. You will also promote trust and team-working, it may not be explicitly visible, it will make a difference.
No, you really can't work on more than one thing at a time... No. Really. You can't.
I see this repeated with alarming regularity, one person has >1 ticket(s) in various stages assigned to them(selves).
You aren't a magician.
Quality impact
Context switching is a hidden killer, it's obviously possible to entertain several ideas in your head at any one time, we do it every day.
You may think you are giving a problem your full attention to the exclusion of the 'n' other tasks you've assigned yourself to.
Chances are you aren't.
This will manifest in the quality of the output, mainly due to the context switching, lead-in / lead-out time to focus back on the thing.
Do this
Work on a single task at a time. Make others aware that you're focusing on a singular task.
If people request assistance, discuss an appropriate time for it so you can focus on your task.
If you're working on a task and you can't make further progress, identify the why, identify if anyone on your team (or another) can assist. If there is a blocking issue, articulate this in the ticket. Move it to blocked so that it can be discussed at the earliest opportunity. Keeping it in active will not help the progress of the story to done (unless you're actively engaged in resolving it) in which case why would you assign another ticket to yourself?
Story progression is king (or queen)
Done most definitely doesn't mean "sort-of / mostly / yeah..but"
Most well organised teams will have a Definition of Done (DoD).
This is a set of explicit criteria that should be defined by the team that will act as confirmation that the story in question is potentially releasable.
The team should have committed to the criteria contained within the DoD.
Quality impact
The whole point of a DoD is to gain confidence that the story / feature has had all the requisite activities (code / test / review / documentation / automation) undertaken. Any ticket in the done column is ready for a potential release to the client.
If there is uncertainty from the team as to the status of the artefact in done then that implies uncertainty in the process leading to the ticket being placed in done.
This in turn will lead to uncertainty of the correctness of the developed story / feature. It's not a blame-game, this is an opportunity to inspect and adapt.
Do this
Ensure that as a team, you revisit and confirm the criteria outlined in your DoD.
Add criteria if necessary.
Remove those that aren't required.
Good practice is to regularly revisit a DoD / DoR / Way of Working, especially on change of team member
If there any commonalities in done artefacts that would impact a potential release, add / amend criteria to cover those eventualities. The DoD can be modified at any time (as long as the discussion is had with the team)
Create a Final Quality Check (FQC) task that outlines a simple checklist of things to be covered off, this is the final task to be completed. A simple checklist also means that any member of the team can pick it up to complete (More about an FQC in another post)
Stick to the story / task being discussed
A Daily Scrum is an opportunity for the dev team to plan out what the next 24 hours looks like as a team.
It should be story focused. i.e how do we (as a team) get this story to done.
Quality impact
If the conversation deviates from one story / task to another, or irrelevant details creep in to the story being discussed, a teams focus will also shift and attention will also shift.
Team members may checkout in terms of attention.
The story that was being discussed now becomes an afterthought, the risk here is that there may have been contributions from other team members that now aren't heard.
The time-box will be violated, despite what a lot of people say, this isn't the cardinal sin that a lot would have you believe it is, this does run the risk of people becoming bored. This in turn provides more ammunition to those that say that Agile is a hindrance, not a benefit.
Do this
All members of a team have a vested interest in ensuring that a task is given it's due attention.
Bring people back on topic, be polite.
If the switch and the topic is that important to people, ask them to discuss it post standup, anyone who has a vested interest can then attend the 'offline' portion and those who aren't interested can get on with implementing the plan discussed in the standup.
Don't wait for the SM to interject, they aren't your mum (or dad)
Keeping JIRA / Kanban board in sync is not optional
Just like meetings, JIRA (or whatever flavour of management tool is in use) are derided on a regular basis. This is normally a result of mismanagement and perception of what the point of these management tools are for.
Quality impact
JIRA and the kanban board should be kept in sync.
One contains detail that won't be apparent by inspecting a board, both act as an immediate checkpoint as to the progression of a ticket.
If this progress is not reflected in either, it's all too easy to pick up a ticket in JIRA that is already in progress on a board, it's all too easy to undertake work that has already been done.
The result is that rework may be required or someone has to interrupt their progress to discuss what has been done and update the affected tickets.
Either way, the quality impact is manifested via distracted team members and confusion as to the 'actual' status of a story.
Do this
Document progress, the task / ticket is not completed until both boards have been updated.
Modify the DoD if required.
If you're remote and you don't utilise a physical kanban board it can be seen as not so much of a problem but the point still remains that JIRA / Management tool should be the single point of truth that a team member can reference to ascertain work done.
'15 billion conversations at once'
Events are conversation pieces.
They are designed to facilitate conversations and stimulate ideas.
This is great but this does come with risks to be aware of.
Quality impact
Walking the board is a fantastic way to communicate progress, this can become undone if several conversations happen at once. It also displays a lack of respect and focus if a person is speaking. It also displays a lack of respect for the team and the event itself
Attempting to following >1 conversation(s) is nigh on impossible.
Speaking over over people will lead to other people speaking over you.
The net result is that 'n' number of team members won't understand the current progress and neither will the offender.
Do this
Be aware and conscious of other team members speaking.
If you have a point to make, wait for an opportunity, allow the team to hear what you have to say.
Take side issues offline.
Conclusion
The daily scrum is the one opportunity each day for the dev team to get together to plan and discuss what the next 24 hours look like in their particular world. It doesn't preclude small groups from talking, it doesn't preclude individuals from being asked / asking for help.
Dysfunctional standups will hurt you and by extension, the quality of what you produce.
A well run, engaging, conversational Daily Scrum sets teams up for success.
It's not a status update. Quality is not just code.
Quality is a people and perception problem
Quality is a concerted effort from: Quality Scrum Masters
Quality Devs
Quality Product Owners
Quality Designers Quality Stakeholders Quality DevOps Quality SRE's