Slides from my talk at Agile Manchester 2017
Successful delivery of an agile project is more than implementing the ceremonies; it requires a commitment to changing how business stakeholders and development teams work together.
In this talk Tristan McCarthy draws on his experience in both agile testing and project management to help you get the most out of your processes and avoid some common pitfalls.
The focus will be on improving communication between different parts of the business and ensuring that everyone shares a common vision for what needs to be achieved, preventing misunderstandings and helping to break down the “us and them” culture prevalent in so many organisations.
Working on projects using agile methodologies for over 7 years.
Started following blindly, then started forming my own opinions about the right way to do things.
After a bit too much complaining I got put in charge of delivering a project.
What I’d like to share today is a few lessons learned from watching the mistakes of others and then making my own.
The focus of this particular talk will be fairly high level, focusing on governance and project oversight more than day to day delivery.
Not just bunch of words fudged together into a snappy acronym!
[click]
Also a chance to slap the face of this amazing actor all over my slides
Self explanatory. Before you can have any sensible discussions about requirements, you need to ensure that everyone is speaking the same language. Once that’s done, you need to make sure everyone has the same idea of the goals of the project
List the user roles - Keep a list of the types of user and the scope of their interactions with the system. Having a concrete list of user roles to refer back to will dramatically speed up creation of stories and help people quickly understand the context of discussion.
Document the domain language - Primary goal here is to make sure that everyone is using the same vocabulary when discussing requirements. One of the biggest causes of drawn out meetings and confusion is people using common terms with a different understanding of their meaning. This is particularly prevalent in large organisations which tend to form their own, often poorly understood, internal dialect.
Capture the project goals - This is one of those situations where the journey is almost more important than the destination. Getting the main stakeholders together to discuss and agree on the “elevator pitch” can help to clarify what the business is trying to achieve, which helps the delivery team. Documenting the outcome is useful for new starters and latecomers to the project.
Communicate your understanding - One of the best ways to cut discussions short is to throw up a “straw man” by stating your understanding of a term or goal. People often find it easier to convey their opinions given a statement that they can either refute or elaborate. Just writing something down on a board can focus a conversation.
Report the right things - Avoid “standard report” formats like the plague. I have encountered nothing more pointless than standardised reports such as slide deck templates. Instead, consider the target audience of reporting and spend time finding out what underlying questions they are trying to answer. Wherever possible you should provide reporting mechanisms which are “pull” rather than “push”. Empower stakeholders to find their own answers with project dashboards which don’t require constant manual update and distribution.
A backlog exists as a collection of high level goals. This should be considered separately to the greater level of detail available from elaborated stories as it serves different goals.
Clear ordering - When everything is a priority, nothing is! Regardless of the tool used to store the backlog, the relative priority of every story should be clear to the delivery team.
Highlight dependencies - The most important part of a well structured backlog is the ability to trace dependencies between stories. This aids in making sensible prioritisation decisions. You can also build up traceability of external dependencies (either incoming or outgoing) in a situation where you are working at the programme level across multiple projects and delivery teams.
Lightweight estimation - Just don’t do planning poker. One of the themes which will repeat a lot in this talk is to think about why you are doing things. Estimation is a particularly important one - what is it you are trying to achieve? Most people know that estimation - particularly against high level goals - is basically useless. It’s something that for whatever reason people don’t like to admit, and instead constantly try to gain certainty through extended estimation sessions. If you do need to provide story estimates, make sure you don’t spend too long on them and ensure that everyone involved understands what they are.
If you are in a position where you cannot get away from the practice of budgeting and setting release dates against estimates, try to use ranges (best case, worst case) rather than fixed values.
Include defects - Defects are often forgotten or treated as less important than new functionality. Given that defects are often things that are in front of the customer this is to my mind a terrible thing to do. Make sure that defects are regularly reviewed, considered and sensibly prioritised in with the backlog.
Bug review meetings should be a regular fixture in the calendar.
Continuous maintenance - If you wash up after every meal it’s easy. If you do your washing up once a week it becomes a massive chore. And you run out of spoons.
Regularly check that the stories still reflect the reality of your goals and that defects are still valid. It’s a common problem for the backlog to become outdated due to shifting requirements, scope expansion and accidental defect fixes.
Don’t elaborate too early - A common mistake made in response to the uncertainty of high level estimation is to try and elaborate stories in the backlog well in advance. To take this too far results in wasted effort and somewhat misses the point of agile delivery. With constantly changing priorities and evolving stories, having a backlog which is detailed too far out just results in conflicting or invalid story content. The ideal is normally to have sufficient work for your next 3-4 weeks broken down in detail.
TIP!
The best way to capture and prioritise a backlog is to write stories for the end goals and then work backwards identifying what needs to be done to get there, adding dependencies as you go.
I’ll admit, this title was a *little* bit forced for the benefit of the acronym. The key point here is that the stories are clear and easy to understand.
Avoid unnecessary rituals - Structure your stories in a way that makes sense to your team, and keep in mind what you are trying to achieve rather than sticking to some prescribed structure. Notably, your goal is to allow a reader to quickly understand the outcome of the story and to understand the context within which it sits. It should also be possible to quickly find related stories and dependencies.
Involve the right people - Stories should never be written in isolation. Rather than specify the roles of people who should be involved, consider the kind of people you want. You need people who understand the business domain, both as it is and as the business would like it to be. Someone should be keeping the story context in mind, i.e. how it relates to other stories. You need someone who will question the requirement and seek to drill down into exactly how the system will behave in various edge case scenarios and you ideally need someone who can consider (at a very high level) any glaring implementation problems which may impact efficient delivery of the requirement. This often comes down to Product Owner / BA / Tester / Developer, but it depends on the structure of your teams.
Communicate your understanding (again) - As with the domain language, it’s helpful to constantly state your understanding of the goals. Make it highly visible - capture the story content as people talk and make sure everyone can see it. You will arrive at a conclusion much more rapidly than if you try to discuss until an agreement is reached. If it’s a domain you are comfortable with, this can also be a technique for guiding customers to make decisions.
Clear definition of done - Any team should understand what they mean by done in a general sense (e.g. delivered into a QA environment and with automated tests running against it). The story itself still needs to be clear in it’s scope. You should capture a complete list of the behaviours expected as an output, and wherever it is not clear identify functionality which is considered out of scope.
Focus on the end goal - I’ve often heard people say that they are working on something technical so they can’t write a “proper” story. In the time I’ve spent writing stories I can count on one hand the number of times I’ve been unable to produce a story that represents value to a stakeholder out of a so called technical task. The main story body should contain only the problem you are trying to solve and the behaviour that’s desired as an outcome, not any implementation specifics.
By all means discuss potential implementation when elaborating as it might impact the requirements, but this should be additional detail and not the core.
TIP!
Writing tests is the best way to increase understanding of requirements. Simply asking a number of “what if” questions highlights problems early and ensures a common understanding. A story with tests written before it reaches developers is clearly scoped and can be properly validated within the team.
Delivery of agile projects doesn’t work when a team is expected to implement in isolation. It requires an organisational shift and engagement from the top down. Without everyone understanding the advantages and limitations of delivering in an agile fashion there will be friction between delivery teams and “the business”.
Reality check - Agile is not a silver bullet, and it’s important to help the business understand this early. As an approach, it has many advantages and it also has its disadvantages. For it to work for the business they need to want what it offers. Got a clearly defined project scope slated to go out as a big bang release in 6 months? Stick to what you know. The disruption of Agile adoption will cause nothing but pain. Delivering a new product where you want / need quick feedback to help it evolve? Perfect, pick up agile and bask in the joys of CI and regular releases.
Continuously evolve - Adapt your process to meet the needs of the business. The non technical side of things need to get on board, this is true. But you cannot simply dismiss their concerns when raised. Consider what they need and why they need it. If you’re existing process provides an answer, share it. If it doesn’t, find a way of providing it. Agile is not an absolute, is is a collection of ideas which can be taken, ignored and adapted as needed.
Group prioritisation - One of our clients had an excellent way of engaging their business. They held internal prioritisation meetings where various parts of the business sent an ambassador to argue their case for stories which affected them to be moved up the backlog. This had numerous benefits, including a sense of shared ownership of the delivery process and an understanding of the various pressures that the PO was under to prioritise work.
Avoid segregation - In most large organisations there is a clear divide between the business and the tech team. This is the biggest barrier to success, with constant friction around delivery deadlines (the devs aren’t working hard enough) and quality (the stories weren’t well defined). Bring as many business stakeholders into the process as you can. Bring them into planning meetings, get their opinions on stories and invite them to demos. With a good agile development process you are constantly making information available to those who want to be engaged - for those from a background of opaque delivery this is a difficult point to understand.
Introduce yourselves around. Don’t be the team in the corner working on some fancy new product.
Challenge procurement process - One of my biggest hatreds is dealing with bloated procurement. Challenge this. An agile delivery team is constantly coming up with new requirements as they move through their backlog. New tools which may require licensing, training which may be required to solve a challenging problem, environments for proper CI - all of these need to be forthcoming within days, not weeks (or months!). Your PO should be fighting tooth and nail against anything which restricts the team. The important thing is to show the cost of slowing the delivery of the team, so that you have a solid, financial argument to loosen the chokehold of procurement restrictions. Highlight time lost due to blockers.
TIP!
Anyone in an agile delivery context should be working to make everything as transparent as possible and ensure that information is always available and always up to date. This moves the emphasis away from waiting for information to be pushed (reports etc) and instead retrieving and analysing information regularly.
This is something that’s often seen as a relic of waterfall delivery, but a clear log of decisions made is critical in any project. Being able to refer back to the limitations which resulted in situations arising allows you to both justify yourself and challenge restrictions.
Capture technology choices - If you decide to use neo4j for your primary data store, capture it. It’s almost guaranteed that a few months down the line you’ll hit some technical limitation related to a choice you made as a team, and you find yourselves scratching your heads and trying to remember why you chose it in the first place.
Explain technical debt - Show of hands - who has made a decision or committed some code in the name of expediency that they knew would bite them down the line?
There will always be situations where we deliberately make choices that we know won’t stand up long term.
Every time you make a decision like this, do it right. Clearly state the impact associated with the technical debt and present the PO with a choice. It’s their job to weigh up things like delivery speed vs quality as they have the context to make the call. Once a decision is made capture it. State what you’ve done, what you think should be done to address the debt and the impact. With this documented list you stand a lot more of a chance of getting that tech debt resolved early. For those in charge of delivery, read that list and think about it CAREFULLY. Make sure you prioritise tech debt in the backlog in the same way you handle new features and bugs.
Log unexpected occurrences - At some point, everything will go wrong. When this happens, capture why it did - what caused it, what the impact was (cost to time normally) and what the knock on effect was. Partially, this is just part of being open about what your team is doing, but it also feeds into your retrospectives and gives you concrete things that you can address in the future.
TIP!
Make sure that a resolution for any tech debt exists in your backlog so it can be appropriately prioritised
Final thoughts, AKA “things that don’t fit into the acronym”. It was suggested I could call this section “Other” and turn the acronym into “SPEEDO”, but that would make this a very different presentation.
Get the right skills in the team - When you have a small agile delivery team, the people and the skills they have are important. Not just technical, but interpersonal. You need the right balance of forthrightness and the willingness to compromise. Also consider what would happen if a team member becomes sick - do you have a single person with all the skills in a single area? This is a common issue in smaller teams. Truly cross skilled teams are the holy grail.
Talk about the work, not the people - This is a little nugget that came out of a recent talk I attended and I’d like to drop it in although it’s a little specific. If you use standups to keep everyone updated, discuss the work items that are in flight and not the people. Asking the three questions (yesterday, today, blockers) gets tiresome and half the team aren’t listening. Instead look at the stories and ask where they are, get the team involved as there should be multiple people working on each piece.
Work smarter not harder - Especially added for a colleague who hates this term. It’s management bullshit, but put another way can be useful. I often see people scurrying around in project delivery roles being very busy but achieving very little. In any situation, step back and consider what you are trying to achieve and think about whether there is an easier way to reach your goal. A good example is project reporting - spending a day a week preparing a slide deck for a management meeting vs spending a day once to set up a dashboard that people can go and look at any time.
Test early and frequently - Almost another topic in it’s own right, but in brief you need to be constantly validating everything. ESPECIALLY PERFORMANCE! Pushing for purely demonstrable business value over ACTUAL business value will lead to problems. Non-functionals don’t exist.
The symptom is not the problem - While going through the process of applying an agile delivery approach you will constantly be facing problems. Always remember that what you are seeing is merely a symptom and that the underlying problem needs to be addressed to properly resolve. Take a step back. Try and group symptoms together to help identify the biggest problems. Overdue delivery is a common example. The symptom is the team committing to a piece of functionality which they fail to deliver. The problem could be one of many things - unrealistic expectations, unclear stories (scope creep), technical debt impacting delivery...
Brief blurb on opencredo
Mention of two upcoming training courses in June:
https://opencredo.com/events/programmable-infrastructure-cloud-architecture-training/
https://opencredo.com/events/introduction-agile-testing-2/
