1. https://appdevelopermagazine.com/agile
  2. https://appdevelopermagazine.com/hey-coach!-square-peg/
10/10/2016 9:07:35 AM
Hey Coach! Square Peg
Agile Development,Scrum,Coaching
App Developer Magazine
Hey Coach! Square Peg


Hey Coach! Square Peg

Monday, October 10, 2016

Philippe Sauve Philippe Sauve

Welcome back to the coaching post that looks at teams and the complex environment around us. This time we shall discuss the not-too-controversial topic of keeping track of work.

Too often, tracking time and logging work related information has been used to enforce work schedules and dishing out “punishment” to those who don’t put in the hours. Here we describe “punishment” as a bad yearly review leading to poor compensation or other.

As a team, in order to understand the complexities of the work we accomplish we need to bring visibility to the size of the work.

It is only then that we can truly start to work and dig at hidden elements. Having this approach means that we can better get together to solve emerging issues by using the time boxes we planned and keeping track of these makes for a revealing tool. Now notice the choice of word. Like scrum, tracking our performance is a tool with the power to reveal important details of our ability to “get stuff done”. A tool can be wielded many different ways and as explored earlier, it often takes the shape of the hammer  ruler (better to hit you with :P).

As a tool in the team’s arsenal it would most likely take the shape of a gauge of some sort. It enables us to have a reference to the many paths available to us when we start the work. The importance here is that we are not looking for accuracy but rather a means with which we can help ourselves to navigate emerging complexities, etc. The key concept to remember is that of Time boxing. We are meant to trigger an event with the maximum amount of time we set for ourselves is up. It is also a precious reminder that while exploring and creating ideas is great we have to get cracking in order to accomplish our sprint goal (better yet, value).

To get started, when we find ourselves in planning and looking at our Product Backlog we need to breakdown work sufficiently as to keep hidden complexities out of the equation. Another aspect to keep in mind is that any work that the team struggles with should be made visible in the plan as to be able to track the remaining work. If this work is made implicit by being part of the Definition of Done then it affects our capacity, as a team, to learn how to cope with the unforeseen or lack of skill.

This approach is what training wheels are to bicycles, a helpful confidence booster.

Here is an example. Working with one specific team we started by refining the definition of done to reflect the necessary practices to deliver, as closely as they could, production ready increments. After going through a first planning with the new D.o.D, the team sets off. Accelerate now to the end of the sprint and we find ourselves in the Retrospective. A particular observation is of interest to us one where by the team was severely delayed because of Integration testing and as a result could not meet their sprint goal. Now, granted there are a lot of different factors at play though like any path to improvement, we need to focus. This focus was put on the unforeseen elements of integration testing. Since integration testing was part of the D.o.D, all team members had to get this done implicitly for all planned elements of their work. What they did not account for is that while they estimated each individual piece of the work with the D.o.D in mind, it left them open for inefficient team work. The elements with which they struggled with was hidden from view of the others and members were not quick enough to raise the “flag”. After discussing, the solution was to make transparent the particular difficult integration tasks. This meant that the team had to explicitly split the work and start tracking time on each of these. The objective being that they will start to learn how best to tackle the tests and combined together with the Daily scrum, the team is now equipped to have an eye on the remaining work and therefore facilitates their decision making to meet their goal.

The courage required to make things transparent is never easy to come by, yet if we make this about responsibility and ownership, the Team will feel empowered to tackle these issues rather than the anxiety that comes with reprimand or control with them achieving their commitment (see previous post, Issue #2).

Thank you and cheers PS

If you would like to learn more about Scrum, find Scrum training or take a Professional Scrum certification assessment you can visit Scrum.org.

If you liked this edition of “Hey, Coach!” feel free to reach out to me @scrumandme or scrumandme.wordpress.com for other articles.

Read more: https://www.scrum.org/
This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.

Subscribe to App Developer Magazine

Become a subscriber of App Developer Magazine for just $5.99 a month and take advantage of all these perks.


  • - Exclusive content from leaders in the industry
  • - Q&A articles from industry leaders
  • - Tips and tricks from the most successful developers weekly
  • - Monthly issues, including all 90+ back-issues since 2012
  • - Event discounts and early-bird signups
  • - Gain insight from top achievers in the app store
  • - Learn what tools to use, what SDK's to use, and more

    Subscribe here