Multidisciplinary Teams vs Teams of Multidisciplinaries

Two working days from the end of Sprint Three, here’s how our “Task Time” burn-down looks:

Screen Shot 2016-05-12 at 17.01.27

Sprint 3 Task Time burn-down

It’s remarkably similar to Sprint Two’s, with the red line never really catching up to the grey guideline, and with red and green crossing far too far to the right of the mid-point of the sprint for my liking:

Screen Shot 2016-05-12 at 17.02.51

Sprint 2 Task Time burn-down

This is over-commitment, pure and simple. There’s pretty good symmetry between the red and green lines, so assuming that nobody’s “gaming” the stats this would imply that our estimates for how long each Task will take are reasonable. Where we’re falling down is planning how much of our time we’re going to have available to work on Sprint Tasks.

Reflecting on why we’re falling into this trap two Sprints in a row, and thinking back to Sprint Planning, I was struck by a thought. We call ourselves a multidisciplinary team because we have all the skills needed to deliver our software:

  • Tech Lead
  • Front-end developer (PHP)
  • Back-end developer (Java)
  • DevOps
  • User Researcher
  • Designer
  • Test Lead
  • Tester
  • Product Owner
  • Scrum Master

The problem with this, is that we have one person who can do each role. If that person gets stuck, there are very few options to provide them with a bit of extra support. The developers can go to the Tech Lead, who understands both the back and front end, but he’s a busy guy already. Likewise, if my tester gets stuck on his cucumber/selenium/Jenkins he can go to the Test Lead, who also has a full workload.

For all practical purposes, there’s absolutely no fungibility. For example, the back-end developer has massively improved the performance of API call “bobbins” by rewriting the entire thing. He’s kept it functionally identical, but has put his new work into “bobbins2” at the insistence of the Tech Lead who apparently has a Thing™ for backwards compatibility. This means that to benefit from all this good work, we need to update the front end every place it calls “bobbins” to add a “2”. Simple, right?

Except that the back-end developer doesn’t do PHP. He hasn’t got the code. Or an IDE. Or know how to release it back. So now we have to add a new Task to the Sprint so that the Front End developer can add some 2s.

Now imagine if the back-end developer had some rudimentary PHP knowledge. It’s a fairly simple search-and-replace job, so it’s not like he needs to understand the finer workings of <insert heavily nuanced PHP subtlety of your choice here>.

I’m not suggesting that the only good team member is the one who can do everyone else’s work as well, just advocating T-shaped skills rather than I-shaped.

Marvo the Marvellous Multi-Tasker

Frustrating times.

One of the team, let’s call him “Marvo”, wasn’t too sure about how to break his work down for this sprint. He was planning to use a new-to-him tool to do something he’d not done much of before. With that much uncertainty I created a Spike for him, time-boxed at three days, to spend some time getting to grips with the tool and the work.

So far so normal.

My first mistake was that I didn’t book the review meeting at the end of day three. Nor did I stick a reminder in my own diary to check in on Marvo in case he forgot.

My second mistake came half way through day two, when Marvo indicated that, having talked things over with the consumers of his work, he changed his mind about which tool to use, and would now go back to using an old, familiar tool instead. My question, “how much time will you now save?” was answered with: “None.”

That loud noise you can probably here,  that’s the Agile Violation Alarm going off in my head. Unless it’s your own AVA going off in your own head. It probably should be. With a bit of follow-up questioning, it turns out that there was as much uncertainty in the scope of the work as there was in the use of a new tool, and doing the same work in a familiar tool was still a largely-unknown task.

In retrospect, the right thing to do at that point was probably to start a new time-boxed spike for that work in a familiar tool. What actually happened was that the vague and woolly “do the work in a new tool” Task remained as-is in Jira, and was joined in the “In Flight” column by all the other Tasks for Marvo for this Sprint.

The explanation was one I’ve heard before many times: “they’re all kind of interlinked.” That translates in my head to “Either I have no idea how to break the work down into distinct, measurable tasks,” or “I’m not willing to expose the work to you in distinct, measurable pieces because it leaves me no place to hide or dissemble on whether I’m making progress or not.” I’ve worked with people who meant it both ways, sometimes at the same time.

The only thing that I’ve found works is to keep coaching them to think about what they’re actually doing and guide them into slicing their tasks up differently. On this occasion it only took a couple of sprints, but I’ve known it take much, much longer.

A Pointless Retro?

I’m a big fan of the Retrospective. I have always thought of it as the most valuable of the Ceremonies. It’s a fantastic way to get a team to open up about what’s bothering them in a way the stand-up’s “blockers” question just doesn’t allow. It’s a safe environment for them to raise anything at all that’s bothering them.

I ran a retro today for the end of my new team’s first sprint, and for the first time I almost wish I hadn’t bothered.

The team has nine members, including me. One was on a course (and missed it), one can’t get into the building yet (and was on the phone), one was working from another building (and was also on the phone) and one was travelling (and missed it). Five out of nine, not a great result for my the first run of my favourite Ceremony.

During the sprint, roughly half the team were out for roughly half the time, some of which was expected and some of which wasn’t. The result was that, while some Good Work has been done, we’ve not delivered much. The reasons for this non-delivery are immediately obvious to all concerned and the sprint is being flagged as “successful” rather than “failed” largely because the team did all the right things at the right time and calling out a failure in the circumstances wouldn’t add any value.

The problem with today’s Retro was that there wasn’t really that much to discuss. One team member isn’t a fan of Retros at all and was very vocal about how the whole thing is a waste of his valuable time (he’ll learn) yet contributed the most in terms of things to get sorted out. “What went well?” was met by complete silence – nobody had anything to call out for protection in future sprints. “What didn’t go well?” had only a couple of token issues: internet connectivity is patchy from time to time and could we arrange some walkthrough sessions for the newbies.

Where I take satisfaction, however, is that the Retro was fitting for the Sprint. As I wrote earlier, in an ideal world, we’d have waited a week or so to start the Sprint and we would have used that time exclusively to make sure that the stories were in a much better state before starting. Outside of that rose-tinted fantasy, however, the team now understand all the things I expect to happen in a Sprint. They’ve attended all the ceremonies, even if only in a half-hearted manner, and doing things better in the next Sprint won’t come as much of a shock to the system.

To answer my implied question in the title of this post, no, the Retro wasn’t pointless. Not as rich and rewarding as many other Retros I’ve run, admittedly, but fitting for the Sprint and the Team and a good use of half an hour of our time, definitely.

Running before walking

New job, new product, new team, let’s make sure we start as we mean to go on and Get This Right! Right?


This time.

The product might be new to me, but it’s been around for about a year or so. The result of a project that ran out of budget somewhere during Alpha and was put live anyway, there’s already a long list of things that the users hate and that need to be fixed, but almost none of the entries in that list stand up to any kind of quality review for a Story.

Most of the original team have left and half the new team only were only due to arrive during the second half of what became the Sprint, so with the backlog in such poor shape, we were nowhere near ready for a Sprint to start.

I started a sprint anyway.

With a couple of days to run this sprint, the burn-down looks like this:

Screen Shot 2016-04-15 at 10.57.47

That big spike on day 2? We added one Story to the Sprint because it had one Task still open even though the Story itself was closed. It brought loads of work with it (work goes up) which was already done (work goes down again).

That cliff on the right-hand end of the red line? We dropped a Story into Sprint 2.

The long expanses of horizontal lines on both red and green? People weren’t used to updating their tasks, so didn’t.

Two people joined the team on April 12th. One of the existing people went on paternity leave on April 8th. Two people were on holiday until April 11th.

If our goal was a pretty burn-down chart, starting a Sprint was a terrible idea.

My actual goal was to highlight to everyone that would listen that getting Stories into a good state before you start a Sprint is important. Not because it lets Jira draw a pretty graph, but because the ugly graph is a symptom of a team that doesn’t know what it’s supposed to be doing. It’s clear from the interactions I’ve seen between the PO and the developers that priorities have been changed on a day-by-day basis, that nobody really has a handle on enough of the detail of any of the work and that I’m going to be gainfully employed here in this role for several months to come!

The Honeymoon Period

I started a new job just over a week ago.

The new team, uniformly, are lovely. My Head of Function is a delightful mix of welcoming and supportive. The work (software used internally in government) is interesting, the project (rescuing a partly broken and thoroughly hated product that resulted from a failed earlier project) challenging, the tools (jira, a MacBook Pro to my own specification, O365, Trello, Slack, Jenkins, etc) effective, powerful and current-century. I’m in Heaven!

Except, of course, this is the “honeymoon period.” The team are about half new, half old hands, so everyone’s still in the cautiously polite ‘norming’ phase. The project is a freshly-kicked-off reincarnation of something from last year, so the stakeholders have easily-met, low expectations. We’re still hiring to fill out the team, so the workload for me as a Scrum Master is still relatively low – nobody’s bringing me much in the way of blockers yet because we don’t have that much in the way of work yet.  Honeymoon.

Still, it’s been over a week and nobody, yet, has asked me to do anything blatantly stupid or obviously pointless. It bodes well (or at least, better than my previous role) to have lasted this long in that happy state. And there have been a couple of frustrations around the time it’s taken to get a security pass of my very own, rather than having to be escorted around the place on a V-badge and a couple more days working from home as a result than I would have liked this early on. Nowhere near enough to dent my mood, which has been, frankly, amazing for the past seven working days.

I can’t remember the last time that was true.

Today, for example, I was happily playing with Jira, reviewing who’d done what (in terms of Jira stuff, not in terms of ‘real’ work) to work out who needed what help and in what priority order, and thinking about which of our ‘almost ready’ stories to take to the grooming session, and wondering how I go about booking a room to schedule that session and generally wallowing in Scrum Mastery Goodness when I happened to switch to the screen on my Mac that still has the clock at the top and realised that I could have left over an hour ago and probably should have left at least half an hour ago. It reminded me of something I think I’d forgotten somewhere in one of my past three or four jobs:

Working on something you enjoy doing, with tools you enjoy using and people you like spending time with isn’t “work”.

You get paid for it, you’ll catch hell if you mess it up, and you’ll probably end up putting yourself under more pressure than anyone else could ever manage, but it’s not “work.”

I told myself this afternoon that it’s just the honeymoon period. I told myself it won’t last. I set myself up for that moment when disappointment strikes and it all just becomes “work” again, but that’s just dumb. Maybe it will. Maybe it won’t. Worrying about it, becoming cynical ahead of it, is pointless. Bringing that kind of negativity to the office is a terrible idea, one that will only serve to hasten the end of this state of occupational bliss, when the truth is that I can’t remember being happier in what I do and how I do it.

Yes, maybe it’s just the Honeymoon Period. I plan to enjoy every single day of it as if it’s the last, and in doing so perhaps it’ll last a bit longer than it otherwise would.

Print(“Blog Time! Round \(++failureCount)”)

(So much for good intentions. This sat in my Drafts folder on here for almost six weeks!)

I’m a self-employed contractor. I don’t have an “Employer”, I have a “Client”. Today I decided to leave that client and take on a new one.

I’m not an employee. I don’t have to do all that tiresome “performance management” stuff that employees have to do, because I’m a contractor. I don’t get holiday days or sick days or employment benefits of any kind unless I pay them to myself from my own company.

So why do I feel so guilty?

My current client is a large, high-street brand name with a significant digital presence. They’re probably not the best at what they do, but they’re good. Customers seem to love our work. The client looks good on my CV (contractors still need CVs, just like employees).

So why am I leaving?

I’m leaving because, in my current client’s organisation, everything is hard. I’m not one for whining. I’m not having a go. It’s not that the team, the department, the project or any of the things that cause many people to become disgruntled and leave organisations.

It’s because Everything is hard.

Not “some things are harder than they should be.” Not “this thing I’ve been trying to do for ages has continued to be impossible because of stupid reason X.” Everything I’ve set out to deliver over the past two years, I’ve delivered. More than half of it on time. More than half of it with quality far higher than the norm for the environment. But every little thing, every step of the way, is hard.

Everything you want to achieve requires significant effort, buy-in from stakeholders, process, paperwork, approvals galore, obscure regulations that you didn’t follow because nobody ever mentioned they exist, entire processes that have remained undocumented for YEARS, including “Deployment into production”, which run differently every release cycle because there is literally NOTHING written down and the “right” way to do something depends on which member of the deployment team you ask, a separate entire function called “DevOps”, who are neither developers (with the power to change or test code) or Ops (with the power to investigate and correct operational issues), I could type all night.

I come from an Agile background. I’ve had years of experience Inspecting and Adapting. On my CV, right near the top, it says “I like to fix broken stuff.” I’ve spent two years mashing my face against the bare brick walls of “because that’s how we’ve always done it” or my favourite from a divisional COO recently “do as I say, not as I do” and it’s time to stop.

Time to walk away. Time to remind myself that they’re not my Employer. They’re my client. They pay me money to do stuff for them, and if I don’t want to put up with this, I don’t have to. They don’t own me. I don’t have to give three months’ notice and slog on to the bitter end. I’m a contractor. My notice period is twenty-eight days. Four short weeks.

On Monday, I have an appointment to tell my Assignment Manager that the clock has started ticking.