person holding white and silver-colored pocket watch

5 Reasons to Kill Time Sheets

/by

I subscribe to a newsletter from Projects at Work which I rarely read. I happened to open it this month and stumbled upon a gem.

 

5 Ways to Improve Time Tracking

 

It prompted this post…

 

5 Reasons to Kill Time Sheets

 

I have a strong dislike to time tracking, especially on software projects and here is why. 

 

1. Motivation of people.

 

The first problem that I have with tracking time is that it inherently sends the message to teams “We don’t trust you.” Even if this is not the intended message, it is the one that everyone hears. More often than not these metrics are used in bonus and performance conversations and used as punishment or reward. For this reason the inherent behaviour that it drives is that people lie, and to feel unsafe and untrusted to get their work done. How will your data be accurate if everyone is lying. If you want people to stop lying then change what is driving their behaviour.

 

2. Managing resources

 

Secondly time tracking implies “resource” management and people aren’t resources. I won’t go into detail on that. Rather, here is a blog post on why that is important. http://arbitrarymix.blogspot.com/2014/03/people-arent-resources.html

 

3. Individuals over teams

 

Thirdly this encourages working towards goals as individuals instead of as teams. If the end game is for people to work better as teams then this drives dysfunction rather than collaboration. If project managers and teams are collaborating daily, then tracking of hours to understand progress is redundant. There are also better ways to visualise progress, and encourage team collaboration and team work. An example would be using a task board to visualise the work and track progress. Less work in progress also encourages collaboration, limiting WIP encourages team members to pair and learn. 

 

4. Satisfying the need

 

Mostly it doesn’t address or satisfy the need. If the need is to understand how long a piece of work takes before a team is finished with it, then there are far better ways of getting this information than tracking time. Measuring a work item start to finish is better than measuring a person for 8 hours or 10 hours a day. Understanding how many work items are done is a better indication than understanding the number of hours James spent on project A. If James said that it was going to take 100 hours and he has spent 80 hours then he has 20 hours left, and so you believe that he is 80% done. That might be true but equally as likely is that James has just discovered that he is only a quarter of the way through. My experience is also that often the last 20% takes 80% of the time. 

 

5. Measuring Productivity

 

Do you want to measure profit or cost? If 3 pieces of work move through a pipeline in a week, that is a far more accurate measure of A: capacity and B: throughput. 

 

Productivity does not equal profit and linking the two together means that you focus on filling up capacity and measuring hours as productivity. Measuring productivity also implies that a team needs to fill up their capacity. The reality is that a team with 100% capacity is much like a highway with 100% capacity: a parking lot. 

 

What you don’t do is measure the rate of work through the system, or give that work space to move through quicker in future. Teams need space to move quicker and filling capacity is not likely to get that. Managing hours is also not a way to drive the right behaviour. If you fill up capacity then you won’t have space for innovation. If you focus on productivity you might miss focusing on profit.

No

Doing No Better

/by

Companies doing agile transformations must empower their development teams or Product Owners to say no.

 

No is important, it is also very final. It implies that you can’t have whatever it is that you want. That is not an answer that Product Owners, trying to keep customers happy can go back to their customers or bosses with. 

 

Here are some ideas on better ways to have those conversations.

 

Team Capacity:

 

What does this have to do with not saying no?

 

Helping stakeholders to understand the impact of adding work to a full system is a valuable way to start this conversation. In this instance, the conversation must be about when this feature can be delivered in relation to what the team is already busy with. 

 

Evaluating how important the new project or feature is versus what the team is already busy with is another way. 

 

Understanding the impact of changing direction mid product is also a valuable conversation to have. Every new feature or product added to a backlog means one that doesn’t get completed right now. Making sure that you are focusing on the right features and that everyone understands the impact of changing those features is a very valuable way to start an important conversation.

 

Feature Value:

 

Features and projects are often pushed into teams without a real estimation of, or a way to measure their value. If we as Product Owners understand the value of each of the features we need to deliver, at least in a rough and estimable way, then making decisions about what is important and having conversations about what is and isn’t going to get done now is much easier.

 

The Rubbish bin:

 

I recently moved, and I had to pack up much of my house. The result was that it was a great time to purge. Anything that I hadn’t looked at or used in the past six months or year had the potential to go in the “throw it” pile. I have seen software backlogs that could use the same heuristic. 

 

Obviously there are exceptions to this rule, but if something is constantly being sent to the back of the backlog, how important is it. Understanding the value and the impact of that feature will aid in getting it moved up the list. If we can’t measure or understand that value in some way, it’s time to send it to the rubbish bin. The ‘we aren’t going to do that pile’. 

 

In essence, there are many ways to say No, and we need to find the most useful way to do that. We as development teams and Product Owners need to use the information that we have. We need to have valuable conversations about what is possible and what is not. And we need to use that information effectively to address the fears and concerns of the business and our customers. 

 

No is a very final statement, finding useful ways to say, not right now or is this the most valuable thing we should be doing is a more effective way of having this conversation.

Photo by Gemma Evans on Unsplash

man sitting in the top of the mountain

Certainty

/by

I read an amazing post the other day on certainty, and what happens when we are certain of things.

 

You can read the post here – The Dangers of Certainty: A Lesson From Auschwitz

 

Personally I found it valuable and interesting. My main take away was about the dangers of certainty. To quote the author:

 

“When we think we have certainty, when we aspire to the knowledge of the gods, then Auschwitz can happen and can repeat itself. Arguably, it has repeated itself in the genocidal certainties of past decades.”

 

This lead me to thinking about certainty in software projects and software teams. How often have I heard people who are certain, that theirs is the only way to solve a particular problem.

We have to do it this way… Or
This solution is the only way… Or
This product is the only one… and so on.

How often in software projects are we certain about the way forward or the tool that will be the solution to all our problems? How often are we wrong about that?

 

Certainty kills possibility

 

When we are certain that we have the best solution to a problem, then we don’t explore different ways to solve the problem. When we are sure about the right way to create something we don’t explore other possibilities. When we are certain that our way of doing something is the only way, we are less likely to collaborate with others, especially if they do not agree with us.

 

Certainty kills innovation

 

When we are certain that there is only one way to build something we lose innovation. If we are certain we are less likely to open ourselves up and less likely to try something different, or be innovative. When we are challenged and constrained, then we are far more likely to think of different and innovative solutions. When we are certain we are less likely to challenge ourselves.  Sometimes its even worth creating constraints that don’t exist to shift your thinking onto a different level and enable more creative thinking. If you are certain, you don’t explore constraints and you don’t challenge yourself or your solutions.

 

Certainty kills motivation

 

When someone else is always giving the answers to problems, people are far less likely to try and solve the problems themselves. When someone shoots down ideas because they are certain that their ideas are better, people are less likely to volunteer information. All of these behaviours will contribute to a lack of motivation from people. People want the chance to be heard and to have their ideas tested and taken in to account. Certainty on the part of another team member, or even more a person with positional authority like a manager, means that often that team member is not open to hearing the ideas of others or taking them in to account. 

 

Certainty doesn’t help in our decision making or problem solving, as much as taking solutions out of a box and applying them to your situation doesn’t work. Whatever problem you are trying to solve and whichever method you use in in solving that problem, questioning will take you much further than being certain. Being a little uncertain will help you to ask questions around what you are worried about, and will help you to understand what you are missing. 

 

To keep questioning the status quo and to keep asking if you are doing things the best way for you and your team is very valuable. A solution that is certain for today, may not be right for tomorrow and so to be certain of anything feels a little like blindly following a process, person or idea. 

 

Maybe if your team mate had been less certain about the right database to use you would have suggested another alternative.If your manager had been less certain about the right way to go forward with this project someone would have suggested a different alternative. I often find questioning the status quo and questioning especially when I am feeling certain, can lead me in a direction that is better than the direction I was going in to begin with. 

people walking on grey concrete floor during daytime

People aren’t Resources

/by
“Resource planning” or “Resource Management” or “Resource blockers” I hear these in stand-ups, or project meetings and even on CSM (Certified Scrum Master) training. People who know me watch me cringe a little each time. I have this visceral reaction that I can’t explain, my whole body cringes.

Why does it matter? Some people would argue that it doesn’t really matter, its all semantics anyway. One of the many valuable things that I learned at PSL (Problem Solving Leadership) was words matter, what you say and how you say things can have a big impact on people. Tone will often have an impact on people’s reaction and words will have an impact on their understanding. So yes it definitely does matter; but Why?

 

Wikipedia has the following definition for resource:

Resource

A resource is a source or supply from which benefit is produced. Typically resources are materials, services, staff, or other assets that are transformed to produce benefit and in the process may be consumed or made unavailable.

I highlight the following : in the process may be consumed or made unavailable.

This worries me greatly because in some of the interactions I have where people are using the word resource the context or tone seems to imply that it is ok if people get used up. One interview I was in a manager said that it would be ok if one of his resources died, because he would be able to be up to speed and take over in less than a week.

The word resource implies an object, something that can be replaced or used up, then replaced. Resource implies that if I replace it then I will get equal or better performance. Let us take a PC hard drive for example; if my PC is old and my hard disk is slow and full and I replace it with a newer quicker disk, then the overall performance of my PC is likely to improve.

People on the other hand are not objects. People have families and traffic problems, and children that keep them up all night.  People have parents that are sick and husbands that are going through chemo, or wives that are having an affair. People are complex beings with complex personalities and lots of different “facets” that affect both their behaviour and their performance.

If the expectation is that they need to behave like resources where managers can just unplug one and plug in another one, then I believe we are not only deluding ourselves but doing all our people a disservice. The lives and the realities of life will have an impact on the people in our teams, and in our organisations. Some days Bob may be approachable and some days he may be short and irritable.  Somedays it will be easy for Bob to focus and get things done, and somedays he will be worrying about his daughter at university or his wife being sick.

People aren’t plug and play they aren’t interchangeable at the drop of a hat. People have a myriad of small and big “things” (for want of a better word) that affect how they work, how they make decisions and how they interact.  If we can all start to think about the teams that we work with as individuals and people instead of resources it might be easier for us to realise that people are fallible and make mistakes. People are mostly trying to do the best they can, with the skills and resources (real ones) at their disposal and they can’t see into the future.

Maybe if we can start to do that we can start to see how expecting estimates to be exact and performance/velocity/lead-time to be constant and linear in its predictability is not realistic. Maybe we can start to see that we are all guessing some of the time, and all learning lots of the time, and all just trying to do the best we can. Maybe with that in mind we can start to see the people in our teams as people and not objects. With that in mind maybe we seek to understand each other more and be right less, and maybe with that in mind our interaction and our collaboration gets better. Maybe with that in mind we can work together to make better decisions about what we develop. We can make sure that what we deliver is of the highest value to our customers or our business.

Ultimately; the better the quality of our interactions and the higher our levels of trust, the better the quality of the code we will produce and the software we will ultimately deliver.

two people drawing on whiteboard

“Best” Practice

/by

Best practice, the application of a single and consistently best method, can be a useful concept.

Unfortunately I see this concept commonly applied incorrectly:

    1. Incorrect labelling of a “best practice”, which results from the assumption that it is always the single best approach, and thus applying said practice dogmatically.
    1. Forgetting about context and copying what works for others without understanding potential differences between their context and yours.
    1. Failure to continue scanning for better practices, results in continuing to apply what was best or good practice, long after a better practice has emerged or context has changed.

Label Law

One of the problems with “Best”, in practice, is what Jerry Weinberg calls the “Label Law”. The Label Law talks about how labelling something a certain way frames and potentially limits our thinking.

In the case of Best Practice, by calling it “Best” effectively labels it as un-challengable, why would you challenge what is clearly the best?

In complex or complicated environments there often isn’t a single best practice, and by incorrectly expecting this we elevate our practice to a status of “untouchable”.

Often the appropriate response should be to apply “Good” practice (or others depending on context). Good Practice being a set of options or approaches, each of which would be effective or have context specific trade offs.

Stay mindful of the consequence of labelling, applying and even searching for “best”, as it can lead to dangerous dogmatic behaviour, which misses better alternatives and ignores changes in context.

Context

I worked with a group who often asked “What would Apple do?”. Newsletters were redesigned, websites tweaked and graphics quality increased to near pixel perfection. The problem was the product on offer was nothing like Apple’s at all. The industry, client needs and user skill and knowledge were completely different. The end result was looking like copy cats without actually delivering on what the customers really needed, confusing many of the less experienced users with overly simple layouts and massive amounts of time and effort consumed applying what had incorrectly been considered “best” practice. All of which yielded virtually no benefits at all.

Google famously A/B tested 17 different shades of the same color of a button, to find the one that resulted in the highest conversion. At their scale of hundreds of millions of users, something like this could potentially make sense. However when you’re dealing with a few thousand clients, it’s highly unlikely that you’ll benefit from this level of optimisation.

In both of these examples there is a distinct failure to understand the difference in Context.

Understanding why something works in a specific context before applying it to our own context is very important. What works for Apple or Google won’t always work for you. Take time to understand the problem you’re trying to address before looking for solutions.

As a colleague of mine often points out “Hope is not a Strategy”.

Scanning

Our environments and context are constantly changing, under the influence of many different factors. As a result what worked before won’t work in near future. Best Practice seldom lasts forever.

In order to combat this, individuals and organisations have to develop their learning and change capability. We have to learn how to learn, and practice so we become better at it. We have to practice so we become faster at it.

By continuously experimenting and evolving our systems and practices we keep the wheels turning and improve our ability to notice and respond to change.

As the saying goes, the second best time to start investing in your future is now, the best time was yesterday.

Understand that things are changing constantly, and start evolving your systems today. Use techniques like Operations Reviews, Retrospectives, Visual Management and Metrics to understand what is really happening in your organisation and how you can improve.

Practice

A common definition of Practice is “repeated exercise in or performance of an activity or skill so as to acquire or maintain proficiency in it.”

Somewhat ironically, it’s Best to Practice.

Practice your practices. Create and develop habits. Habits of learning. Habits of adaptation and evolution. Acquire proficiency, then continue to practice so that you maintain it.

In closing be very careful what you label as “Best Practice”. Take time to understand the context in which it is truly applicable.

Always keep an eye out for potential improvements or changes so that you can adapt your practice accordingly.