Communication

Agile Metrics in Action

Time flies! It’s been a while since I did some blogging, but now I’m back with a book review ”Agile Metrics in Action” from Manning Publications. The subtitle is ”How to measure and improve team performance”. This is an interesting topic I must say! If you do a change in your team, how do you know if it was for the better, or for the worse? You need to have some information, to be able to compare before, and after, the change. Voila, metrics comes in! The book is written by Christopher W. H. Davis and has 270 pages, it was released in July 2015.

”Agile

Content

The book consist of 10 chapters divided into three parts. The chapters are:

  1. Measuring agile performance
  2. Observing a live project
  3. Trends and data from project-tracking systems
  4. Trends and data from source control
  5. Trends and data from CI and deployment servers
  6. Data from your production systems
  7. Working with the data you’re collecting: the sum of the parts
  8. Measuring the technical quality of your software
  9. Publishing metrics
  10. Measuring your team against the agile principles

In software development we need measurement of what we produce, of course, but also measurement of the impact of the changes we make to improve delivery. Collect, measure, react & repeat – these are the steps in the feedback loop that we want to use.

”A method of measuring something, or the result obtained from this” – metrics defined by Google

In the software development lifecycle (SDLC) data to use as metrics can be obtained from the following sources:

  • Project tracking
  • Source control
  • Continuous integration
  • Deployment tools
  • Application monitoring

Development teams should be responsible for tracking themselves through metrics that are easy to obtain and communicate!

From your project tracking system (PTS), like JIRA or Rally, you can get the following:

  • Burn down chart
  • Velocity
  • Cumulative flow
  • Lead time
  • Bug counts

But why stop with only this? The book has a tip about tagging your tasks with as much data as possible. Tag for example all tasks that get automated tests written for them with:
#automated

With a clever query in your PTS, you can use this tag to create a new metric, representing the percentage of the tasks that are covered with automated tests. Store this metric over time, and you can see trends, to answer the question ”Are my automated test coverage going up or down?”. Another useful thing, is called recidivism, which is the measurement of tasks as they move backward in the predefined workflow. If a task moves from development to QA, fails validation, and moves back to development, this would increase the recidivism rate.

Source control is where your code is being written and reviewed and is a great source to complement the PTS data for better insight into how your team is operating. Continuous development starts with continuous integration (CI), the practise of continuously building and testing your code as multiple team members update it. Also use data from your deployment tools and application monitoring to combine everything into powerful metrics, that can tell the team and other stakeholders a lot about the current situation!

To calculate a custom metric you need two things:

  • Data to generate the metric from (as mentioned above)
  • A function to calculate the metric (can be in a range from very simple to super advanced. But remember you should be able to communicate your metric to other people!)

Recommendation

The book ”Agile Metrics in Action” does a good job in thoroughly explaining the topic about metrics. This is done with informative texts, together with a lot of pictures! If your are interested in metrics to help you improve your team, you should definitely check this book out!

All the best,
 Tomas from TheAgileist

Advertisements

Self-Organization & The Planning Board

Last summer I wrote about how I used some agile principles and practices to handle three problems we faced when living four families together in a small summer house. You can find that blog post here. When my vacation started, I spent some time thinking on improvements for this year’s stay (bringing together in total 19 persons). When everybody arrived I had prepared some new ”tools” for self-organization, with the Planning Board as the major new idea!

”The

These are the ”tools” we used

The Planning Board

The planning last year was compelled of a to-do list, and a schedule for the daily meals put up on the most central place in the house (i.e., the fridge :)). This set up worked well enough, but I wanted to improve it this year, and ended up with the Planning Board as shown in the picture above. It’s a matrix for each day in the week (that consisted of our stay in the summer house) with time slots (before lunch, lunch, afternoon, dinner and evening). To fit on the fridge the largest pager I could use was in A3 format, so I had to do my own stickies to be able to fit it all (cutting pieces of paper and using tape). As you may recall, ruler, scissors and tape are amongst my favorite agile tools! 🙂

”The

Above is a picture of the completed planning board, before any stickies were added. As you can see, I took the opportunity to make it colorful. Some additional information was also added to the board.

Below you can see the planning board, before the week started placed on the fridge (as said, the most central place in the house, where everybody passes several times a day).

”The

Initiatives

A sticky on the planning board represented an initiative. Maybe we could have used the word activity as well, but initiative felt better and more generic to fit our purpose. Each initiative had a driver (marked with ”D: <Name/s>”) on the sticky. The driver was the main responsible person for the initiative. Some initiatives regarded all persons, so they were marked with ”D: All”.

Some of the initiatives were given from previous years (like some shorter trips we like to do), so I added them before the week started to the planning board.

So could anyone just add an initiative? The answer here is both yes and no! Yes, because there were no rules for who could add a new initiative and no because some ”secret rules of self-organization” applied. I will explain them now. First, the driver needed sponsor(s) for the initiative. I.e. person/s that agreed and would ”join in”. Since most of the initiatives didn’t involve any major costs, finding sponsor(s) for the driver was pretty easy (”Shall we do this? Yes, that sounds like an good idea, let us add that to the planning board.”). A few initiatives involved cost, and they had to be funded, i.e. agreed upon with the owner of the summer house.

”The flyer”

To communicate about the initiative the driver in some cases used a flyer. Those didn’t fit on the fridge so we used a door for that. On the flyer the following information was stated:

  • Name of the initiative
  • Short description of the initiative
  • Name of the driver(s)
  • A motto
  • If participation was mandatory or not (the children put up a show every year, and attendance to that is always mandatory 🙂 )
  • Preferred time for the initiative (maybe if it was best suited as an evening activity)
  • An inspiring picture
  • Additional information.

The door

”The

Here you can see the door in the beginning of the week with five flyers added. The door also contained some feedback boards, that gave the opportunity for anyone that wanted, to give feedback (whether it was positive, negative or suggestions for improvements).

The planning meeting

After the dinner when all the participants had arrived, we held a planning meeting. At the meeting, this years new ”tools” were explained and we also did the first version of the planning (i.e., putting up all the stickies) on the planning board. Later some stickies changed back and forth during the week, mainly because some of them were weather sensitive. So the planning was like a guideline that we could follow, not rigid, and given the possibility to be flexible. This worked out really well during the week!

Self-Organization

With the ”tools” describe above the ecosystem was set enough to allow for self-organization! No-one was forced to do an initiative. Naturally the driver started and others would ”dig in”. This worked out really well during the week!

Hey, so you mean no problems at all occurred? Well yes, of course some problems occurred and needed to be sorted out. Mainly those discussions were handled by the four siblings (representing the four families). They came to an agreement in consensus, and in all cases I am aware of, everyone else aligned to that decision. Metaphorically, you can see this as the driver seeking sponsors to fund the initiative.

What happened?

Initiatives (a lot of them)

A lot of initiatives, with high commitment and value! It felt like more activity than previous year. New initiatives emerged during the week (I’m super happy with this, that showed that the ecosystem for self-organization really worked). Here is an example: One of the first evenings, an adult conducted a music quiz, following evenings many of the children held there own quizzes (with their music, almost impossible for the adults to guess :)).  Another example is building of a new porch for one of the smaller houses. This was an initiative that kept going ”in the background” during several days of the week (first to tear down the old porch, get rid of that, and then building the new).

Committed drivers (most of them)

In most cases, pin pointing a driver was really beneficial for the initiative, and the outcome was much better than leaving this with ”handled by whom it concern”. For one initiative I had higher hopes on the driver. In reflection maybe I should have taken a step back to get more involvement (I produced the flyer for this initiative, while not being the driver).

Alignment

Very little arguments or problems occurred during the week (less than previous year). All the people were aligned in terms of them knowing what was going on (a child knowing what day the Aqualand visit is planned, to an adult knowing who is responsible for making the dinner). The whole week was pretty much smooth sailing all the way!

Agile things we used

Open Space

If you are unfamiliar with Open Space, you can read more about it here. Basically I thought of the week like a long open space where initiatives (instead of topics) where put into time-slots.

Visualizations

The Planning board and the feedback boards are examples of visualizations.

Feedback door

Jurgen Appelo have come up with the idea of a feedback door. That inspired me to our door, as seen in the picture below (depicted after the week had ended).

”The

Planning meeting

Like the sprint planning meeting (in Scrum), we had a planning meeting with all participants to get understanding and alignment.

Self-Organization

I got some new inspiration regarding self-organization from reading the book ”Team of Teams”, which is may latest book review that you can find here.

Summary

Reading the feedback that was given about the week, it seems like a success (the only thing people complained about, was the weather – which wasn’t as good as it can be). I’m happy that everything I’ve set up worked out well, and that we improved from last year (kaizen – continuous improvements, remember?). It was also great to see the high commitment in the initiatives! Hopefully you now have some ”tools” to use when you want to bring structure to many people living together in a limited area during their vacation, or if you can use them in your daily work!

All the best,
 Tomas from TheAgileist

Zero Inbox

Today I’m sitting at a huge indoor playground, my son is here for a birthday party. I brought my laptop with the intension to ”write something” 🙂 . Earlier this week, I saw the hashtag #ZeroInbox mentioned by one of the persons that I’m following on Twitter. It seemed like a big deal, that #ZeroInbox was reached (meaning no emails in your inbox). I have that all the time, so I started to wonder why that is important, and maybe if I should write something about how I achieve it.

”Zero

Introduction

First of all, I’ll set you into my context. I get about 50 – 100 emails every working day. Some of you may receive a lot more than that, some of you less, but I assume the amount I get is pretty average. Many of the emails I get, are from the fact that I participate in email-lists (for example alerts of status changes in a ticket system). Maybe 10 – 20 emails per day are coming from other persons.

What are the reasons to keep ”zero inbox”? For me they are:

  1. I don’t feel any stress that there are things in my inbox that are important, and that may need my urgent attention. Checking the inbox regularly prevents that from happening.
  2. Very seldom things get ”lost in the inbox”. I have a system to keep track of the things I need to do.
  3. I have a possibility to act immediately when something pops up. There is not ”a long list of unread mails that may contain even more urgent things” that are blocking me.
  4. Overall, ”zero inbox” gives me the feeling of control, to be on top of things. I’ve also written about this earlier.

Below I have listed the rules that I try to live by, to keep #ZeroInbox at all times.

1. Use your mobile phone

You must be able to read your working email on your mobile phone (or other device you have with you all the time). Otherwise, you can’t apply my rules. But I guess most of you already do that.

2. Don’t have any filters/macros

I don’t use any filters/macros (for example moving emails in the inbox from a certain sender to a sub-folder). Why not? Isn’t that a good was of keeping #ZeroInbox? First of all, filters/macros you can (or should) only use on emails you get from systems (or email-lists). Then you can create a rule looking at the sender and then move them to a sub-folder. That sub-folder will of course increase and hold ”X unread emails”. That to me is stressful (to have unread emails). What do I do then? When I see an email from a system in my inbox I do:

  1. Delete it immediately (which is 99% of the cases, it takes about 5 seconds per email to do)
  2. I act on it immediately (for example a ticket is completed I send off ”good job”-message to the developer that fixed it).

The down part of not keeping them in a sub-folder, is that you can’t go back and search for old items. That is slightly true, but I almost never find the need to go back, and if I have to, I can check in my deleted items folder (which I don’t empty too often, maybe twice a year).

3. Checking emails all the time

Some of you may disagree with me on this one, but I check my inbox all the time. It’s the only was to keep #ZeroInbox! If you sit in meetings all day, and fall behind (emails is piling up in your inbox) there is no way to get back to #ZeroInbox (or at least that will require a huge effort that you will feel resistance to do). What shall you do if you have meetings all day then? There is always some time before, and in between meetings, clean your inbox then. Maybe someone else is talking at the meeting and you are ”out of focus” for a while? Pick up your phone and clean your inbox.

4. Emails I have to act on (i.e the ones sent directly to me)

Do I delete all my emails? Of course not. I use a system with sub-folders to keep track of them. The folders are ”in the cloud” so I can reach them all the time from all my devices. Some of you may keep an email in the inbox as a ”signal” that this is something to act upon, or keep it marked as unread. I don’t do that. All the things I have to do I keep track of using on online kanban board, right now in Favro.

5. Deleting emails (i.e. CC or from systems/emails-lists)

This may sound frightening to you, but I delete most of the emails I get. This means probably over 90%. Some rules fot that:

  1. If I don’t feel the urge, or have the time, to do something about the email I received now, I will probably not have it later either (if I keep it).
  2. If I’m on CC on the email, I got it ”for your information”, I’m not driving the discussion and therefore I can delete it (to be honest I keep CC-emails in some cases, moving them directly to a sub-folder after reading them).
  3. System emails / email lists – Just by the subject I can decide if I should do something or delete directly (see the filter/macro rule).

Summary

There you go, my rules for achieving #ZeroInbox. Are they applicable for your situation? It should be if you receive less or the same amount of emails that I get every day. If you get more, or don’t have the possibility to continuously check emails, you probably have to think about something else. Until next time, enjoy!

All the best,
Tomas from TheAgileist

Tachometer to find perfect flow

How do you obtain a ”perfect flow” of work tasks passing through your software development team? That question have been in my head for quite some time. I can start by admitting that I don’t have a solid answer to that question (yet). However, I have instead thought of a way to visualise if you are having ”perfect flow” or not. How? I’m thinking of a tachometer!

”Tachometer”

Tachometer to find perfect flow

First of all, this is just an idea that popped into my head (this is actually the first encounter with the ”outside world”, so please bear with me). The idea is however to use a tachometer to indicate ”perfect flow” on a kanban board for a development team. Just like a tachometer is indicating if you are using the sweet-spot of your engine at any given moment.

My little example is a kanban board with three columns:

  • Design – Given the value 1
  • Development – Given the value 2
  • Test – Given the value 3

The values are used to calculate the position of the needle in the tachometer. I will now give you three examples that hopefully explains it all!

Example 1 – ”Too early”

”Tachometer

In this example three tasks are in the ”Design”-column, giving a ”tachometer value” of:

1 + 1 + 1 = 3

Thus indicating that we are ”too early”, and that the later steps in the flow (”Development” and ”Test”) are not utilised. The analogy with a car would be to ”gear up” meaning that the team needs to take the ongoing tasks to the later steps of the process.

Example 2 – ”Too late”

”Tachometer

In this example three tasks are in the ”Test”-column, giving a ”tachometer value” of:

3 + 3 + 3 = 9

Thus indicating that we are ”too late”, and that the team soon will run out of things to do. The similarities with a car would be to ”gear down” and for the team to put focus on feeding in new tasks to the kanban board.

Example 3 – ”Perfect flow”

”Tachometer

In this example the three tasks are evenly spread between the columns, giving a ”tachometer value” of:

1 + 2 + 3 = 6

Thus indicating that we have a ”perfect flow”, and that the steps in the process are utilised in the best possible way!

Summary

I understand that the mathematical formula behind this idea must be improved if this should become a reality. There are also cases where a tachometer like this will not be useful, for example if the team has just started. Maybe this can act as a challenge to manufacturers out there of digital kanban tools to add a tachometer in their product!

All the best,
Tomas from TheAgileist

Switch

In an old episode of Seinfeld it’s discussed and concluded that ”the switch” can’t be made (in this case meaning to switch a girlfriend for her roommate). The book ”Switch” tells another story, about making changes that last. This book is written by two brothers named Chip and Dan Heath. The subtitle is ”How to Change Things When Change Is Hard” and was released 2010.

”Switch

”What looks like a people problem is often a situation problem” – Chip Heath & Dan Heath

Content

The book consists of 11 chapters, divided into three sections, and they are:

1. The Surprises About Change

DIRECT THE RIDER
2. Find the Bright Spots
3. Script the Critical Moves
4. Point to the Destination

MOTIVATE THE ELEPHANT
5. Find the Feeling
6. Shrink the Change
7. Grow Your People

SHAPE THE PATH
8. Tweak the Environment
9. Build Habits
10. Rally the Herd

11. Keep the Switch Going

The first chapter is describing change, and mentions that to change someone’s behaviour, you’ve got to change that person’s situation. Wisdom from psychology says that the brain has two independent systems at work all the time. First, it’s the emotional side (instinctive, makes you feel pain or pleasure). Second, it’s the rational side, also known as the reflective or conscious system. If you want to change things you have to appeal to both sides! To use the vocabulary of this book: You have to speak both to the Rider and the Elephant. One other advice about change is that you have to provide crystal-clear direction.

The ”magic formula for change” boils down to the following:

  • Direct the Rider – What can look like resistance is often lack of clarity (give crystal-clear direction).
  • Motivate the Elephant – What looks like laziness is often exhaustion. You have to engage the emotional side.
  • Shape the path – The situation (including the surrounding environment) is called ”the path”.

How to find the bright-spots? Use the following question: ”What’s working and how can we do more of it”. One other tip is to use destination postcards, they do double duty: The show the Rider where you are heading, and they show the Elephant why the journey is worthwhile. They can be incredibly inspiring!

When it comes to shaping the path two strategies are described:

  1. Tweaking the environment
  2. Building habits.

Recommendation

I can recommend this book, it presents a simple formula for making change. The challenge is of course to tailor and implement it for your specific needs. I have not tried out this yet.

All the best,
 Tomas from TheAgileist

Famban

What is Famban? That is my own abbreviation of Family + Kanban! In other words, our attempt to visualise and keep track of all activities within our family. Can’t an ordinary kanban board solve that need? Of course, but we have made some additions that we find useful. It’s also quite fun to come up with a new name for something, I admit  🙂 .

”Famban

Famban in Favro

Setup

We use a collection in Favro with three boards:

  • Ongoing week (with one column for each day in the week – Monday to Sunday)
  • Next week (same setup as above)
  • Further ahead (with two columns; Coming – To keep track of things that are 2-4 weeks ahead & Later – to store stuff even further away).

Why have a bi-weekly schedule? It seems to fit our needs best. You could have a one week rolling schedule or four weeks instead, depending on your needs.  

We use color coding (called Tags in Favro) to visualise different types:

  • Recurring activities (Green) – Used for all recurring family activities, for example ice hockey school on Sundays for my son.
  • Activities (Blue) – To cover all “one off”-activities.
  • Travel (Red, not shown in picture above) – To keep track of an “activity” that spans more than one day.
  • Food (Purple, not shown in picture above) – We had an idea to keep recipes in here to also plan our dinners. To have 10-15 of our favourites to be able to spread them out during the two weeks and have some variation. We had not really succeeded in this though.

Operations

The operations of Famban is easy! Since Favro has a very good web interface for computers, together with apps for iOS and Android we can reach it everywhere all the time. This is the number one benefit of having a digital board like this!

It’s mainly me that maintains the Famban board. Every time an activity comes up, it’s added to one of the boards (ongoing week, next or further ahead).

Once a week, usually on Sunday, the next week is discussed and planned in more detail. Basically I then make “next week” the “current week” by switching places on the two boards (a simple drag and drop operation in Favro). I also change the week numbering (week 47, week 48 etc.). A trick here is to have double of all recurring activities, so you don’t need to copy them between the weeks.

Famban on fridge

”Famban

Our first attempt of Famban, was to put it up on the fridge. That is the most “central spot” in our home, here it’s seen multiple times per day by all family members. I made a physical version of the Famban board using several papers that I taped together. One problem was that it couldn’t be wider than the door of the fridge, and at the same time have the needed seven columns (one for each day in the week) and to be able to fit standard size stickies.  Therefore the “To-do” and “Done” sections were placed “below” the board.

This incarnation of Famban worked well at home, and we had daily morning meetings in front of it. The problem came when not at home, not being able to see it. Often the question came up during the day while at work, my wife called me and asked “Do we have something on Tuesday evening, or can I make arrangements with my friend X?”. That question was not possible to answer, it had to be handled later when at home again, that was inflexible so after a while this Famban board was not used.

Improvements

Here are some improvements that I have thought of, but not yet implemented:

  • When the kids get older and probably get even more recurring activities an improvement would be to add swim-lanes, one for each family member. That is supported in Favro.
  • To get the food planning up and running, adding nice pictures to the recipes would probably help!
  • We have lost the visibility by having the Famban put up on the fridge. That could be fixed by mounting a tablet device on the fridge, showing the Famban board 🙂

Summary

Famban is visualisation and family planning combined! I hope you liked this blog post, and that it inspires you to try something similar! As always, reach out to me if you have something to share!

All the best,
 Tomas from TheAgileist

Feedback Loops 2.0

Earlier on in this blog I have written about feedback loops. Time has come to revisit that topic, and also to talk a bit more how we do it right now.  

Introduction

One of the six Kanban core practices is “implement feedback loops”. Short loops gives the possibility for fast feedback. Our feedback loops are mainly implemented as a set of meetings with different cadence.

”Feedback

Purpose

The purposes of the meetings with different cadences are the following:

  • Improve quality – By giving early feedback on work, errors can be found and corrected when they are “small”, and not later when they become “disasters” (i.e., found in production by customers).
  • Reduce context switching  – By giving feedback fast, the context is still “active” and no context switching is needed (that takes time and reduces the overall productivity).
  • Implement feedback loops – As mentioned earlier, it’s one of the six core practices in Kanban.

Meetings with daily cadence

Daily standup

The purpose is to enforce all six Kanban core practices. The team captain conducts a daily standup in front of the kanban board, with all team members present. Other stakeholders can listen in. Focus is to get tasks to flow through the process, and taking care of and removing impediments (bottlenecks that are preventing the flow).

Bug Triage

We believe that over time more brains makes better decisions than just one! To prioritize between bugs is an activity known as “bug triage” in the software industry. All new bugs entered in the ticket system shall pass this meeting for decision. Fix or not? If fix, when – current release, upcoming or future? Is the bug valid, if not close.

The bugmaster (yes that’s the name!) conducts the meeting and goes through the list of bugs currently in the state “Dispatch”. Afterwards the ticket system is updated with all the decisions made on the meeting.

Meetings with weekly cadence

Status, Planning & Prioritization

The purpose is to follow up on already made commitments, but also to be agile and be able to act fast on changes from customers or in the market.

This weekly meeting has the following agenda:

  1. Action points from last meeting.
  2. Discuss the overall planning, currently we are using “The Circles”.
  3. Discuss and prioritize activities in “The Volcano”.
  4. Any adjustments needed in time, cost or scope? We work in teams, but team members can move between them to where they are needed the most for the time being. If we can, we cut the scope for a release (we work in priority order, starting with the things that are promised to customers so it is possible). A last outcome is to postpone the release (change the release date).
  5. Any other business. Sometimes we use “The Shooting Target” to focus when we get closer to a release for a product.

The Head of Project Management is conducting this weekly meeting together with other stakeholders and the captains from the teams. A written protocol is produced and made available after each meeting.

System architect group

The purpose of this meeting is to secure that we have an architecture for our products that is sustainable and can live a long time. General topics around the architecture is discussed (security, scalability, redundancy etc.), as well as all tickets marked “Sysarch” in the ticket system. The Head of Development leads this weekly meeting together with all system architects.

Demos

The purpose is for developers to show their work on regular basis and to get early feedback on it (before it is “too late to change”). The demo is conducted on Friday afternoons together with “fika” (Swedish phenomena – like an extended coffee break) in the control room.

Meetings with monthly/quarterly cadence

Release planning

The purpose is to produce a prioritized scope (specified on high level) together with a time plan (release date) for the coming release of a product. Stakeholders meet in one or several meetings to discuss:

  • Targets – What do we aim for with this specific release? The targets must be meaningful and understandable to ALL! They shall also be helpful in the daily work. “Shall I do A or B?”, the targets shall guide the decision.
  • Scope – What shall be included in the release.

Ad hoc/when needed meetings

Team planning

The captain calls the team for a planning meeting anytime needed. Usually this is done when the team starts to work with a new thing (fetched from “The Volcano”).

Kaizen meeting

The purpose is to secure that we improve the teams and the process a little step every day (continuous improvements). Before we had this meeting regularly (bi-weekly), but we sort of lost momentum. Now the meeting is called upon when needed (something in the team or process needs to be improved). We use a channel on Slack to bring up the topic with two possible outcomes:

  1. The topic is discussed and solved on the channel directly
  2. The topic is extensive and a meeting is needed (or some smaller topics are collected before a meeting is called).

The Agile Coach and the captains together with other persons with interest in the topic(s) perform the meeting. The outcome is documented on the Slack channel.

Summary

There you go, these are the meetings we conduct to implement feedback loops. We also have some other channels for feedback, but I save them for another blog post. What type of feedback loops does your organization have? Don’t hesitate to contact me if you have any questions!

All the best,
 Tomas from TheAgileist