The short answer is that company culture is mostly about what a company is doing and why (e.g. developing FinTech enabling better and faster portfolio rebalancing for clients worldwide), and the Agile Mind-set is mostly about how a company achieves this.
A company with vision and great teams can deliver anything anyhow. Even, dare I say, using a traditional Waterfall method.
If Agile delivers anything, it delivers a framework, top-to-bottom transparency and a cadence to the way Stakeholders prioritised outcomes are delivered.
As we’ve mentioned in previous posts, Agile is not just for IT departments or IT-based start-ups. Adopting an Agile Framework from the get-go can significantly help a start-up in these three ways…
Agile delivers clarity top to bottom
An issue in any start-up is being able to track all the tasks, projects and must-do-now’s.
An Agile framework (and associated tools) will enable you to answer questions such as:
What are we working on right now?
How can we articulate progress to our Stakeholders?
Agile delivers transparency of what you’re doing and why
Agile Mind-Set aside (that’s a number of posts which we won’t go into here) adopting an Agile Framework will enable everyone in your start-up to see what the Management Teams vision is, how that breaks down into headline outcomes (Epics) which enables individual team members to be clear on what they should be doing THIS WEEK to move the start-up forward.
Agile makes it easier to track progress and make objective decisions about prioritisation
The Agile approach enables a start-up to clearly articulate what outcomes have been identified, how success has been defined, how those outcomes have been broken down into User Stories, what has been prioritised and when, and how fast the Agile team members have been tackling the work.
When IT teams use the Agile method to deliver software, the bi-weekly Sprint provides the cadence and framework required, along with the other usual processes and meetings such as the Scrum and Retrospective.
For Management teams it can be a little more difficult to see how an Agile framework can operate, but operate it can.
The main benefits delivered by an Agile framework for Management teams are transparency, prioritisation and robustness.
Transparency in Agile Management
Project plans existing in documents or in emails is of limited use even if one individual is responsible for the “golden copy”.
Using tools such as JIRA and Confluence, Management teams are able to contribute collectively to the definition and decomposition of high-level outcome definitions.
These “Epics” are available for Program and Project Managers to see and for Product Owners to review, seek elaboration and to decompose into User Stories.
Prioritisation in Agile Management
A key benefit of having Management Teams’ required outcomes in tools delivering transparency is the ability to make prioritisation an ongoing “delivery” of the Management team. Prioritisation’s never stay the same for long and it is fatal for any project to pretend they do.
Robustness in Agile Management
With transparency and the ability to deliver ongoing prioritisation’s, the Management Team can deliver robustness in direction which in turn drives resourcing. If you know what you’re doing, why and in what order, you can massively improve the robustness of your projects and so decrease risk.
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.
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:
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.
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.
This includes such traits as written, verbal and non-verbal communication as well as responsibility, team membership and self-motivation. Without these skills it is difficult for an Agile Team Member to simultaneously be part of a team and self-motivated to complete their own work as well as helping to guide their team.
Collaboration and the Agile Mind-Set
Emotional Intelligence is the gateway trait into collaboration. For example knowing when to assist other team members with their work, contributing to the definition, planning and execution of Sprints as well as delivering work assigned. Collaboration with Stakeholders and a Management Team is also essential, including the ability to know when to escalate issues and step in as an SME.
Resilience and the Agile Mid-Set
Resilience is important because it means being flexible – e.g. if an in-flight project changes direction or if your role changes from being an SME in critical meetings with 3rd parties one week and then taking on User Stories the next week that may be more mundane in nature. This feeds into the notion of being “T”-shaped which is a trait which is useful but can cause issues if misunderstood or “forced” upon Agile Team Members.
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.