Agile at the Team Level - Key Benefits

Wednesday, June 14, 2017
Agile delivery in a corporate environment is challenging, requiring teams to strike the right balance between maintaining the flexibility required to capitalize on the benefits of an Agile approach, whilst also keeping the process rigid enough to ensure focus on the product delivery. In our second posting in this series, we cover off key tools and techniques applied in addressing the challenges that appear in this complex environment.


While not all environments are conducive for a pure Agile delivery, many techniques derived from this “pure” space can be adapted to plug and play in any project setting.  In our previous post, we highlighted some of the common pitfalls seen when implementing Agile and Bi-Modal, including lack of clarity around how the activities would be run, distributed location of teams, and poor visibility of the sprint work at the enterprise level.  Three of the more common plug and play “tools” that can be used in any environment include Stand ups, Kanban boards and Sprint Demos, often providing for immediate benefit to the organization.

  1. Stand ups

Stand ups are daily meetings that are timeboxed, usually to no more than 10-15 minutes. The standard format is to go from person to person answering 3 questions - What they did yesterday, what they are doing today and whether there are any impediments to their work. In strict application, individuals from outside the team may attend but usually do not comment or talk during the meeting, greatly helping communication and awareness of what everyone is working on, without extending time in meetings.

Looking to “stand up” a stand up in your non-Agile environment?  Benefits for your team include:

  • Bringing early attention to issues blocking progress, allowing them to be addressed quicker and increasing team productivity.
  • Raising issues in a team setting facilitates best practice knowledge sharing, enhancing delivery quality and improving time to market.

It also allows individuals with impediments to raise them and team members who are able to help can follow up with solutions afterwards, thereby preventing people from sitting on issues.  If this is done in conjunction with a Kanban board, then tickets can be moved during the stand up.

  1. Kanban board and Burndown chart

Kanban boards, also referred to as Agile boards and Scrum boards, are a visual representation of the workload with a variety of different headings, typically 'Backlog', ‘Blocked’, ‘In-progress’, 'Testing' and 'Done'. Each piece of work is represented by a ticket on the board and the board is updated to show where the issue currently is.

This is useful for clearly identifying the progress of a sprint acting as an information radiator where it can then be picked up quickly by senior stakeholders. Jira has a plug in called Greenhopper, while both Trello – who was acquired by Jira parent Atlassian - and have free tools for those looking to get started online.  For those who are old school – it is possible and completely acceptable to make one using post-its and a whiteboard – see our attempt below.

Also mentioned, burndown charts are a graphical representation of the work remaining in the sprint.  The total work in the sprint is marked at the top, and as the sprint progresses and work is completed, the amount of work remaining is tracked and updated or burned down. Doing this immediately after the stand up, either gives the team a boost for doing well or emphasizes that the pace should be picked up, whichever is necessary at that point in time.
While a burndown report is atypical for a non-Agile environment a Kanban board is not.  Benefits for your team include:

  • Providing a constant and visual representation of status on progress, ensuring team members can see latest status regardless of location, allowing for better overall management of distributed teams.
  • Visibility of the work completed, allows for assessment on the order and importance of subsequent work, improving the team’s ability to manage changing priorities.


  1. Sprint Demos

Lastly, a Sprint Demo is a meeting is conducted at the end of a sprint. The team gathers with all relevant stakeholders and demonstrates the work (or product) that has been completed during the sprint. This gives the business the ability to provide feedback on quality of the work performed and the ability to make informed changes in priorities and scope, whilst there is still tolerance in the schedule to meet the project’s timeline.
Whether or not you are running your project via “sprints”, conducting early and frequent demos on your product or process with your user community has many benefits:

  • Provides early and direct access to your product/process with engaged individuals, improving not only product visibility but end user adoption
  • Improved visibility leads to increased identification of downstream impacts, reducing product risk
  • Ensures regular and consistent feedback on real world application and effectiveness, reducing misalignment and lengthy rework

Getting feedback from stakeholders helps build motivation and buy in within the team and decreases the risk of poor quality or unsuitable products in the final delivery.  However, introduction of tools alone will not ensure success.  You will need to ensure that there is a clear structure and expectations from the team and management and that there are effective communication channels across all levels of the organization.
In Conclusion

As mentioned in the previous post, it is critical that the team and management are clear on how the delivery process works. This keeps the focus on the delivery instead of expending energy debating how Agile should be implemented as this can be a highly charged subject.
Recognizing that you now have many subcultures within any organization – the Project Management Office, the Agilists and the Traditionalists – it is important to stress that the main focus in adopting any Agile technique is the on the delivery of the project, and NOT the implementation of a ‘perfect’ Agile solution.

Pcubed therefore recommends to be pragmatic about your transition so that it fits within the organization and isn’t blindly an implementation of processes ‘because Agile says so’.  Involving the team in the initial consulting process, ensures that everyone feels bought in to the structure and is clear on what is expected of them.  

Second, if the teams are not co-located, then it is especially important to have communication channels in place to ensure team cohesion and that team members have a means to raise issues and have them addressed. As Agile provides a murky view of the delivery by its nature, it is important that management has a clear view on progress.  A structured communication channel will allow transparency and speed in decision making, focusing awareness on issues that need executive help to address.

In retrospect, it is important to remember that Agile and the associated tools and techniques are not a silver bullet for your project. As with any tool it is only effective if used correctly and in the right scenario. It is important to continually monitor your Agile working methods to ensure they are increasing business benefit with minimal impact on your resources and their time.  If a specific technique is not providing demonstrable value, you would be better off to simply “stand it down”.

Ben Beavers is an Agile delivery specialist and Senior Consultant at Pcubed, based in the London office. He is a qualified SAFe SPC4 consultant, specialized in implementing and enhancing Agile deliveries. His most recent project has seen him working with global teams in big data, analytics and reporting tools at a tier 1 investment bank.

For further information on this article and Pcubed, please email