Hey Coach! Square Peg
|Philippe Sauve in Agile Monday, October 10, 2016|
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.
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.
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/
Learn the best ways to organize your app development projects, and keep code straight, clients happy, and breathe a easier through launches.
Write and run code every step of the way, using Android Studio to create apps that integrate with other apps, download and display pictures from the web, play sounds, and more. Each chapter and app has been designed and tested to provide the knowledge and experience you need to get started in Android development.
How to create a profitable, sustainable business developing and marketing mobile apps.
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.