At TAB, the Agile Principles are instrumental in guiding the ways we work on projects, and also within the wider sphere of our company operations.
This post takes a deeper look at one of the principles included in the Agile manifesto:
‘Business people and developers must work together daily throughout the project.’
As the principles should be interpreted based on context, we will define ‘business people’ in this post as any stakeholder who is empowered to have a final say on product decisions. This may be on the client-side, or one of our own TAB Product Owners. The relationship and collaboration between the business people and the developers building the software is critical when it comes to achieving the best possible result.
Why does this principle matter?
1. Short feedback loops increase visibility and minimise waste
Daily input from a business person is imperative - it provides invaluable feedback and direction for the team. This in turn allows the team to validate that they are building the most valuable product in alignment with stakeholder needs. It is equally as important that the team communicates their progress in an open and transparent way. This type of constant, two-way communication results in shorter feedback loops and helps to minimise waste.
2. Regular check-ins strengthen working relationships, provide context and create happier teams
At TAB, we refer to the fable of ‘The Chicken and the Pig’ to illustrate the differing levels of involvement in a project. The basic fable runs:
A Pig and a Chicken are walking down the road.
The Chicken says: "Hey Pig, I was thinking we should open a restaurant!"
Pig replies: "Hm, maybe, what would we call it?"
The Chicken responds: "How about 'Ham-n-Eggs'?"
The Pig thinks for a moment and says: "No thanks. I'd be committed, but you'd only be involved."
In summary, whilst a chicken only has to supply its eggs with no further involvement, a pig is required to fully commit to the project - literally providing the skin off its back. Having a 'chicken' involved - whether as a business person or developer - can be dangerous. Whilst anyone could be a chicken, it is the responsibility of the team to ensure consistent commitment from all members.
The important point, however, is that due to their lack of commitment, chickens can make bad decisions because they do not have the correct context. They may also waste time by trying to understand decisions made by the team that have already been well-considered, regardless of the chicken’s absence.
As well as potentially adversely affecting the product, this can negatively affect the team’s dynamic, creating an ‘us versus them’ mentality that slows velocity and reduces the overall quality. Getting everyone - from engineers, designers, and strategists to business people - acquainted, ultimately leads to strengthened relationships and happier, more productive individuals all round.
3. There are valuable lessons to take away from both sides
We always encourage close collaboration between the business people and developers, both from TAB and from our clients, often by co-locating. There are lots of valuable lessons that both parties can take from each other through regular communication, and this in turn helps get more done in a shorter timeframe.
For instance, our teams often work with business people who are new to iterative, agile ways of working. We can help coach these people through daily stand-ups, retrospectives, and simulations. In turn, our teams can develop a much deeper insight and understanding of the outcomes that the business people are trying to achieve. As a Scrum Master and Agile Coach, a key part of my role is to work with external stakeholders and our own Product Owners to increase efficiency and productivity.
What practical steps can a business person take?
So if you are a ‘business person’ tackling a mobile project for the first time, or perhaps with a new team, how can you ensure that you play your part and proactively set up the team for success?
Below are my top line thoughts for what makes a business person good, better and best at championing this Agile principle.
As a business person, attending planning sessions and sprint reviews will help the whole team to ensure that the right items have been prioritised, and that features have been built as expected during a given sprint.
Joining retrospectives also means that you and the team are able to work through any concerns you may have in a safe space through communication, and ultimately leading towards resolution.
However, only touching base during sprint reviews will not allow for you, as the business person, to have direct involvement in the development of features during a sprint. Consequently, significant amends could mean the team has potentially wasted two weeks of work, causing high priority features to be pushed further down the backlog, timelines become more stretched and budgets grow.
In addition to attending key sprint ceremonies, the business person should also work with the team to beat up user stories, acceptance criteria and scenarios which outline how the product should behave. Working with the team to identify as many scenarios as possible ensures that everyone is aligned with the expected outcome of each user story, which helps to minimise waste.
However, attending sprint ceremonies and writing scenarios doesn’t guarantee success. Once again, if you are only touching base intermittently, it could mean that whilst building, the developers may come across a scenario that hasn’t been previously covered.
Do they assume that they're building the right thing and carry on, even if they might have to duplicate their effort? Or do they wait, allow themselves to be blocked and potentially waste time?
To create the most valuable product, it is essential for the business person to have visibility of what the team is working on - at any given point in time.
The best way to achieve this goes beyond sprint ceremonies. The very best decision is for the business person to be co-located with the developers on a day-to-day basis. This enables face-to-face communication, helping to eliminate any ambiguity over requirements, and shortening feedback loops. Obviously, in the real world, co-location with client-side business people every single day isn’t always possible, or for a variety of other reasons, isn’t ideal. This is one of the reasons why our own Product Owners are so essential to our teams here at TAB. Additionally, however, where co-location isn’t practicable, the principle remains that business owners and product teams should strive for daily communication wherever possible - and preferably, face-to-face.
Not only does this aid prioritisation, it also forges stronger relationships and working together becomes a better, more productive experience. In addition, business people new to more agile ways of working can bring invaluable experience back into their company, or extended teams.
If you want to discover more about how we work at TAB, and our iterative approach to delivery, contact us.