Nightmare on time sheet; how we overhauled the time logging process (part 3)

Author: Becky Burks

Wait: you need to read part 1 and part 2 first!

The fun side of cultural change

You’ll remember that last week I discussed the crucial need for a cultural change in how we dealt with time logging. After the CX team’s thorough research, we were ready to take the findings – and our ideas – to our board of directors. The first thing we showed them was our low-hanging fruit - a solution to the problem of people not remembering to regularly log their time. One of our in-house designers had created some fun posters to stick up around the office. A while back, we had an internal photoshoot as part of our rebrand, and we used our peer’s funny photos in the posters. With their permission of course!

David time logging.jpgFarhan time logging.jpg













Caroline time logging.jpgMarta time logging.jpg













Matteo time logging.jpgNelson time logging.jpg








We had approval to put them up straight away. This was a great start. We didn’t need to have a new system to start implementing this kind of cultural change. Everyone found the posters fun and entertaining, and we still have them around the office today.

Changing the system

Then came the more challenging part - justifying a change to our internal systems. We approached this in a structured format, leaving the best for last. First, we talked through all of the analysis we had done in the exploration phase, to prove why we needed a new system and a new time logging process. Then, we went into the details of how we selected the two potential options, along with the benefits that each would bring, and the cost implications.

We introduced both systems to the directors in a similar way to what we’d done for developers, and went into demo mode of each, answering the directors’ questions as we went along. At this point, it was clear that the room was leaning towards System A, just as the operations team had done when they saw the systems. System A was easy to manage and made it easy to get reports. The interface was also very similar to our existing time logging system, so the change needed was minimal.

Then, we showed them the results of the survey we had done at the end of the developers’ workshops. It turned out that pain points were lessened by more than half by System B compared to System A. Developers thought that System B would foster daily time logging from them as opposed to weekly with System A. All but one person thought their time logging would be more accurate with System B. On the final question about which system they would choose if it was up to them, all but one answered System B. The results were astounding. It was not what had been preferred from a management perspective at all, and without this feedback it would not have been the selected system. Of course, this information changed the game, and the directors immediately agreed the answer was to implement System B. The operations team and managers could adjust to a new way of working; the most important thing was to have a system that the developers actually wanted to use.

At the next company meeting, we announced the good news. Shortly after, we rolled out our chosen system: Tempo Timesheets (a JIRA add-on). We provided training to all of our different user groups.

Since then, nobody has looked back. This is not to say that everything is perfect, and as with any rollout, the cycle of continuous improvement should always follow. However, whenever people are asked in feedback sessions if they prefer the new system to the old, they chuckle and immediately agree it’s miles better.

Lessons learned

There’s really only one moral of this story, that really must always be top priority for any implementation; a system is useless if your users won’t use it. Listen to your users, have a plan for how to manage the change and approach it openly and honestly involving different areas of the business, and of course, make sure that what you deliver is something they genuinely want to use.

Nightmare on time sheet; how we overhauled the time logging process (part 2)

Author: Becky Burks

Hint: you'll need to read part 1 first for this post to make sense.

Phase 2: Imagine

The CX team got together to discuss the problems and carry out an internal ideation workshop to tackle them. We knew that we had 3 key tasks:

  • Improve people’s knowledge of why time logging is important
  • Create a culture of time logging as a habit; and
  • Make the systems they needed to use simpler and clearer while having less of them!

Knowing that there was no room for improvement with our existing official timesheet system, we started to look at the market. We were looking for something that would integrate with JIRA, where our developers work on a daily basis, so that time logging could become a seamless process for them. We narrowed the list of contenders down and chose the two most promising to fully evaluate. We needed to evaluate each to check that it could cover all of the functionality we already had; and more importantly, that both operations and the developers would want to work on.

After a few weeks of testing both systems and evaluating them against a requirements check-list, we showed them both to the operations team. Overall, they liked both systems, but preferred System A over System B. However, we all knew the real test was to see which one the developers would use...

Two workshops were held simultaneously with two different groups of developers. One group saw System A first, where we ran a quick presentation about how it works and then let them play around logging time. While that group was looking at System A, the other group was doing the same for System B. Halfway through the sessions we swapped each team over, so they were evaluating the other system.

This approach let each team play with both systems, but in different orders and without speaking to each other. The idea was to eliminate any bias people might have after speaking to their peers in a different group, or bias towards the first or last system they saw.

At the end of the workshops, we asked them all to complete a survey before leaving the room. The survey questions were created to gauge how the systems would help them with the problems we had previously identified:

  • How regularly do you think you would log your time using System A and then System B?
  • Which pain points are lessened by logging time in System A and then System B?
  • Are you likely to spend less time in System A or B than you do currently?
  • Which system will help you to be more accurate?
  • What advantages do you think each will bring you?
  • If you were in charge of choosing a system, which would you choose and why?

The feedback was nearly unanimous. But it wasn’t quite time to make a final decision yet. We also needed to go through a cultural change…

Telling the story: why is time logging so important anyway?

The next stage for us in our time logging journey was to map out all of the pain points we had identified, and group them in an order which told a story of the problem:

Story of the problem.png

Then, it was time to communicate this to the masses. The arena? The next company meeting.

We used the company meeting as our golden opportunity to talk openly about our time logging woes. We presented the view of the problem from different people’s perspectives, and Dan took the time to explain why we actually need to log time, and how it helps us all.

Time logging.png

At this point, we had output from our workshops. We had the devlopers' feedback. We even had solid ideas for the way forward. Now, it was time to go to the directors to get their approval for implementation…

Check out next week’s blog to find out how we further managed cultural change and finally untangled our time logging troubles!

Nightmare on time sheet; how we overhauled the time logging process (part 1)

Author: Becky Burks

It had been coming for a long time…

At the end of every month, developers scrambled to complete their timesheets, while the operations team were breathing down their necks, threatening them with sticks to get it done - and done right. The developers were left wondering why operations wanted their time logs so desperately. Surely they already knew what they had been working on? The operations team were scratching their heads as to why the developers didn’t do it; they had been reminded at the end of every month like clockwork, yet every month the same story. It was hugely frustrating for both sides, and was approaching boiling point. As soon as the Customer Experience team had a break between projects, we knew this was a top internal issue that had to be solved.

Explore - the operations perspective

We knew we needed to start by getting to the root cause of the problem. So, we set up workshops with the different stakeholders, including operations and developers. They were set up in a way to not mix audiences, so that people would be free to express themselves without someone from a different side of the argument being present. 

The operations team is the right size for us to run the session ‘interview style’, with carefully prepared questions. From a CX Analyst point of view, it was an eye opener. We were so used to being involved in internal project teams, that we hadn’t considered the operations point of view. As we interviewed the team, we drew out a reflection of the time logging process as they saw it from their perspective.

We learned that time logs expected from developers were actually for the company to be able to calculate its profitability, and have a view of the staff utilisation. The operations team had to do a bunch of reports on these topics at the end of every month for the directors to be able to make informed decisions, and for the company to know where it should focus improvement efforts. As the CX team, this was the first time that we fully understood what the time logs were actually used for, and why they were so important. Moving forward into the developer sessions, we were keen to find out if anyone else was also in the dark about this too.

Explore - the developers perspective

Next, we held a developers workshop. We made sure to invite specifically selected people (not that they were aware at the time!) to ensure we were covering everyone’s points of view; from testers, front and back-end developers, support developers, as well as those who were the best and worst at logging their time. We made clear to them at the beginning of the session that the aim of the workshop was to discover their pain points and motivations for logging time, as well as to gather their ideas on how we can improve the process.

But first, we had to break the ice. To start with something fun, as well as get everyone in the open and honest mind-set we needed for the real topic, we played the draw toast video from Ted Talks. Then, of course, we made them all draw their process for making toast.

While it seemed like a pretty useless exercise from their point of view (if entertaining!) it really achieved what we wanted - to show that everyone has a different point of view. It made the transition to the follow-on topic easy. Naturally, the next process we wanted them to draw was their process for logging time, however they each saw it.

When they were done, they each pinned it on the wall and explained it to the rest of the group.

As they each spoke, it became obvious that there were some common themes for everyone, no matter which member of the team they were. Everyone had a step in their process about confusion or panic. As they spoke, we also wrote down quotes from them and stuck them up with their process to get the full, annotated picture.


At the end of the session, our questions were answered. What motivated people to log their time? They were told to. All stick, no carrot. What was their experience of the time logging process? Confusion, frustration, panic and stress. They weren’t always sure which system to log time in, which tasks to log their time on, or even who to ask. They worried about the consequences of accidentally missing a day and having to go back to log it. Worse, because they didn’t understand its purpose, it gave them the unsettling “big brother is watching” feeling.

Around the same time, the CX team attended a fantastic Design Thinking course by Julia Goga-Cooke to further hone our skills. We picked up the useful technique of considering the Design Thinking process as a cycle of Explore, Imagine, Telling the Story and Implement. This was just the process we needed to use for the time logging project. We knew we were still in the exploration stage, and used the opportunity to delve deeper into this phase.


Explore - management perspective 

We held an interview with our COO, Dan Shepherd, to get his take on the time logging problem. Overall, Dan of course knew why time logging was important. He also had a good grasp on why it was frustrating for people on both sides. We shared with him some of the feedback we had gathered so far, and he was surprised to hear that the problem seemed to be more culturally ingrained then he thought. He knew that we needed to get better at internal training and communication, but he still wasn’t sure why people didn’t ask which system to log time on.


The next steps

As the final step, we created a company-wide survey for everyone to have the opportunity to put forward their ideas and feedback. We also wanted to use it to put some quantitative data behind the problem. In summary we found out that:

  • We were using six different systems for time logging;
  • Most people said they logged time in the official timesheet system closer to the end of the month rather than daily;
  • However most developers consistently logged time in JIRA for each task they completed;
  • Most people thought the most important reason for logging time was billing;
  • The biggest pain point was that people couldn’t remember what they had done, the second biggest that they had to log in multiple systems, and the third that they were not clear which tasks to log time against.

The last question asked everyone for their ideas on how the process could be improved. The most common answer by far was to have one system to log time in. The next was making it simple enough for staff to do it daily.

So how did we tackle the problem? Check out next week’s blog post for the next episode of our time-logging saga…

The bullseye (not bored) scrum board

Author: Neil Clark

I’ve wanted to write something about Infomentum's scrum board since its inception in late 2012. Now seemed as good a time as any to share the story...

During an end of sprint retrospective, one of our developers Jakub said “I'm bored of the board.” That didn’t surprise me. We'd been doing two week sprints since much earlier that year, and after rough calculations, I realised that the team had been standing next to the standard scrumboard for about 45 hours...not all in one go, obviously. That was 20 sprints * 9 days per sprint * 15 minutes per stand up; i.e. a lot of time standing in front of a boring board. 

It was good timing really. We'd just done a major deployment, so were in a period of warranty and bug fixing - and that meant I had a bit more time on my hands. I went Googling, and found Craig Strong’s super hero scrum board.

It was the inspiration that gave me the following:

Bullseye board 1.0 

Original bullseye board 1.0

This was very much a first draft. The board is looking pretty different these days (I'll come to that in a moment), but the techniques of how we use the board hasn't changed.

Board structure

The main point of the board is that it focuses the eye on the sprint goal and the mascot in the middle. That's where we’re aiming. That's where we want to get all of our user stories to, so that we can achieve the sprint goal and appease the mascot (who happens to be Dominick the Christmas donkey in the above picture). We (try to) choose or create a funny mascot for our sprints which is loosely connected to the goal. 

The board is divided into segments, each representing one day in a sprint. At the time, we were doing two week sprints, with one day written off for the review, retrospective and planning.

On the left of the circle, you can see the area where we put out 'To-Do' user stories. We only put user stories, not tasks, on the board; we use Jira, so sub-tasks are managed there. I think the board gets too messy if you try to include a card for each sub-task as well. We also have high level technical tasks in our sprints (e.g. Set up UAT environment), which are chunky enough to be on the board as well. 

The outer red circle is for 'In Progress' user stories - these are stories that developers are working on, but haven't been passed to the tester on the project yet. On the first full day of the sprint (usually a Tuesday) we have a different type of daily stand up, where the whole team discuss a rough plan of when the various stories will be available to the tester so they can properly get their hands on it and start finding bugs, e.g. a developer starts a story and based on the tasks, and their workload, they believe it will be ready for testing on Monday of week 2 - so they place it in that segment.

The idea behind this is to create an even distribution of stories across the whole sprint. It allows the tester to test throughout the sprint, and avoid cramming all of the testing into the last day or two. If this happens, testers won't be given the time they need to make sure the definition of done is met. If/when they find bugs, fixes for those bugs might not be possible in the sprint, leading to technical debt or a bad sprint review. 

Highlighting this scenario is the first tangible benefit of this board; it highlights when your sprints are becoming mini waterfall phases. If at any point during your sprint the majority of the story cards are in the final two segments of the board, something has/is going wrong. And with this board there’s no getting away from it. Everyone can see it.

The ensuing discussions have brought out several root causes across projects I’ve worked on:

  • Dependencies on a 3rd party providers (incorrect documentation, lack of access to environments, randomly turning things off) meaning development took longer than expected and held up other work
  • Large user stories that had too many areas of complex functionality within them; they needed to be sliced so they could be more easily understood, developed and tested
  • A developer hanging onto their work for too long until they perceived it to be perfect before releasing it to test; this was due to their misplaced sense of ownership
  • Bottlenecks on certain team members or skill sets
  • Inter-dependencies on tasks and stories

During the daily scrum, the team then reassess relevant stories as they discuss what they’ve been working on. The physical action of having to move a story further round the circle forces a discussion about why and what the rest of the team can do to help remove the impediments that may be blocking the developer(s).

The next circle is In Test. The developer moves a story there once they’re happy their tasks are complete. The tester then moves it round to the section representing the day that they think they’ll be able to finish testing.

Once the tester is happy the story meets the definition of done, they place it in the bullseye. 

Bullseye board 2.0

Since the original attempt, the board has evolved and sharpened up it's look. Firstly, Alecia and Erin used a simple string and blu tack technique to make a much neater circle, dividing it into something approaching equal segments. We also used South Park avatar to create a likeness of each other. The rest of the team were encouraged to follow suit after I had created my own - highlighting my lack of hair and slightly angry face. These avatars are used to show who is working on which story, and also just to have a bit of a laugh with each other. It may sound like forced fun when agencies say “we’re cool and relaxed, we have an Xbox in the office”, but it just creates a bit of informality. It’s a talking point. It starts a conversation, and that for me is the most important thing; people interacting. People from outside the team often want an explanation as well!

The finale: bullseye board 3.0

The next significant version (also our current version) was created when we moved to our new office on Jewry Street in April 2015. Most of the walls are painted with whiteboard paint, so it was the perfect opportunity to get one of our designers to work their magic on creating our on-brand bullseye board. We had it printed as a wall sticker on the whiteboard walls:

Bullseye scrum board 3.0

But why the bullseye board?

For me the board has the following benefits:

  • Focuses on the goal and the mascot
  • Represents the cyclical nature of Scrum
  • Highlights when sprints are just becoming mini waterfall phases (all testing at the end) and helps us to remain agile
  • Highlights when stories are continually slipping round the board, so that we can address and remove impediments more quickly
  • Because of all the room around the board thanks to our whiteboard walls, it becomes an informal team noticeboard where anything can be shared
  • The use of avatars allows people to quickly see who’s working on what
  • Creates a talking point for those in and out of the project.

All in all, it's been a great success for us - that's why it's still going strong after 5 years.

Drop a comment below to let me know if you have created or seen any alternative scrum boards. 

Follow infoMENTUM on Twitter