Kingland Blog

Agile Part 1: Do You Know What Your Team is Working On?

Written by Jason Toyne | 3/10/16 8:58 PM

The hectic schedule of an IT leader can often create a situation where the leader feels disconnected from the daily activities of the team. Too often we will find a roller coaster relationship between the leader and the team where the leader will jump in with both feet one day and “micro manage” the situation and then become busy again and be un-involved the next. This roller coaster can be unhealthy for the team.  As leaders, we need to be responsible for providing vision, coaching and support.  It’s important that we create consistency in how our teams perceive our involvement. Fortunately, I have found some methodologies that have helped me and I’m sure they can help others as well. 

SHORTEN THE FEEDBACK LOOP

In the IT world we tend to play buzzword bingo. One buzzword of recent years is “agile”. I’m a firm believer in agile and one outcome of agile that works extremely well is the shortened feedback loop. The agile methodologies create key milestones that allow for management involvement in the work activities. The Kingland agile methodology allows a number of key leader interaction points.

RELEASE PLANNING 

During release planning we work with our customer stakeholders to understand at a macro level what the requirements/scope and priority is for the release. The team estimates the macro level scope and we set tentative release dates using the team’s estimates and previous productivity measures (Velocity). I attempt to be involved in all release planning activities because it gives me a great opportunity to not only understand what we are planning on producing, but I can also provide coaching and support to the team as they consider approach.  My involvement in this activity sets a solid foundation for all future release activities.

TWO WEEK SPRINT REVIEWS 

Every two weeks the team meets with stakeholders to review the progress of their release work. Often times this will involve show and tell sessions where each team member will show the progress they’ve made on the release and elicit feedback from the stakeholders. I attempt to participate in this activity because it gives me the ability to take a pulse of the release. I like to observe the interaction between the team members and the stakeholders. The interactions often lead to key coaching or customer relationship takeaways that I can be involved in.

USE MACRO VIEWS 

Macro view reports allow me to spend a short amount of time each week reviewing the progress of the team. There are three things I look for in the reports.

1. Do we have a plan and are we working the plan to completion?

I use a burndown chart to answer this question. The burndown chart allows me to quickly see how much work was planned for the two-week report period and it also lets me see the rate at which we are completing the work in that plan. Here is an example of a burndown view that we have in our Kingland SDLC tooling.

At least once per week, I will look at the burndown and if it is not tracking at “guideline” will work with the Scrum Master to understand why and use that as opportunity to provide support if needed.

2. Is the release on schedule?

I use our Kingland Release Burndown view for this. 

This chart allows me to quickly understand the teams Velocity and determine how many two week Sprints are required to finish the release.  If I see that scope is being added or velocity is diminished, I will use that as an opportunity to meet with the Product Owner and Scrum Master to understand why and provide support where necessary.

3. Do we have future work?

Because we plan work in two week increments, it’s important to make sure that we always have at least two weeks of quality backlog available to the team. To determine this, I look at the team’s velocity and backlog. Within the Kingland SDLC tooling we will tentatively plan a two-week period (Sprint) ahead of schedule, we call this the “future sprint”. I look at this future Sprint to see how much work is planned and compare it against the team’s Velocity to ensure it is adequate.

 

Stay tuned for Agile Part 2 and learn the three quality areas to look at.