Transparency Within Your Team

Today we’re lucky to have the opportunity to let a fellow member of the agile community guest blog for us.

Out guest blogger is Agile Coach, Luis Gonçalves. Here is is take on creating transparency in agile teams.


Transparency Within Your Team

During my career, I had the opportunity to help several teams. All these teams were in
different stages of agile adoption, but I believe that one of the most basic things that a
team must possess is transparency of data, actions and decisions.  In this article, I will
provide several tips I use with my teams to create transparency as well as self-awareness.

Vision, Work Principles and Values

Every time I start to coach a new team, there is one exercise I always practice – Road Map
for High Performance. With this exercise, I help the team to find out their vision and
purpose. Why are they together? What do they need to achieve as a team? What is their
purpose? At the same time, I help them to select values they want for their team and the
work principles to guide them in their daily activities. The full exercise is described here. The result of this exercise (the mountain) is then transferred to the wall. This will provide a big transparency about the team´s believes and the way they like to work together.

Definition of Done (DoD)

Next step is to make DoD transparent to everyone and especially for the team. Simply
explained, the DoD is a list of tasks that must be performed in order to deliver a product
with a great quality. Typically, DoD contains tasks such as Unit Testing Coverage of x%,
Accept Criteria met, Build Must Be Green, Reviewed by a peer, Performance Testing
done, all necessary documentation written, etc.  It is quite normal that teams work with
legacy code, therefore it is not possible to have everything in a single DoD. In this case, I
advise to create a DoD of what can be accomplished right now and during the sprint, as
well as a list of topics that must be performed but cannot be done during the sprint.
Each sprint I help the team to find ways to pick up topics from the most ambitious list
into the Story DoD. Posting this information on the wall helps the team to not forget
about tasks, which need to be performed in order to ship the great quality. Another
benefit of having this on the wall is the fact it shows to everyone what kind of activities
the team do to ship the product into the market.

Sprint Information

I use three types of information to get transparency of what is going on during the
sprint. Based on my experience, it´s a good practice to keep the Spring Goals on the wall,
to remind and share with everyone what the team is trying to achieve during that sprint.
Anyone that walks by can immediately see what the team is working on.

Second type of information, is to have the work board on the wall. This might seem a
silly idea, but based on my experience, when teams do not have this information
displayed they lose focus easily. If you use a virtual team, make sure you have a screen
near your working place displaying the virtual board. Having this information available
helps the team to focus and pick up work from unfinished tasks instead of starting new
tasks from new stories. Having this information somewhere in virtual tools is not
enough; we must make this information visible and transparent in order to help teams.

The last piece of this puzzle would be the sprint burn down. I believe this concept and
its value is really badly explained in the community. I am surprised with the amount of
teams that do not explore this tool. Most of engineers think that a burn down chart is a
simple reporting tool, which in my opinion is sad. Of course it can and is used also as a
report tool, but it is not its biggest advantage. This tool should be used to establish a
conversation with business owners and help the team to see where they stand as a team;
it should be used to see if they are on a track or not. If they are not, they should
negotiate with business owners what they should drop to deliver the most valuable piece
of software to the customers. This is a fantastic tool to create visibility of what is going
on with the team, yet not so many teams use it in a proper way

Cooperation:

I usually advise my teams to have a “cooperation part” on their wall. In this part, you can
display some information about cooperation. One thing that I like to use something what
I call the happiness index that can be found here. This exercise
allows people to share their feeling during the sprint. Some people might find this a bit
intrusive, however, if used in a good way, it is a fantastic tool to understand how people
feelings are affected by what´s going on within the sprint. This can be a great tool to be
used as an input for a retrospective. Another information I find useful, in case you do a
pair programming, is to have a table chart to see who paired with whom, as shown
here. This information will help the teams to bring transparency and provide them an input to
act up on in near future.

Metrics and build status:

There are several metrics that can help you to improve your way of working. Before I
refer some of them, I want to state something really important. When you decide to
make all these metrics transparent, make sure you communicate to everyone that your
performance should not be measured by those metrics. Those metrics help you to
improve and to see if your code is gaining or losing quality. Explain to everyone that all
metrics can be faked, thus if someone tries to attach a performance to your payment,
make sure they understand they will be cheated. Below you can see several metrics I use.

Testing Code Coverage  (Unit Testing, Integration, UI, etc) – Try to have a
register over the time. This will help you to find a trend. It will help your team to see if
you are getting better or not. Many people told me this metric is useless, because in
today’s world we want 100% coverage. Even if this is truly based on my experience, not everyone starts a project from a clean sheet. They start in the middle of an old project,where legacy is part of their daily job; therefore people cannot have 100% code coverage. Because of this, it is useful to track code coverage over a time to see how is the trend involving.

Velocity – Velocity over time is a good metric to predict if a team will be able to deliver what is planned.

Build Results – This is fundamental information, it will tell the team if they can release the product or not. There are several facts that affect a build; all these factors should be made visible for the team. Test Cases must pass; code coverage and rules should be met. Teams usually have monitors in the team area to keep this visible for everyone.

Release Information

It is always useful to know the progress of our release. To track how the release is
progressing, we can use a graphic presented below. The red bar shows the stories that
need to be implemented, green bar demonstrates the ones that were already achieved and
the yellow ones the stories added to the product backlog. We can see how many stories
were initially planned vs. stories that are on the backlog at the moment. This metric can
give us an idea whether a product owner adds lot of stories or he sticks to the initial
release scope.Team - Product Backlog Burndown

Another information that can be added, but unfortunately I do not have a graphic to
show, is the date when the team will finish the product. This can be achieved calculating
the average velocity of the last 5 sprints and project it into the future. The team can see
how many stories there are still on the backlog and easily calculate the approximate date
when the product is finished. This is crucial information to keep everyone informed
about the status of the project.

Another information that can be added, but unfortunately I do not have a graphic to
show, is the date when the team will finish the product. This can be achieved calculating
the average velocity of the last 5 sprints and project it into the future. The team can see
how many stories there are still on the backlog and easily calculate the approximate date
when the product is finished. This is crucial information to keep everyone informed
about the status of the project.
I believe, if teams use the information I provide here, they start to have all the necessary
knowledge that allows them to reflect on their work. This allow them to achieve fantastic
results.

My name is Luis Gonçalves and I am an Agile Coach, Co-Author, Speaker and a Blogger.
I am a co-author of the book called: “Getting Value Out of Agile Retrospectives“.

I like to write and share ideas with the world and this made me a passionate blogger. You
can follow my blog.
If you liked this blog please subscribe my newsletter in order to receive information
about this topic.

Tags: , , , , , , ,

No comments yet.

Leave a Reply

%d bloggers like this: