BHAG: Big Hairy Audacious Goal
James Collins and Jerry Porras proposed the term ‘Big Hairy Audacious Goal’ in their 1994 book Built to Last: Successful Habits of Visionary Companies.
I was first introduced to BHAGs when I was part of a management team in the IT department of a small health insurance company in the late 1990s. We were in charge of transforming the organization through the introduction of a new core system. The CIO challenged us to set what seemed, at first, to be outrageous targets and goals, and then develop strategies to achieve them. In doing this, we moved from Collins and Porras’ original intention of having just one achievable BHAG for an organization to:
By definition, Agile lends itself to BHAGs that may appear to be difficult to achieve, because we have:
More recently, I introduced elements of BHAGs to Agile projects in Brazil and Singapore. Initially, the BHAGs are met with skepticism – generally seen as unachievable. This is exactly the point. BHAGs should be hard to achieve. They are stretch targets that should be used by a team to test and change daily activities. The purpose of having BHAGs is to continuously learn and improve team processes and practices. As we will see, BHAG rules are expected to be broken. This is fine, provided that the team comes together and discusses why it was broken, and what steps can be taken to avoid the same issue from occurring again.
In this article, I first explain the concept of a ‘Pull’ system, which underlines a number of the BHAGs, and then detail four BHAGs that I feel most Agile project teams could benefit from using.
The solution then is to have a ‘Pull’ system, which is borrowed from the Kanban (Lean) for the software world. In a ‘Pull’ system, a card only moves across the board when the receiving team or individual are ready, and a detailed kick-off or desk check has been completed.
For example, let us assume a Dev pair believes that they have completed a card. The BA, QA, Product Owner and Dev pair will come together and do a detailed review of the working software - ensuring that the code does what it is meant to do, and all of the acceptance criteria have been met. Only when everyone is satisfied that the intent and acceptance criteria have been met, the QAs ‘Pull’ the card to the next column. Likewise, the same group will come together when the QA believes that the card is complete and the Product Owner will ‘Pull’ the card to 'Done' (signed-off).
Having a ‘Pull system’ in place ensures conversations within a team and encourages optimization across the team. For example, Developers churning through cards ‘In Dev’ and looking to optimize just their column, are not thinking about the productivity of the whole team.
With a ‘Pull’ system in place, we are now ready to look at four key BHAGs.
The number of columns on an Agile wall is often the cause of robust and passionate discussions, with some teams arguing for as little as three columns (Ready, Doing, Done) and others arguing for many more (Ready for Analysis, Analysis, Ready for Dev, Dev and so on).
As explained above, the issue with ‘Ready for QA’ and ‘Ready for Sign-off’ columns is that they can be viewed as a ‘dumping ground’ for Devs and QAs. There is no need for ‘Ready for’ columns if the team has meaningful kick-offs and desk checks. Rather, I have found that having four columns is most efficient:
The key to improving and moving towards this BHAG is having a detailed desk check – involving the BA, QA, Design and Product Owner when the Dev pair have completed their work. This does not replace the work of the QAs – it simply front-loads some of the basic initial checking that the QAs would normally undertake. The QAs will still perform regression and edge-case testing.
If a new requirement is identified after the card has been desk checked and pulled into the QA column, the team creates a new story card, rather than adding the requirement to the existing card. If a defect is identified, a defect card is created and placed into the ‘Backlog’. The team then comes together to understand how the defect occurred and what steps can be put in place to avoid the same issue from arising again. The team accepts that the BHAG has been missed, and take steps to avoid a repeat.
In advanced teams, the QAs will review and discuss all defects that have occurred in the previous iteration and look for common patterns and reasons. They can then provide feedback to the team, with a view to continuously improving development practices.
Whilst the ultimate aim is to never break the WIP limit, in reality, WIP limits will be broken regularly.
On a project in Singapore, the team attached an ‘Alarm Bell’ icon to the column card when a WIP limit was broken. They would then come to the wall and discuss why the limit was broken, what steps should be taken to rectify, and what process changes may be needed to avoid it from happening again.
WIP limits break for many reasons. For example, the Dev column limit may break when a story card is blocked due to a dependency (breaking BHAG 4 – see below) or the Testing column limit may break if one of the QAs is on unplanned leave. In the first case, the team would look into the reasons that the card was blocked and aim to avoid this situation from happening again. In the second case, the team may assign a Dev pair to the QA team for some time to clear the Testing backlog.
The goal, though, is to analyze why the WIP limit broke and take steps to avoid that situation from recurring.
The key, then, is to understand any dependencies that a story card may have, and ensure that the dependent work will be completed in time for the story to be played. Dependencies will be identified during analysis and can be shown on the physical card or on a Dependency Map.
This is hard, but the benefits of being able to complete a story card as planned, makes the effort worthwhile. If the completion of the dependent work is not guaranteed, the team should select an alternate story card to play. Rather than being blocked, the team should work on other stories that could be released earlier.
Another reason that a card may be blocked, is a key resource taking unplanned leave – specifically, when there are pools of knowledge within a team. Regular pair rotations, team code reviews, lunch-and-learn information sharing sessions and the like help remove these pools of knowledge and reduce reliance on key individuals.
Introducing BHAGs to your team will set them on a journey. Every time the team changes a process or practice to remove an issue, they improve and move closer to achieving a Big Hairy Audacious Goal.
James Collins and Jerry Porras proposed the term ‘Big Hairy Audacious Goal’ in their 1994 book Built to Last: Successful Habits of Visionary Companies.
A true BHAG is clear and compelling, serves as a unifying focal point of effort, and acts as a clear catalyst for . It has a clear finish line, so the organization can know when it has achieved the goal; people like to shoot for finish lines.
I was first introduced to BHAGs when I was part of a management team in the IT department of a small health insurance company in the late 1990s. We were in charge of transforming the organization through the introduction of a new core system. The CIO challenged us to set what seemed, at first, to be outrageous targets and goals, and then develop strategies to achieve them. In doing this, we moved from Collins and Porras’ original intention of having just one achievable BHAG for an organization to:
- Having a small number of BHAGs for a team or department
- Specifying BHAGs that aimed to challenge the team to continuously reflect and improve
By definition, Agile lends itself to BHAGs that may appear to be difficult to achieve, because we have:
- A regular cadence (typically one or two week iterations)
- A series of repeatable rituals to reflect on our performance and improve our processes (retrospectives)
More recently, I introduced elements of BHAGs to Agile projects in Brazil and Singapore. Initially, the BHAGs are met with skepticism – generally seen as unachievable. This is exactly the point. BHAGs should be hard to achieve. They are stretch targets that should be used by a team to test and change daily activities. The purpose of having BHAGs is to continuously learn and improve team processes and practices. As we will see, BHAG rules are expected to be broken. This is fine, provided that the team comes together and discusses why it was broken, and what steps can be taken to avoid the same issue from occurring again.
In this article, I first explain the concept of a ‘Pull’ system, which underlines a number of the BHAGs, and then detail four BHAGs that I feel most Agile project teams could benefit from using.
The ‘Pull’ System
A common issue that Agile teams face is of cards being pushed across the board. That is, the developers complete a card and then push it into the next column – typically ‘Ready for QA’ or a QA will push a card to ‘Ready for Sign-off’. The problem with this is that if an issue is found with the code, the card needs to ‘Bounce Back’ to a Dev pair or QA. They typically would have already picked up another card, and so there can be confusion around how to prioritize the work.The solution then is to have a ‘Pull’ system, which is borrowed from the Kanban (Lean) for the software world. In a ‘Pull’ system, a card only moves across the board when the receiving team or individual are ready, and a detailed kick-off or desk check has been completed.
For example, let us assume a Dev pair believes that they have completed a card. The BA, QA, Product Owner and Dev pair will come together and do a detailed review of the working software - ensuring that the code does what it is meant to do, and all of the acceptance criteria have been met. Only when everyone is satisfied that the intent and acceptance criteria have been met, the QAs ‘Pull’ the card to the next column. Likewise, the same group will come together when the QA believes that the card is complete and the Product Owner will ‘Pull’ the card to 'Done' (signed-off).
Having a ‘Pull system’ in place ensures conversations within a team and encourages optimization across the team. For example, Developers churning through cards ‘In Dev’ and looking to optimize just their column, are not thinking about the productivity of the whole team.
With a ‘Pull’ system in place, we are now ready to look at four key BHAGs.
BHAG 1 - Four Columns Only
Agile project teams will maintain electronic and/or physical card walls to track the progress of work over an iteration.The number of columns on an Agile wall is often the cause of robust and passionate discussions, with some teams arguing for as little as three columns (Ready, Doing, Done) and others arguing for many more (Ready for Analysis, Analysis, Ready for Dev, Dev and so on).
As explained above, the issue with ‘Ready for QA’ and ‘Ready for Sign-off’ columns is that they can be viewed as a ‘dumping ground’ for Devs and QAs. There is no need for ‘Ready for’ columns if the team has meaningful kick-offs and desk checks. Rather, I have found that having four columns is most efficient:
- To Do – stories have been fully analyzed with acceptance criteria defined, technical notes recorded and estimated
- In Dev – Developers ‘Pull’ the story after a meaningful kick-off. The story is being actively worked on by a pair of developers.
- Testing – The story has been pulled from Dev by QA following a desk check, ensuring that the intent and acceptance criteria have been met.
- Done – Story has been pulled from QA by the Product Owner and has been accepted. The story is now ready to be showcased.
BHAG 2: Zero Defects, Zero Bounce Back
The goal of BHAG 2 is to have defect free code and cards that only ever move from left to right on the story wall (that is, the card does not ‘Bounce back’ from right to left).The key to improving and moving towards this BHAG is having a detailed desk check – involving the BA, QA, Design and Product Owner when the Dev pair have completed their work. This does not replace the work of the QAs – it simply front-loads some of the basic initial checking that the QAs would normally undertake. The QAs will still perform regression and edge-case testing.
If a new requirement is identified after the card has been desk checked and pulled into the QA column, the team creates a new story card, rather than adding the requirement to the existing card. If a defect is identified, a defect card is created and placed into the ‘Backlog’. The team then comes together to understand how the defect occurred and what steps can be put in place to avoid the same issue from arising again. The team accepts that the BHAG has been missed, and take steps to avoid a repeat.
In advanced teams, the QAs will review and discuss all defects that have occurred in the previous iteration and look for common patterns and reasons. They can then provide feedback to the team, with a view to continuously improving development practices.
BHAG 3: Strict WIP limits
Work in progress (WIP) limits are used by delivery teams to identify and resolve bottlenecks. Typically, the team will discuss and agree on WIP limits for the Dev and QA columns. Different teams will have different approaches to setting WIP limits. One approach is to set a WIP limit for the Dev column on one card for each Dev pair and for the Testing column as one card for each QA.Whilst the ultimate aim is to never break the WIP limit, in reality, WIP limits will be broken regularly.
On a project in Singapore, the team attached an ‘Alarm Bell’ icon to the column card when a WIP limit was broken. They would then come to the wall and discuss why the limit was broken, what steps should be taken to rectify, and what process changes may be needed to avoid it from happening again.
WIP limits break for many reasons. For example, the Dev column limit may break when a story card is blocked due to a dependency (breaking BHAG 4 – see below) or the Testing column limit may break if one of the QAs is on unplanned leave. In the first case, the team would look into the reasons that the card was blocked and aim to avoid this situation from happening again. In the second case, the team may assign a Dev pair to the QA team for some time to clear the Testing backlog.
The goal, though, is to analyze why the WIP limit broke and take steps to avoid that situation from recurring.
BHAG 4 - Zero Story Cards Blocked
A regular cause of a blocked story card is inter-team dependencies. For example, a story card is blocked when waiting for another team to create and expose a service layer. This is frustrating and time consuming.The key, then, is to understand any dependencies that a story card may have, and ensure that the dependent work will be completed in time for the story to be played. Dependencies will be identified during analysis and can be shown on the physical card or on a Dependency Map.
This is hard, but the benefits of being able to complete a story card as planned, makes the effort worthwhile. If the completion of the dependent work is not guaranteed, the team should select an alternate story card to play. Rather than being blocked, the team should work on other stories that could be released earlier.
Another reason that a card may be blocked, is a key resource taking unplanned leave – specifically, when there are pools of knowledge within a team. Regular pair rotations, team code reviews, lunch-and-learn information sharing sessions and the like help remove these pools of knowledge and reduce reliance on key individuals.
Conclusion
BHAGs are meant to be really hard to achieve. In fact, some are virtually impossible to be met. That is the point. Agile project teams should be aiming to continuously learn and improve. The purpose of these BHAGs is to break them, understand why they were broken and put in place improvements to eliminate that issue.Introducing BHAGs to your team will set them on a journey. Every time the team changes a process or practice to remove an issue, they improve and move closer to achieving a Big Hairy Audacious Goal.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.