Well that got your attention. Aka sorry about the clickbait.
Context: A large-ish project is using JIRA(*) to manage their work, with varying degrees of success. And they’ve customised their instance heavily. No change was too small, or unreasonable. Over time, their configuration evolved as to be practically incoherent. There’s a parallel with teams maintaining software without paying any attention to technical debt. Things are built on top of other things. Workarounds are invented because it’s easier than refactoring, fixing deep seated faults and moving on. I’m sure most people have had an experience or two a bit like this.
Even your tools like Confluence and JIRA can have technical debt. Remember to pay that back regularly.
When I spent time with them, I came to realise that a significant underlying cause of their tool-based-pain seemed to be rather “simple”. They were not consciously aware of how they worked as a whole. They all knew what their roles were and how to do the day job. They even mostly understood how to work with their immediate neighbours (in a value stream sense). But they didn’t get the whole picture. No-one did. As a result, there was no way of telling whether a JIRA configuration change that would alleviate a local problem would have an adverse effect.
There’s a huge chasm between where they are now, and where they needed to be. Step one was to get back to basics – let them discover how they work (as opposed to how they use their tools) and then help them refine that.
Which brings us to another challenge. It was hard for this project to accept an OOTB configuration – “we do things differently here; we simply couldn’t work with a vanilla installation!”.
So I cheated.
They wanted to work sensibly, so they had great intentions. I tried to use that with a sequence of questions which allowed them to build up a tailored process for them:
Are you sure you want to use Sprints? Yes! Handy, it allows us to have backlogs, sprints, sprint planning, demos and retrospectives.
Do you want to visually track what you’re actively working on? Yes!That gave us an “In Progress” column and state
How do you tell if what you’ve worked on is good enough? We have testers in the team, they work with developers. Before we merge our code, we need to explicitly run tests.That gave us a “Being Verified” column and state.
When do you close off a story? When it’s accepted by the Product Owner.That gave us a “Done” column and state.
What happens when things get stuck? We have a blocked column and we put things in there so our scrummaster has a backlog of blockers.That’s another state & column (**).
When you run your “before-merge tests”, can you start that verification as soon as the developer is ready? No sometimes it takes us a bit of time or we batch up some related work and verify multiple changes at once. That gave us a “Ready to Verify” interim state that testers would pull from.
Is your product owner available at all times to accept stories as soon as they’re ready? No, our product owner has a day job so sometimes they have to batch accept stories. That gave us a “Ready to Accept” interim state that the product owner would pull from.
The final workflow they were happy with looked like this:
The corresponding board looked like this:
If you squint, that looks like Not Started > In Progress > In Test > Done. Which is pretty standard. But because they, as a team, worked through their process, it was their board. They also thought about a few useful elements, such as pulling work when you’re ready to do it, and trying to limit how much they had on the go at any one time.
(*) I don’t mind the Atlassian stack. It works well enough. But if you go well beyond OOTB then like a lot of products you’re flying without an electronic safety net.
(**) I’m not keen on having a discrete Blocked state as I’m a bit nervous of it being seen as a “rug to sweep things under and start something new”. But this team liked it, and it’s their way of working, so I accepted it.
I’m lucky at my current employer, in that part of my job is to deliver a load of courses to help my colleagues make some sense of words like “agile” and “mindset” and to learn about leading brands such as “Scrum” and “XP”. And more importantly, to help them realise that it’s OK to use your brain and common sense at work when trying to apply this stuff to really tough projects (my employer is relatively expensive, so we don’t get simple projects).
I’ve always enjoyed seeing students get a hold of a difficult concept – their eyes light up and you can see wondrous machinery whirring away at internalising their new-found knowledge. And for me, the ultimate in euphoric trip is when they think it’s an idea good enough for them to spend time and energy spreading (the payback usually takes longer as I don’t always find out, but that’s OK too).
This course is new for me though. It’s my first attempt at a train-the-trainer type of course. It forced me to do some soul searching and navel gazing.
Why do I like being a trainer?
What do I look for in a trainer?
What am I wary of in a trainer?
Why does this stuff matter?
What do I want from a trainer-production-system?
Who will the existence of all these trainers help?
Why do I like being a trainer?
I think it is just about seeing ideas enter people and change them (hopefully for the better). Their eyes light up, it’s brilliant. I think I’m just grateful that I get to see this a fair bit.
What do I look for in a trainer?
Someone who’s authentic. They bring their whole self to their course and they speak from their experience. Someone who’s not afraid of trying things out.
What am I wary of in a trainer?
Someone who’s voice and ego is bigger than the message. It’s about them, and how they do stuff.
Why does this stuff matter?
Project life is hard enough as it is. I want people to try and help make things better.
What do I want from a trainer-production-system?
Probably for it to not be a “mass production system” – if I wanted people who could parrot out the precise messages I wanted to give, then to be honest, I’d have recorded myself on YouTube and spent the budget buying Segways and IPads…
Who will the existence of all these trainers help?
The obvious (and stock) answer would be “future students”. But I think it’s the project teams that the new trainers will be in that will benefit the most. Not because they magically get someone who “knows all the answers”. I think it’s simpler, they get a “better team member”. By that I mean someone who doesn’t want to be the centre of attention, but is more interested in helping everyone else in the room (team) improve. Someone who feels learning is important enough to be willing to invest time and effort on it.
(Meta) Course Structure
On this train-the-trainer course, there are three distinct themes that need to come through:
The course content. So they can make the course flow “naturally”
The underlying material and knowledge. So they can speak from a position of knowledge and experience, as well as honesty and authenticity.
The confidence and ability to present / teach. Or even, the “permission” to make the course their own, and find their voice.
We mustn’t underestimate the third bullet, as I don’t think it’s usually something that we have in our minds as (potential) trainers. Especially when it’s someone else’s course. Terms like “Standards”, “Intellectual Property”, “Consistency” etc. all usually surface when broaching the subject of course content alteration for the first time. It’s not that those terms aren’t important – they’re very! It’s just that sometimes the underlying motivation for a course owner may not be the same as a trainer – especially the sort I’m looking to grow.
As a course designer and course owner, I feel successful when the courses that have been delivered/franchised/etc. are run well. The material was easy to understand, and people get what they were expecting. Course feedback is glowing. But that can’t be the only measure of success – a “successful” course that changes nothing in the lives of the students is a failed course IMHO.
So the future trainers of my courses need to be able to change how the courses function in order to give their students the best possible chance of getting something useful out of it. For that to happen, the trainers need to understand the course design and flow. Great courses have a logical flow to them, and there are a lot of hooks to connect concepts together, or to build on ideas. A course that is teeming with knowledge but is presented as a large list of independent facts will be dry, boring, and mostly pointless as the students won’t really learn much (other than how good/bad their cramming skill is).
With these hooks come many opportunities to connect ideas. For that to sound natural and based on what is actually happening in the room, trainers need to have put in the hours – they just need to have lots and lots of facts to draw from, from a huge range of scenarios and contexts. They’ll need to read around the subject. Anything less, then the trainer will spend effort trying to steer the room to a point where one of their pre-canned examples becomes relevant.
But to make sense of all of this potential flexibility, trainers need one more thing. They need to feel empowered to adapt the course to meet the needs that they see there and then, as opposed to what we saw while designing the course in the first place. Usual rules apply here, they need some skin in this game, that it’s their course too and they need to look after it. What they bring to the party, is their voice. How they tell the story, how they weave the narrative through all of those hooks and potential connections that the course material gives them. Course material should never be a paint by numbers. It’s a canvass and a palette for the trainers to produce the right result for their audience.
That is scary for a new trainer. Positively terrifying. What we had to do, was help them get this fear under control.
Some things we did:
Used a variation of “mob programming” so the whole class presented a difficult section on “mindset”
They were unfamiliar with the topic and unfamiliar with the training material, so the mobbing approach would help reduce the fear of the unknown (they’re not alone). One minute timer, so the speaker would change about once a minute, give or take (they all got a chance to be part of it).
That seemed to work well. They were able to come up with lots of interesting observations. There was a mix of “verifying the points were being made, and supplementing as needed” as well as “learning from the speaker and internalising the new ideas”
The proof was in the ability to recall the themes and present the topic confidently the day afterwards. To help this, we had some diffuse time – we let them sleep on it.
Repeated practice runs on “industry standard content” on Scrum and XP
They knew the subject matter reasonably well, but they didn’t know the training material or the defined flow
By splitting them into smaller teams, we took them one step closer to their “training reality” – they’d eventually be teaching in pairs
Smaller teams meant more sessions of the same content, so they could learn by observing others try to deliver the material
We kept things as fair as possible – the first team to try a section were at a disadvantage as the training material was unfamiliar. By the third team, the content was less scary. So we swapped the running order every time a new topic was ready to be practiced.
Multiple opportunities to handle “difficult questions from difficult people”
One of the larger areas of concern for new trainers – what do I do when faced with difficult people?
Ground rules – “ask difficult questions, but don’t be difficult”
DBAD – Don’t be a <swear word>
After three days they were cooked. But we’d covered enough of the scary stuff to think that they could give it a pretty decent go. Not everyone in the class would likely keep training on a regular basis, but they were all keen to try it out, as even if they weren’t selected as trainers, they’d still be better off and so would their project teams. Even the losing side has a positive outcome.
It’s no secret that teams that have a “culture of learning” outperform similar teams that don’t care about that sort of thing. The Internet’s full of articles extolling the virtues of such a culture, along countless articles offering suggestions on things to do that would help you develop your learning culture. There’s a lot of good sense out there, but in my experience, it’s not really possible to develop (or introduce) a “learning culture” as a discrete thing. There is no carrot & stick solution that’s resilient to real life.
The best I’ve been able to do is make it possible for my teams to believe that it’s worth learning new things, growing and sharing. Mostly because it’s more fun that way. As a species, we are if nothing else, driven by emotions. Hopefully positive ones.
Learning new things is a risky business. For a start, if it’s something difficult, or requires lots of practice to master, then you’re going to get things wrong. A lot. Making a mistake is often seen “in the corporate world” as a bad thing. With penalties like “poor performance ratings” if you’re an employee, and terminated contracts if you’re self employed. Ironic really, as we tend to learn the most valuable stuff while making mistakes. So another thing that I do to help my teams, is make it OK to make mistakes, to break things. On one project, that was a counter – everyone was allowed 3 epic fails. On another project, it was “as many as we needed to in order to do the right thing by our customers” (we were very user need driven so we had lots of empathy with our users).
On an explicit front, we introduced “Lunch and Learn sessions” – once a week, for 30 minutes. The list of topics was on a (Product) Backlog – well, a whiteboard with a load of post-it notes on it. Anyone could add things to the backlog, and re-order things as they saw fit, with a deadline of the morning of the lunch&learn day. It started off as me giving the talks, which after a couple of months, saw others offering themselves up as speakers for a subject they were keen on. It wasn’t limited to digital development either. One speaker wanted to talk about macro photography. We were able to round up guest speakers from other projects, and they were usually delighted at the chance, and in payment, we would give a talk to their team in exchange. One session was a live demo – our accessibility specialist brought in a blindfold and some headphones, and we were to try and use the website that we were building, but from the perspective of a blind user. Talk about an eye opener!
On a subtle angle, we used lots of pairing and collaboration techniques to spread the knowledge about, as part of “doing the day job”. We tried to get the default model for solving a complex problem into one where a person finds a teammate with some time and they work it together. So by necessity, we introduced a little slack time to help with this. Irrespective of role, seniority or time on project, we all tried to treat each other as equals (part of our team charter that we signed up to when joining). That made it “OK” for information to flow around, and made it part of being in this team.
If you think all of this sounds like hard work, well you’re spot on. We had to invest heavily into creating the conditions that would make a learning culture more likely to happen, and we had to do it in a way that didn’t completely alienate us from the rest of the world (though there was a rumour that we laughed more than everyone else in the building put together! And despite such frivolity, we were easily the most effective team in the building). We had to sustain the effort too, as we were looking to build a lot of good habits (once an activity becomes a habit, it becomes significantly easier to do as there’s no longer the need for conscious willpower).
Fear. The desire to please. To not look stupid. Bravado. Saying no is hard. It might be confrontational. You might upset them. The world might end. Aargh! Better to say yes and suffer in silence. Martyr yourself.
No to a feature request when your team’s already got a hundred.
No to a suggestion that clearly doesn’t make sense with everything else you’re doing.
No to another task in your in tray that you won’t get to for ages.
Learn to say no. But say it graciously. You’ll build integrity that way. It’s better than leaving your customer hanging, believing that you’ll do something you’re not going to.
“We have to have 2+ years’ experience of everything in the full stack”
“We’ve not got that much development work for the next couple of sprints, so another project can pay for 50% of our developers’ time and get some work done, and we save money”
Any of these sound familiar? If so, you might be trying to have your cake and eat it. “Agile” ways of working move the centre of power into the delivery team, which can be hard to deal with, especially if you’re in a more “traditional position of power”, like a Project Manager or the Head of Department.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
What does that mean in practice when your teams begin to detect a skills shortage? If you’re in a leadership position, you might be tempted to try and fix this – after all, that’s what you’re supposed to do right? Deal with those pesky blockers. You might need to know what the scale of the problem is, and seeing as you recruit in whole numbers, you might need to translate the size of the problem into a “number of developers”. What sort of skillset should they have? Your team’s trying to do some complex stuff, so you’ll need someone who could do all of it right? Your management structure or your client is complaining that work isn’t going fast enough to meet a key date so you’ve got to increase your capacity somehow?
It’s worth taking a step back to think about just what the team is responsible for. It’s pretty obvious that they’re responsible for doing the actual work. What can sometimes be overlooked, is that they’re also responsible for how they do the work. And that includes who does the work – part of the team’s responsibility is to make sure it has all of the skills needed within the team. If they’re detecting a skills shortage, they’re best placed to try and find the right fit.
As a leader, you’ve got to worry about your organisational recruitment – pay and conditions, legal requirements, that sort of thing. But don’t let the mechanics of recruitment be your only process – make sure you’re recruiting the right person for the team. You’re not looking for a generic skillset, you’re looking for someone to fill the very team specific hole they’ve got. And they know exactly what that hole looks like. I’ve had the most success when I’ve let the teams recruit their team members, and the leaders sort out the paperwork.
And as for the third example at the beginning – my only real advice is to avoid doing that. Teams are entities in their own right and it’s well worth thinking about them as atomic units. Chopping and changing internal team structures is generally only really good for disrupting the work. If your team’s got a little slack time, use it productively – pay off some technical debt (there’s always some). If you’re in the ideal situation, then why not just reward the team with some R&R? They’ve probably earnt it.
The following diagrams show how one of my projects applied User Research to drive the software development process. There were two distinct modes of operation – before we went live with Release 1, and afterwards.
Before Release 1
Research was lab based, and essentially theoretical – we would do the best we could to recruit actual and potential customers and find out what they would do if they were faced with our system, and these test subjects would do the best they could to pretend that they needed our services.
Here’s a simplified workflow:
We would start off with a hypothesis, which we’d refine by thinking about it and working with the business. We would design how the lab would run, what experiments we’d perform, all to maximise the learning that we could get from the lab. We’d build multiple prototypes to test the variations on the theme and we’d conduct several lab sessions. At some point our analysis would show whether or not the concept we tested had legs, possibly requiring a few refinements and retests. If proven, we would then tease out what we needed to do to deliver a product increment that capitalised on what we’d learnt, build it and demonstrate it to our stakeholders.
At this point, we’d hope we’ve done the right thing. We’d only really find out when we deploy into production.
Production Based Research
Even after we’d gone live for the first time with our Release One, our reliance on User Research remained. We’d still come up with hypotheses and design suitable experiments to prove or disprove them. All that fundamentally changed though, was how and where we ran our experiments.Instead of conducting the experiment with theoretical users and pretend demands like before, we’d employ A/B or multivariate testing, build alternative flows through our system and just measure what our actual customers did. To measure demand for a new feature, we’d just put a button on the screen and count the number of times it was clicked (users would be given a “we’re assessing the demand for this feature, your interest has been registered, in the meantime do this” message). The proven hypotheses were demonstrably proven as the outcomes were better (as opposed to before when they were still technically just theoretical). The cost was that disproved hypotheses needed additional work to remove the code from the live system. We thought it was a cost worth paying.
A quick trawl through the internet with this blog post as the search term throws up lots and lots of results that all assert that user research is indeed a team sport. However, far fewer seem to go into why it’s important. Sure, the “usual stuff” about collaboration leading to better solutions because the problem is being observed through different lenses is certainly true, but that’s really about collaboration, and not about user research.
So why then, is user research specifically a team sport?
One thing I’ve observed, is that participation in user research sessions tends to make a somewhat abstract notion of a “user” rather more tangible. Painfully so, in cases where your users are vulnerable segments of society. It builds empathy.
Empathy’s a powerful motivator. One common effect is it can instil the desire to “do the right thing” especially if it helps someone. An effective team is one that has a shared purpose. And worthwhile purposes (i.e. helping someone) are fantastic motivators. If only half the team are motivated in this way and want to “do the right thing” and the other half aren’t, then you’ve probably got a problem.
It’s more than the pithy slogan “user research is a team sport”. The whole team need to feel motivated to “do the right thing” and user research makes it possible to tell just what that is. Just one reason why research should be a team sport. Surely this one’s enough?