An honorable member in any development group manifest is enhancing people’s knowledge and expertise. However, it often gets positioned in the infamous “Important/Not Urgent” quarter of the Eisenhower matrix, and gets less attention than it should. Even if an organization does invest effort in this, it will be managed separately from the development process.
In this post I will suggest an agile approach for measuring and monitoring knowledge transfer among team members in an agile environment. I believe that implementing this technique will also have a positive effect on the team estimation quality.
The agile team routine revolves around a “Task”. We plan, estimate and implement tasks. Most of them are created during user stories break down, but many others exist such as bugs, merges, refactoring, etc.
Time spent on a typical task can roughly be divided in two. Time spent learning and time spent working. Given a task, can you state which portion of it was spent on learning and which on working? Well, you might be able to give a rough estimation but it certainly not trivial. This made me wonder if there is an easy way. Here a mental exercise for you. Imagine you perform a task twice in the exact same way. Each time you start from the exact same point. Only the second time you are armed with the experience and knowledge you got at the first time.
How much time would it take you to complete the task the second time?
The second time you don’t need to learn. So it is safe to say that all time spent the second time is “working time”. This gives us the following formal definition:
Given a team member M and a task T the learning factor of a task T with regards to team member M is defined as the amount of time it will take M to perform the task the first time divided by the amount of time it will take him to complete the task the second.
I apologize for the formality. Let’s have a look at two examples in the form of imaginary tasks belonging to an imaginary team of experienced Java developers. We will then try to estimate the learning factor.
What is the learning factor here? Well, if you believe their tutorial (and you should), it takes about 10 minutes to learn how to use XTream. Thus the learning factor here is about ~1. If you start this task again it will roughly take you the same time.
Example 2: Add to a website the option to login with a Google account.
Well, assuming you haven't done this before most of the time here will be spent on learning. The actual implementation is just a few lines of code. So I would roughly go here with ~8.
OK. So now we have a nice new definition. What can we do with it? First, let’s have a look on the existing method for planning the estimation.
Spoiler alert: The following paragraph might be considered a heresy by some.
Agile methods aim to aspire all members to agree on the effort needed for a given task. This is usually achieved by playing Planning Poker. In this game each player will reveal his estimation for a task at the exact same time as the rest of the players. The estimates are then discussed in order to achieve agreement. If you stop for a moment and think about it you can’t help but wonder why?
In practice we know this is not true. The duration on which a person will work on a task is highly dependent on who this person is. So why we should all agree on task estimation? Especially when we still do not know which person will perform the task? It only makes sense that the exact same task will take different amount of time for different people. In most development groups, people have different skills and expertise. The knowledge discrepancy can be at technologies, code, business domain, etc. So even if team members agree on the desired solution it will still take more time to perform by some than others.
How can we do it better?
What if we change the planning poker method just a little? From now on each person will state two numbers. The first is estimation for the working part and the second is estimation for the learning part. The learning part is personal. All team members should only agree on the working part.
Why is it better?
It gives us a nice way to measure and monitor learning in our team. We already measure how much time people spend working. What about learning? Using the suggested method, over each sprint we measure the amount of time people spend on learning. We can call it the Learning Chart. This is exactly like the Burn down Chart only here we measure the number of point’s people spent learning over time. As with Burn down Chart we use the points given at the planning stage.
Here are some examples of learning charts and what they are telling us:
Consider a very horizontal learning chart resulted from most tasks with low learning factor. What does it mean? It means that the team is very efficient and everybody is doing exactly what they are good at. It also means that they are not learning new things and the knowledge is not well spread among team members.
On the other hand a very steep learning chart might suggest less efficient team and probably low quality work since most of the time people do things they know little about.
So what is a good learning factor?
I actually don’t know the answer for that. I would assume it is at least 2 so on average people spend half of their time learning. This might also correlate to the satisfaction and challenge your team member experience in their daily work.
What’s next? Try out my new idea and see if it actually makes sense. I will keep you updated…
Cool concept! I like the idea of measuring the learning factor, and trying to keep it ~2.
ReplyDeleteHowever, I do have two wonders here:
1. In order to keep learning factor ~2, the team's tasks should always contain something new to the team. From my experience, this is not always the case. There are sprints with only known tasks to the entire team. Do you see the learning factor as a goal by itself? I.e. do you think it should affect tasks priority?
2. One of the assumptions here is that the working part will be pretty much the same for all team members. Even though the solution is discussed and agreed during the planing, the implementation might be affected by the team member's experience, coding style (quick and dirty vs. nice and clean), number of challenges during the work and their solutions, etc.
1. we assume the team is changing all the time. Ne challenges arrive, team members come and go. I agree that some sprints have known issues, but think of the sprints were you go where no one has gone before. The goal factor, as I see it, is not a goal but more of a way to be able to estimate better.
ReplyDelete2. I agree. I think that a senior developers guide can come into play here. No one usually wants quick and dirty (you will pay for it later). Makes me think if there is a correlation between the learning factor and the time it takes you to write the code (i.e. the better you learn the better you code?)