Raising a teenager: scrum at home
This article is part of a series about how we tried to help our teenage son through his secondary school career, using techniques and practices from the workplace. For an overview of all articles, a good place to start is the introduction (introduction to this article series), where I set the scene and at links to all subsequent articles.
This specific episode is about creating transparency.
How the story unfolded
One of the biggest struggles for adolescents is learning to organise themselves. In primary school, children are taken by the hand to gradually evolve from learning through play towards more and more actual learning. Everything they do is very much bitesized for them and their teacher follows up closely what they do.
In the early stages of secondary school, children are gently encouraged to take matters in their own hands. The amount of study material they need to master increases and they find themselves in a position where just going to class and paying attention is no longer enough to achieve results. At least, not for most of them.
That implies they need to develop a view of what they need to get done. And so we decided to introduce agile boards to help our kids make work transparent. The practice itself was not new to them. Even when they were young kids, we used boards like the one below to get them involved in the household:
To make it more fun for them, we let them draw their own pictograms to represent their tasks. And if they did well, they could earn iPad time, which was a very popular reward back then.
Along the same lines, we encouraged them to visualise their planning with cards. The idea was to have a separate card for every single task. One of our cupboards acted as the board (there must be a reason why there is a board in “cupboard"), the days of the week were columns and we also added a Done column to move completed cards to:
We experimented with different formats and even tools. As my son is very much into computers, we even set up a board in Jira, which looked like this:
What worked
I am absolutely certain that making work visible is a crucial step in any improvement initiative you undertake.
-
Having a card for every separate task was a great instrument for my son to help him think about what he needed to do.
-
For us - as a family - it created insight into how he defined his tasks and where he needed help to become better at it.
-
As the board was in a place where everyone could see it, the transparency it gave created a lot of trust - while it lasted. We could see what was on the agenda, we could track what was completed and we could ask questions when we thought it was necessary.
-
The digital version of the board in Jira even gave us the opportunity to start tracking his results over time.
The practices we used were an important first step for my son to start organising his own work. And although it has taken some time, we are starting to see today that this was a valuable learning experience.
Some lessons we learnt
Nevertheless, we saw it was very difficult for my son to keep this going. While everything still went pretty well in his first two years, we started noticing later on that - despite the boards and the cards - he started missing deadlines, forgetting certain tasks and even studying for the wrong exam one day. In other words: the visualisation and planning did not reflect what he really needed to do.
Basically, he was not ready to do all this planning by himself. And the more he saw how things did not lead to the desired results, the less he became motivated to keep the boards up to date. That in turn did not do any good to the high levels of trust we had before. And that was a really unwanted side effect.
I short, making work visible is a very strong enabler of improvement. But it is of utmost importance to provide the necessary, continued support when you notice certain flaws.
How this relates to the workplace
On a forum like this Atlassian Community, trying to convince users that using visual planning tools like boards is valuable would very much be like trying to sell beer to a brewery. You all know that, of course. So let's stretch the subject a bit and look at what type of board or process may be the best fit for your team ...
Scrum or Kanban?
It is probably clear that the analog boards (the sticky notes on a wall) I used with my son are neither. They are a visualisation of work that needs to be done and more of an actual planning system based on a calendar. It comes pretty close to the calendar view in Jira Work Management. Why? because that was the best fit with our needs at that time and for the type of work we wanted to organise.
The choice between scrum and kanban often comes up when I work with teams. And maybe the most important thing I want to note here is that there is much more to consider than just what type of board you choose for your project. There is a lot of ceremony and best practices behind the visual representation too.
Scrum basically is a choice for planning up front. Every 2 or 3 weeks you purposely decide what your team is going to commit itself on. You start a sprint with only the selected work items on it and expect to deliver those items. The active sprint is the place your team goes to in order to decide what will be the next thing to work on and - basically - what is not on the board is currently not a priority. At the end of the sprint, you run a retrospective to determine what went well and how you will improve in the future. Then, you plan the next sprint and repeat that process. A key metric to build confidence in your teams ability to deliver is velocity, the amount of work your team can complete in a sprint (usually measured in story points, but that may be any other numeric value as well).
Kanban is a pull system. Work items come in continuously and are prioritised, so when the team is ready to start on a new piece of work, they can just pick the one at the top of the list. On top of that, the flow of work is essential in this methodology. That means work must be prioritised on a continuous basis and the team must develop and maintain an attitude to constantly identify and eliminate bottlenecks or waste in its processes. For that reason, Work In Progress (WIP) limits can be configured in kanban boards. Key metrics for a kanban team are lead and cycle time, which can be visualised in Jira through the control chart.
Which method is right for you team depends in the first place on the type of work it mainly needs to tackle. If most of it can be planned up front (like product development by a software team), scrum is often a better fit. If you are mostly responding to customer requests (like in a service team), then kanban is the more logical option.
Very often we see software teams preferring kanban as well. And that is perfectly fine, as long as that is not for the wrong reasons: “these planning and retrospective meetings take too much time”, “we forget to complete our sprint after two weeks all the time” or “we can’t complete the issues we added to the sprint anyway".
Optimising the way you work with kanban requires much more maturity from your team than scrum, as the element of retrospective is built in with the latter. The examples I mentioned may suggest lack of that maturity. For teams struggling with that type of issues, kanban risks to become a cover up of what is really going on. So in short, if you pick your framework, make sure you do so for the right reasons …
What workflow should I use?
To wrap up this article, I'd like to share a short final note on this common Community question. As Atlassian has built a lot of templates into Jira, (new) users commonly ask which one they should use when they get started. My answer to that has always been (and will always be): go to the drawing board and map out your current process. Always design the tool around how you work and adjust incrementally as you start seeing things could be improved. Never blindly implement a standard template from a tool and force your way of working to match what the tool dictates.
In the next episode, I will discuss distractions, external factors that influence team focus. For my son, this mainly was his growing interest in gaming, which caused him and us quite a few headaches. I’m aiming for the week of December 20th for that!
Was this helpful?
Thanks!
Walter Buggenhout
About this author
Atlassian Expert
Axians Belgium
Belgium
1,453 accepted answers
12 comments