Going digital to save Taylor & Francis 150 hours a week

“Our e-copyright system was a relatively simple idea that required some fairly complicated problem-solving to make a reality. We worked side-by-side with True Clarity throughout the process to make sure the product we ended up with didn’t limit our flexibility. We appreciated the willingness of True Clarity to have people doing the development work available to us throughout the process. ”

Edward A. Cilurso Vice President – Production

Taylor & Francis Group are one of the world’s leading publishers, releasing over 2,100 journals and 4,000 books annually, with a backlist in excess of 60,000 specialist titles.

What was needed

Taylor and Francis (T&F) have to handle around 250,000 copyright agreements annually in order to publish articles on their site. Getting these agreed involved a lengthy process of emailing out forms, toing and froing through lots of amends and relying on scanning, faxing and emails to log author’s approvals electronically. The business case was crying out for moving this process online, in order to eliminate the pain for authors and staff, save time and keep up with the competition’s online offering.

How we tackled it

Prototypes and early delivery

We kicked off with a discovery phase, involving a few workshops and sessions to completely map out the process, then put together some flow charts to illustrate how we would automate the copyright process. At this stage we carried out some proto-types to validate the approaches, flesh out the unknowns and start delivering to T&F as early as possible in the project. Beyond the author approval on-site, we also needed to map out the integration points with internal legacy sites, such as the production and content management system, and map out some complex workflows to keep the site as self-sufficient as possible.

Designed for Flexibility

The site was designed to present the author with a set of questions, which dynamically change based on their response. The outcome is then used to generate a personalised version of the copyright agreement for the author to agree and submit. Key to this project was to ensure migrating the process online didn’t take away the flexibility of the manual process, so we worked with T&F to create a sophisticated back end allowing T&F to define the routing of questions and answers used to generate the copyright agreements. We also created a number of customisable email templates sent out for different statuses, including reminders for authors who may not have completed an agreement after X amount of time.

The Value

Copyright agreements turned around much faster

T&F sent out 193 author publishing agreements upon launch. 118 were approved within a week, with the vast majority clicking standard options, requiring no further intervention from T&F and minimal enquiries. The approval of 118 licenses would have averaged a longer turnaround, with inspection of each form, using the old process.

Saving staff time on menial tasks

T&F are able to compile detailed weekly reports from the author approval system based on the current status of manuscripts, licenses assigned per country and APAs completed by day. T&F have calculated from the initial launch stats that the new system will save them up to 150 man hours per week – the equivalent of four full-time staff members.

Catch 22: Building Great Software

Building great software is hard. It starts with the choices you make and making great choices is really hard. After all, given the choice, we’d all choose to make great software right? So what’s the catch?

Picture a young guy out to buy a car. He really wants a convertible, it really fits with what he wants out of life right now. So he buys a convertible. He meets a girl, settles down, and before you know it, a baby is on the way. Now the convertible isn’t so great. What helped him when he was dating isn’t much help to him now. Now he wants a saloon!

Our current choices often conflict with future circumstances, however, if we focus too heavily on the future, we may actually make decisions which conflict with the present. A decision which is great for the future might be terrible news right now and vice versa. So how do we deal with this conflict? As it turns out, we tend to deal with it rather badly.

Decisions go stale. As business needs change, what’s relevant today is no longer useful in the future. In software development this means each feature will at some point fail to be relevant. Developers can see this as a failure to make the right choice rather than accept that ultimately our decisions will at some point be irrelevant. It’s likely that given such failure there will be the belief that enough learning took place to make a better decision in the future. We completely ignore the fact that at some point those choices will also become stale. Rather than turn our attention to being good at handling change, we repeat the cycle of trying to improve our decision making process on the basis that we’ve learnt enough that it won’t happen again. We naively think that next time our decisions will stand the test of time!

In extreme cases decisions can go stale before we’ve even acted on them. Businesses don’t wait for you to finish, they continue to change and learn. Being mechanically minded, let’s say we decide to build a saloon. This will take some time. While we’re doing this our child could grow up, leave home and we’re left wishing we’d built a convertible.

The conflict between present and future choices creates a problem in defining a successful software project. Success or failure at this level is outside our control: we can’t predict the future so we don’t know how relevant our choices are going to be over time.

In order to handle this conflict, we have to make it a non-issue. We have to be successful at adapting to change. What really matters to our success or failure is our ability or inability to respond quickly to change. When we can’t adapt quickly to changes, such as new or revised requirements, we have ultimately failed to manage the conflict. The good news is, if we understand that we have failed to respond quickly, we can invest time in understanding why that is and learn from this failure in order to improve our software development process to better handle change.

For a software team to be successful at adapting to change, you need to understand that you’re biggest asset or liability is your code. No decision you make can ensure your code outlives its usefulness, all you can do is ensure you can change it quickly, easily and without risk. To do this you will need clean, loosely coupled, well structured, unit tested code.

Similarly, business stakeholders need to help break the mind-set that features are perpetual. Software is evolutionary and features carry an amount of speculation about current and future value. Rather than telling developers what the business needs (or developers interpreting needs as perpetual), a “let’s try this next” approach to implementing features helps to reinforce the understanding that change comes with the territory.

Focus on handling change well. Your process should be about improving the ability to handle change by understanding and identifying your failure to respond quickly to change. Loose the ego and stop being frightened to admit failure and maximise the opportunity to learn as much as you can for the next change – it’s definitely coming!

Context Switching

The dreaded context switch. I hear about it all the time. I have to drop what I’m doing several times a day to listen to people discuss it (chuckle). Jokes aside, I’m genuinely interested in the reasons why people want to avoid switching context.

Up until very recently I was convinced context switching was a bad idea. I would also have assumed any books that deal with context switching would justify my belief Q.E.D. style, case closed. I’ve been wondering lately if my thinking is broken and that I’ve been fighting for the wrong cause.

So what is context switching? In my world we are talking about changing from one deep train of thought to another. As a developer it takes me a while to get my head round the code I’m looking at. If I have to break my concentration, clear my registers and push what I was thinking about onto my mental stack for later, it takes times. A familiar example would be working on the code for a project and an urgent problem comes in that requires my attention to be diverted to the codebase for another project. Everything I was holding in my head about the code I’m currently working on gets lost forever as I bring my thoughts to bear on a different problem.

Now I’m sure you might be thinking there are also sorts of time management practices you could apply to handle this. However, I would urge you to think twice about how you tackle context switching. Is it really a good idea to rush into this problem with your productivity hat on and try to optimize the process to avoid context switching? If you do, much simpler and more important questions may go unanswered: are people finding context switching hard? If they are: why is that?

Recently I read two very different books. Although they turned out not to be so different after I’d read them. One was on psychology, the other development.

The book on psychology “Think Fast, Think Slow” discusses how we handle the process of decision making and problem solving. It will come as no surprise that we need to engage a large percentage of our brain to solve problems. The harder the problem the more time and thought you will need to understand the problem and resolve it. My take away is that there are types of work that we struggle with. We’ve all put a book down because it was just too damn complicated. We’ve all read a book where each page was jammed so full of information it took ages to read. I’ve also read similar sized books in a few hours. Those books I’ve read quickly were just… well, less complicated!

The book on software development was called “Clean Coder”. It challenged some of my long held beliefs about good software development. It especially challenged how I think about being in the zone. I love being in the zone. I love being so engrossed in difficult problems that hours seem like minutes. I love holding hundreds of lines of code in my head trying to figure out where it’s going wrong. I’ve woken in the morning knowing how to fix a bug in some thousands lines of assembler I’ve memorized. It’s addictive and gratifying. There can be a certain amount of bravados about being better at handle complicated problems than others. Is boasting about fixing really hard code like totally unreadable assembler a good thing? Is being so engrossed in a problem that you lose sight of the big picture the best approach?

Both these books were telling me something about complicated work. It can be difficult to get your head round. We don’t want to be disturbed when we’re engrossed in complicated work because it’s difficult to get engrossed. If you like a challenge, it can be a lot of fun. We don’t want to be disturbed when we’re engrossed in complicated work because we’re enjoying ourselves. Whether context switching is time consuming or a killjoy, the fact is: difficult challenging work is time consuming.

If context switching is a problem, you need to understand if the work is the underlying cause.

Maybe you’re thinking: “Duh? Of course software development is hard. We need to focus more and have less distractions to deal with it!”

Maybe you’re thinking: “I kind of get it, but we can’t make the work less complicated, we have no control over the work coming in!”

Maybe you’re thinking: “How can I make the code I have to read all day simpler and clearer?” If you’re thinking about the possibility of making things simpler, you understand.

It’s just like ‘Grand Designs’

I was sat watching ‘Grand Designs’ with my wife a while ago (It’s not a programme I would normally watch, but I was looking to earn some brownie points at the time) and I noticed just how agile the couple were in terms of creating their perfect home. For those who don’t know, ‘Grand Designs’ is a programme where couples design and build their dream homes (some of which are truly amazing). The couple on this particular episode had some basic requirements for their new house in terms of size and location but that was about it. They had bought some land in a nice location, received the designs from the architect and started building. This seemed to surprise the presenter of the programme, who was astounded that the couple hadn’t worked out all of the tiny details for how they wanted their dream house to look and what it would contain upfront. He made his opinions clear to the couple that he thought they were mad to start with the actual building of the house, as they would surely end up wasting loads of time and money.

What actually happened astonished both him and my wife (who had agreed with the presenter’s views), but will come as no surprise to those of you who use agile on a day to day basis. As the house went up, the couple worked through each stage of the process, always staying just one step ahead of the builders. They made sure that they had narrowed down the requirements for the next part of the build, just in time for when the builders got there. They were always on hand, ready to provide guidance or offer feedback on certain aspects of the build. The build was completed on schedule (almost unheard of on this programme it would seem) and the house met the couple’s requirements and expectations.

This may not have been software development, but we can still see the agile process at work here with a Stakeholder/Product Owner prioritising their backlog in terms of importance and providing continuous feedback. They only worried about the small details when they were sufficiently close to being worked on by the builders, as opposed to getting all the specifications laid out at the beginning.

It just goes to show that provided that you apply it properly, the agile methodology comes up trumps every time, even outside of software development.

All I need to do now is convince my wife to live in a house that looks like a castle and we can get started on building our ‘Grand Design’!

Kid’s stuff

There’s no doubt that asking the right sort of questions [not just in sprint retrospectives] can elicit the kind of information which empowers teams to reflect on what they’ve just said, what has happened and then, ultimately, lead to changes in behaviour, processes, etc.

So why is it then that children find it so natural to do just this i.e ask the kind of questions that really force you to think about what it is you’ve just said?  Well it’s obvious isn’t it, they’re simple beings and so can only come up with simple questions right?  If you haven’t got kids yourself then maybe it’s harder to remember the kind of things they say or that you used to say when you were a young ‘un.  Here’s an example:

Son (who’s 4):  “So why was the rabbit afraid of the dark?”

Me:  “Er, well, because he was on his own and wanted to get home.”

(I should probably say at this stage that we were reading a story)

Son:  “Why?”

Me:  “Well, because he had lost his sister and she was looking for him and at night, when it’s dark, lots of animals get scared?

Son:  “Why?”

Me:  “Well, they’re like people;  you sometimes get scared when it’s dark don’t you?”

Son:  “Yes.  Why?”

I won’t bore you with the full conversation but it certainly made me think about how powerful simple questions can be.

The “five whys” technique in retrospective meetings is just one of many tried and tested techniques to generate insights into any data gathered from looking at what happened in the sprint.   In my short career as a ScrumMaster, I haven’t yet been on the receiving end of the five whys questioning so it was interesting for me to feel the effects of a technique about which I had read and tried out several times on others.  Ok, it may have been a four-year-old, but it still worked!

Kids don’t have the inhibitions which we all pick up along the way and can think and act in a very pure way without even trying.  Our own self-awareness, confidence and experiences just get in the way sometimes both as the person asking the questions and the person answering.

It’s not very practical to suggest that we all start acting like a four-year-old but we could all learn something from them!