Estimation is hard. An analogy…

A fleeting thought over a cup of tea, a mind full with work and triathlon training and an overheard conversation led me to this little beauty…

Stakeholder:

“What’s with this cone of uncertainty, why do you have it?”

My mind:

Well, how fast do you swim a 100 front crawl in a 25 meter pool? (I know you’re not a swimmer).

In my head Stakeholder:

Well, I’m not sure, I’ve not done it in a while.

My Mind:

So if I asked you to hazard a guess, knowing you can swim, what would it be? and how would you go about making a better guess?

In my head Stakeholder:

I’d likely ask what the world record is, or how fast you do it and your background.

My Mind:

Relative sizing, nice. How could you be most accurate without swimming the whole 100m?

In my head Stakeholder:

I’d maybe swim a portion of it and take a guess from there. Say…25m and * it by 4.

My Mind:

Great, projected velocity…So what if you can’t do any of that?

In my head Stakeholder:

Well, I’m sure I could do it within…a day, a week, an hour, half an hour, 10 minutes, probably 5 minutes or less.

My Mind:

So give me your optimistic time and your pessimistic time.

In my head Stakeholder:

Okay. 1 minute to 5 minutes.

My Mind:

Great, so 3.5 minutes ish…thats a reasonable guess for a leisure swimmer who has no idea. I’d make an educated guess of about 2 minutes but I’ve never seen YOU swim so I’d be making a general assumption. If I knew you were a very good swimmer I’d be saying just over a minute, someone who can doggy paddle…lets say 5.

Moral of my mental drift

Estimates are individual to the person carrying out the task, are based on knowledge already known/not. Where possible we relative size to make our estimates better informed and based on past performance. When its a team of people, we have to account for that range of abilities, knowledge and prior experience, hence the range in our estimation.

 

The key traits of a great agile hire.

In an agile organisation every person you hire is critical to the success of the company. When there’s no organisational compartmentalisation of people, adding someone great can add great value, but on the flipside there is no limitation to the damage that someone who isn’t right can make.

A few years back I went to watch a rehearsal of a talk my partner was delivering with two former colleagues. They’d all worked within an extremely experienced and mature agile team in a well known investment bank spanning 3 ‘generations’ of the team. When looking at success factors of the team the talk turned towards hiring and firing.

I can remember my shock when the most experienced coach on the team spoke of how critical they were when hiring and more importantly how happily they would get rid of members who just didn’t fit. It sounded to me like they didn’t give people a chance…

I was intrigued though, as this team were well known for their successes within a tightly controlled and rigid environment.

A few years on and a lot more experience growing agile teams, I have a little more insight and perspective on what I heard that day, and agreement for that matter. I understand that in a flat hierarchy with no management it can take longer to recognise underperformers which is why it’s so important to get hiring right. I also recognise that there a few key traits that you’d look to hire for and a few behaviours that you should think about moving out of a team.

Now, it’s worth pointing out that there will always be individual team dynamics that will come into force when hiring someone from the team. The team will be looking for complementary traits or someone who can fill a void (outspoken or quiet, introverted or extroverted etc) these are a given for the purpose of this article. The things I’m talking about here are what I view as some of the fundamentals to be a good fit in an agile team in general.


Key Traits-

People who work well with ambiguity, self starters.

No mummies boys and girls, no one who requires spoon feeding. Only self organising, answer seeking, driven individuals need apply. No one will come up with a solution for you, nor will we tell you how to do your job. It’s assumed that you’re the experts, therefore you can make the expert decisions on how the work gets done. You’ll be given a very clear idea of the why and the what…that’s it, the rest is up to you.

Team Players, T-shaped generalists.

You can’t have a team full of mavericks and maradonas (or Balotellis). Even if they can do the job technically, or have ‘moments of genius’.

In an agile team of T-shaped generalists (google it), with no defined roles, a team player will fill the gaps to progress the team towards their goal. A non team player is likely to play the role they feel best benefits them and their career. 

You can’t plan for moments of genius, and individuals who outshine the team don’t move the team ahead, you need reliable performance from people who are prepared to share their skills not progress at the cost of others.

A great ted talk from Margaret Heffernan on this particular topic and ‘Super Chickens’ well worth a watch- https://www.ted.com/talks/margaret_heffernan_why_it_s_time_to_forget_the_pecking_order_at_work#t-173183

People who aren’t afraid to fail

It feels fairly obvious but they’ve got to have a mindset of “I’ll give it a go” and not get married to ideas before they’ve been tested with the users.

This falls under having a nature of curiosity and being up to explore. Users will always surprise you, so you have to be prepared to offer something up that you’ve worked on for weeks (possibly months) to user testing and take the feedback as a positive enhancement to your product.

This also applies to evolving how the team works and its processes. The best teams are open minded to change, to trying something and to canning it with no regret if it’s not right.

Growth Mindsets vs Fixed Mindsets

In the book Mindset, Carol Dweck makes the point that people with a ‘growth mindset’ will always outperform those with a ‘fixed mindset’. Those with a fixed mindset believe that their attributes are fixed for life i.e. “I’m no good at maths”, whereas a growth mindset will believe this can be changed with effort, “If I practice and practice I’ll get better at maths”.

People can change to have a growth mindset but it requires a lot of coaching and encouragement that praises the process and not natural skill “ You did a fantastic job on that ” vs “You’re a fantastic developer”. You’ll be giving your team a massive head start to hire those who display a growth mindset outright. These people are more likely to “stretch themselves, take risks, accept feedback and take the long term view” in the words of Chip and Dan Heath in their book Switch.

Self improving- receptive to learning

An agile team needs people with a thirst for knowledge who are never happy with the current amount of knowledge they have. Where a team is continuously improving the people within it should be too.

If the team members are not furthering their knowledge then the ideas the team have will become stale fairly quickly and they will reach a ceiling of improvement. No one will spoon feed you in an agile organisation (see point one, no mummies boys/girls) so members must seek knowledge, ask questions, learn from others, share the knowledge.


So that’s the desirables to hire, if these things are lacking in a member of the team then I’d suggest replacing them with someone that does exhibit these traits. The longer they are in a team the more damage it can do to a team and its morale, and a team morale is a hard one to recover once it’s hit the floor. Along-side these traits are some behaviours that I look out for and either ‘coach out or move out’. I don’t give people a long time to change once they’ve had very clear feedback about these things because they are superficial behaviours that should be easy to change and in a world that iterates and changes so quickly, we can’t wait, it’s as simple as that.


Coach out or move out behaviours:

People who complain…but never suggest any improvements. It’s just negativity, it’s not helpful.

People who are just ‘here to do their job’: and therefore won’t step out of the box and help others.

Those who are precious about their work: and therefore won’t surface it, share it, pair on it, listen to any suggested improvements.

The antagonist: the person who just loves to argue for the sake of it..they’ll waste time and money.

The PR Guru: the person who believes perception is everything and thus spends all their time pruning their ‘brand’ and very little time actually doing work.

The one that won’t talk in meetings but then completely derail plans afterwards with their input.

…There are many more, I know this, I’ll pause there for now.


How to hire to maximise success:

There are some simple things that can help maximise the chances of the hire being a success (other than looking for the desirable traits above).

Not just filling numbers

Hiring just to fill numbers will do more harm than good. The time spent investing and dealing with people without the right skills or traits will waste more time than it will increase productivity. The wrong hire will do more long term damage than waiting for the right hire.

Drip feed the team

Don’t hire lots of people into an established team all at once and expect productivity to be maintained. Introducing people gently will do the least damage and give the newbies the best chance of success. This will also mean the team dynamic doesn’t change too suddenly, the impact of one newbie is rarely enough to change the team completely if you’ve hired well (assuming you have a dynamic you don’t want to mess with).

Keep experience to inexperience ratio 2:1

Carefully consider the experience balance in the team. A nicer way of saying, don’t saturate your team with lots of juniors who are just starting out their career. The wrong ratio will overwhelm even the most advanced and experienced of people.

Let the team decide

Hiring should be carried out by or at least agreed by the team. An cohesive team will know what will work. Listen to them. Don’t hire for your ‘vision’, let the team inform and agree upon the skills gaps to be filled and let them find a personality that they’d like to work with. They are the ones that will have to work closely, or pair with that hire. With a good team bond comes improved productivity; you’re much more likely to achieve that if team members have chosen who they work with.

With an inexperienced team, assist in vetting, but final say should still go to them.


I’m still learning more about what it takes to make a great agile team, I’m pretty sure there will never be one perfect formula, that’s what makes my job so fun. That said, I can’t see the desirable traits I’ve listed losing importance anytime soon.

I’d love to hear what you think…do you know of any more?

The Measure of a good Scrum Master.

As a contract SM I think its important to be able to demonstrate value-add on a regular, if not daily basis. Problem is, because we don’t produce anything tangible, this can be rather hard.

I’ve challenged people to give me metrics in a few of my contracts and most of the time velocity is cited as the only metric. I believe this to be far too simplistic and completely dependant on the teams willingness to change, aptitude for learning and passion to become self organising, this varies per team. Even with the best Scrum Master in the world velocity may take some time to get on the upturn if the team isn’t committed to change yet.

So, what else do we have?

For me, there are many metrics and their importance varies dependant on the situation/team/company.

Why do they vary?

They vary because those who you are demonstrating value to may favour one more highly than the other. Also different problems are prevalent in different organisations, so you’ll want to see that you’re addressing the big issues and measure against those. Thats why I suggest interviewing or holding a mini retrospective with each aspect of the team end to end, using the 5 why’s to make sure you’re addressing the cause and not the symptom.

What metrics have I come across so far?

Team questionnaires- can measure things like morale to see if there is an upward/downward or stable trend. After all, if the team is unhappy, they’re very unlikely to be motivated to do their best work. This gives feedback after each sprint.

PO questionnaires- Like team morale questionnaires, you can ask them to rate things like visibility, predictability and value for money.

Predictability of releases/ regularity of releases- in a fully empowered agile team, releases should be little and often and the PO team should always know when the next is coming.

Concept to cash time- This is a great end to end measure, although, like velocity it can take some time to improve and can do so in massive jumps or small steady increments. That said, there’s only one thing the big boss’ll care about…and thats value to users.

Then of course, good ol’velocity…but you know this one right.

Ok, we measure those things, what next?

Publicise the results openly. Do not be afraid if they’re not going in the right direction, they’re early warning signals.

Discuss with those same people you interviewed at the start to gather your problem statement/acceptance criteria. You have to make sure you’re still measuring yourself against the correct things and the world hasn’t changed so dramatically around you that those things no longer make sense.

To wrap up…

There are so many things that can be measured, as long as you’re thinking about it and doing it in some form you’re onto a winner.

It’s very simple from high level, know your audience (who’s measuring), understand the problem (why are they measuring), create and agree metrics to measure performance against these problems, revisit…often.

Now to practice…easy 😉

IMAG0705

Scrum Master- a contract only job??

When recruiters ask if I’ll ever go permy somewhere, I always give the same answer… “Not as a Scrum Master, no”.

I’ll generally follow up with the why, not to seem rude.

Why?

Well, I believe that to be a good Scrum Master you need to do the following:

  1. Grow the team to be self organising
  2. Grow the team to be self sufficient
  3. Teach them how to continuously inspect, adapt and improve.

I can’t see how this can be done if you’re always maintaining an opening for your role, as to need your role means the team are dependant on you, not self organising or self sufficient. In my mind, you should always be looking to see how the team can share on the responsibility of tasks.

  • Blocked??…be motivated to remove your own blocker, its fastest.
  • Need to plan/retrospect??…there should be a reoccurring meeting and the team know the rest.
  • Backlog needs managing??…why should your product ownership team not be motivated to do this without prompting, this ensures they get the product they want when they want.

You should be aiming towards a point where all you need to do is present the team with the problem/project and they follow their own simple processes and self organise around it. I’m not saying this happens overnight and I’ve had a few long contracts in places where the teams have struggled with self organisation at first, they’ve all gotten there in the end though…with the right motivators (thats sounded sinister, it isn’t!).

My other reason…

In a contract role, in most places you’re somewhat removed from hierarchy. There are still only a few places that operate the fully flat structure that Agile recommends, and as a servant leader, we’re hard to place into a hierarchy. Hierarchies come with expectations of behaviour at each level which in turn create behaviours, conscious and subconscious, in reaction to this.

Put a servant leader in a position above the team and the team may lose the willingness to be self organising or take ownership over the outcome, why would they when they have a “boss” to tell them what to do and to take the wrap? They’re paid for it after all?

Put a servant leader in a position below the team (technical and product) and they may view this person as “having no authority to tell them what to do” when they come to facilitate the standup/ retrospectives/ grooming or planning meetings. They need a voice.

Alongside is best, but in most hierarchies I’ve seen, the product ownership team have authority over the technical team, so in a hierarchy, being on the same level as the team may not help a servant leader.

Flat or undefined is best. Ambiguity wins in this case.

Why am I blogging??

Why am I blogging, well..

  1. I’d like to keep this as a thought record, I thought might be worth sharing too.
  2. Initiate conversation with smart people who may/may not agree…because I enjoy conversation on the topics I’m blogging about.
  3. I think it might be interesting to see how my thoughts develop on topics the more experience I gain.

There won’t be any regularity to my blogs, I’ll post as and when I have a moment of mindfulness. 🙂