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.
Example 1: Use Xtream java library to map about 50 XML’s to java classes.
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…
| Reference: | Agile Estimation – Are We Missing Something? from our JCG partner Nadav Azaria at the DeveloperLife blog. |
