Thinking Digital 2017

I’m writing this from the comfort of my train as I hurtle south through the English countryside following a memorable and very enjoyable conference, back in my home town of Newcastle Upon Tyne. I’m ashamed to say this was my first attendance at an event that is now celebrating it’s 10th anniversary. I will be sure to return next year!

tdc17The content was varied, thought-provoking, informative, very well presented and frequently amusing and inspiring. Think of it as a mini WIRED or TED event and indeed the organiser, Herb, does also run TEDx Newcastle.

The Startup Competition – write-up to follow, honest…

The Main Event (full schedule)

Session 1

Mark Mullen (Atom Bank)

Laetitia Cailleteau (Accenture) – applications for AI

Dan Biddle (Twitter/BBC)

Darren Jobling (ZeroLight) – has branched out from gaming to visualisation for Audi.

Session 2

Sophie Bostock (health)

Dr Anita Sengupta (rocket scientist)

Di Mainstone (art/music)

Tom Scott (future)

Session 3

John Kershaw (beards)

Adrian Westaway (design) – talk about tech not being the end game, the importance of UX etc

Simon Singh (maths)

Session 4

Richard Wiseman (magic and design)

Dr Justin Sanchez (darpa, brains/neural)

Imogen Heap (music)

Jeremy Silver

Chris Turner (rap)

 

Applications for Finance?

Given that my employer kindly agreed to fund this trip I should make some observations in the context of Financial Services. We heard from Atom Bank. With direct applications for my particular area of banking (Equity Research), we saw a pitch from City Falcon, an interesting disruptor in the FinTech space looking to simplify access to market data (or commentary) and present using intuitive interfaces, such as Amazon Alexa.

More details to follow, I promise…

 

#TDC17 @ThinkingDigital

16th & 17th May

Advertisements

How the burndown burned me out

“Scrum is leading us into temptation to work until we burn out.”

Michael Hofmann @ SGBER (2014)

confusion

I’m a ScrumMaster in a reasonably successful feature team at a large European bank, in London.

First of all don’t get me wrong – the title is deliberately dramatic and attention grabbing, but I am a firm advocate of Scrum and agile methodologies in general. I’ve worked on waterfall projects and is was not a pleasant experience – I have no desire to return to those dark days. I do however, believe that Scrum is far from perfect and offers its own unique challenges.

My problem is stress and the constant pressure caused by maintaining and sustaining a certain velocity (i.e. high pace), while at the same time ensuring that quality doesn’t suffer. I want the team to actually enjoy themselves at work and I often find the frantic pace just doesn’t allow this. Now, I know what you’re thinking – a teams velocity is supposed to be sustainable; that is clearly stated in the manifesto.

“Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.”

Agile Manifesto – Principles

The competing factor though is continuous improvement – this philosophy is instilled in all good agile teams and so there is a natural tendency to want to see your velocity increase.

I have another problem with velocity and it’s the implication or assumption that it is carefully measured.  If you measure something you are creating targets, whether you mean to or not. Should it be measured at all? I stopped measuring velocity a long time ago and we abandoned the burndown altogether; I haven’t detected any particular problems and morale has improved as a result. Anecdotally, I’ve seen no reduction in velocity or capacity.

Then you have the problem of how it is measured and reported (and then ultimately compared and used as a stick to beat a team with). Equally, if you don’t measure velocity, you have the problem that stakeholders and product owners will calculate it themselves, ambiguously and without assigning an actual measure or real value, based purely on their perception of your output. This is why if you run a successful Scrum team it often feels like you are digging your own grave – the joy of having a successful sprint and delivering against your plan is swiftly replaced by the overwhelming dread that you’ve got to do it all over again next week (and improve on it). You are left with the demoralising effect of feeling like you’ve somehow gotten worse or that you are going backwards. Either way, it’s stressful and not much fun.

There is a lot of supporting evidence in favour of an agile approach vs waterfall, with respect to the teams mental health – but this is largely based on the assumption that stress is reduced and far less than that found during a typical waterfall crunch period. Is it really? Does slightly reducing the stress levels but spreading them out so that it occurs in each sprint really improve things? At least after a couple of weeks of waterfall crunch you had the chance to rest and recuperate; with Scrum there is no end in sight.

I’ve also found that generally a Scrum team has a far more rushed attitude to delivery. This is a common criticism of Scrum and I’m not going to cover the issue in any detail here. You could call this ‘focus’ or the result of increased energy, motivation or enthusiasm, but the result isn’t healthy, for the product itself or the team members. Again, this is often the result of the drive towards continuous improvement. What if some things just take time and careful consideration?

“Move slow and craft things.”
Kevin Fox

Now, I realise that there isn’t anything in the agile manifesto about increasing velocity or rushing through things, but the reality is that the principles and the attitude that is instilled into the team does affect a number of people in this way. Certain personality types seem less affected than others and some people are more willing to miss their estimates and instead just do the job properly, but that is rare in my experience. It’s not just the burndown; it’s Scrum in general – people can find the process and the methodologies addictive and the never ending backlog of work just doesn’t fit well with certain personalities.

Closing a JIRA or moving a sticky note to a ‘done’ column is an intrinsically rewarding and motivating process. I don’t think that is an accident; I think there are elements of gamification within Scrum by design. Is this the right approach – we know that this encourages people to call a piece of work complete when perhaps that isn’t quite accurate. If all of your colleagues have moved some tickets or closed some items at your daily standup, there is some pressure on you to do the same, that is human nature. Again, there are many other articles covering the importance of the Definition of Done, or of the effects of peer pressure within an agile team.

I’m not the first person to make the connection between Scrum and exploitation…

“The daily Scrum meeting (stand-up) is another tool designed to maximise exploitation of developers as a capacity constrained resource by keeping them busy and keeping development moving forward.”

Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results.

David J. Anderson

To summarise, I think the agile approach fundamentally changes an individuals approach to work – largely in a positive way, but with some negative connotations for stress and an individuals attitude towards completeness and thoroughness.

What can you do about it?

Have some time off between sprints, perhaps a free day, so you don’t feel that you are jumping straight back into the fire! This would give everyone some time to play, learn, reflect etc. I’ve seen similar implementations where people have tried to introduce Google 20% time outside of the Scrum process, for example.

It is worth investing in a proper model of your system, ideally visualised and well presented. This model can help to articulate the business value of design, infrastructure or architecture work.

A good ScrumMaster, team lead or project manager will spend a lot of their time helping to ease the pressure on team members and insulate the team from frequently changing and increasing demands. It’s a fine balance, you need to be delivering ‘value’, but you also want to allow the team to fail occasionally to facilitate learning through experimentation.

My advice – drop the burndown, stop measuring velocity and appreciate that there is a real limit to team performance and efficiency; the continuous improvement curve can’t be linear!

As always, I’m keen to hear your thoughts and experiences.

Further Reading

How To Not Destroy your Agile Team with Metrics

The importance of a good team

It may seem obvious, but a good team of people is absolutely critical when implementing Scrum. Scrum and the delegated control and decision making that comes with it can be disastrous if you don’t have a team of people that you can trust.

dt100901

Agile is based on this word, trust. You will be told, in all of the literature, that trust is crucial and that you must resist the old school management temptation to dominate and dictate. Can you implement Scrum successfully without this trust – the answer, obviously, is no. What if you find trusting difficult?

There could be good reasons for your scepticism. How do you know whether you have a team that you can trust?

Use an agile maturity model to help understand how capable the team is and how much potential there is for improvement. If you don’t see each and every member of your team maturing to the desired end state (presumably zen/guru) then its probably time for them to find another team. The weakest team member will always hold the rest of the team back and prevent your team as a whole from maturing.

Solution?

Evaluate the team and have them self-evaluate using a formal model.

Run small experiments to limit your exposure and validate or invalidate your fears around trust and specific team members. Frankly, if you place your trust in them and it doesn’t work out, then you know what to do…

Of course there will be legitimate limits of your trust as a leader, but you need to be on that boundary and pushing it all the time. There is nothing wrong with that, as long as you have a plan to address the problem; maybe this month you don’t trust Bob with a release, but you can delegate a few smaller tasks and see how he gets on, then try again next month.

As Einstein famously said, insanity is doing the same thing over and over and expecting different results – if it’s not working, move on and change your team.

Do not, under any circumstances, try to shelter or insulate an individual for the team. The problem is  not limited to that individual, it will be having an effect (visible or otherwise) on the rest of the team. One de-motivated, non-believer can have a huge negative effect on an otherwise high functioning team.

Another problem with IT budgets

Well, it’s that time of year again – budgets and 2016 planning. Great! This process, certainly at my organisation but I’m sure at many others the World over, is met with dread. It can be maddeningly frustrating, stressful and time consuming and is often ultimately unsuccessful.

dt101113

Recent research has shown that people in financially challenging situations often make bad decisions.

“When they were preoccupied by financially challenging scenarios, the poor did significantly worse. When concerns of scarcity captured the mind, the poor had notably reduced fluid intelligence scores and exhibited diminished executive control.”

Can we apply this research to corporate decision making? I think we can – the stress and complexity created by constraints is quite similar to that which you experience when dealing with personal financial difficulties (although obviously far less important). Indeed, the author actually alludes to the fact that you don’t necessarily need to be ‘poor’ to be affected.

“This also appears to be true for people who are not “abjectly” poor, just budget–constrained. When they were preoccupied by their finances they did less well on the cognitive tests, and the effect was substantial.”

So, perhaps there is a lesson here for the corporate budget process? I think we all know that 12 month, short-term, thinking is unhealthy – but is the mere fact that we are budget constrained very damaging in itself?

Of course, until we find a better approach, this is just yet another nail in the coffin for the current budget process…

WIRED UK article ‘Worrying about money can lower your IQ‘.

 

 

Deconstructed Viz – Male vs Female in the UK Houses of Parliament

Houses of Parliament Membership http://dadaviz.com/i/3828

This is a fairly powerful visualisation, but I’ve got a few problems with it…

1. What’s the story?

You kind of already know the answer before you see the results! So there are more male MPs than there are female – that ain’t news! This is a common weakness in many visualisations – it’s not showing you anything new, but rather its a pretty picture of a statement we already know to be true?

2. What’s the purpose of the visualisation?

Do we even need a graphic to get across this particular message? Is it adding any real value – we’ve already made the very bold statement in the title of the visualisation – “More male MPs were elected in 2010 than the total number of female MPs ever”. That clear statement is arguably enough on its own – I’m not sure the graphic is doing anything to drive that argument home?

3. Make it a fair argument!

It’s a leading question and that’s what I really don’t like. The author had a clear agenda – to highlight discrimination against women. Don’t take sides and try to let the user explore the data and draw their own conclusions.

Visualisations can and should be powerful – they should prompt a debate and discussion, but they should be based on a level playing field for that debate, with no obvious bias.

4. More questions than answers?

What about the context? The first thing I think when I see this graphic is ‘ok, but how many women actually stood for election?’.

We are implying that people aren’t voting for women, but we aren’t backing that up with evidence. We aren’t telling the whole story and we have to be very careful when we do that.

This is only part of the picture. Try to paint as complete a picture as you possibly can. That’s not always possible, but try to at least be honest about the gaps in your data.

Don’t leave them wanting more, or more confused than they were to begin with.

Scrum Maturity Model

This is a model for understanding and exploring Scrum team maturity. I created this model during a workshop ran by Olaf Lewitz & Krishan Mathis at the annual Scrum Global Gathering in Berlin.

The first diagram shows the circular states that represent the different levels of team maturity, with some examples of what demonstrates that level of maturity.

ScrumTeamMaturity

The second diagram highlights the fact that the team can only ever be as good as it’s constituent parts. Or in fact, as good as it’s lowest common denominator! In other words, if you have one particularly weak team member, it is going to hold the whole team back. This reinforces why the circular maturity model is so important – any change to the team can have dramatic effects on the overall team maturity.

LowestCommonDenominator

The model isn’t scientific and doesn’t go into a lot of detail. It won’t tell you how to measure maturity or what you need to do to change it. It serves a single purpose; encouraging you to think about the maturity of your team. It will hopefully help you understand what you need to change and how fragile a team’s maturity can be.

This still needs a lot of work, I realise that. I’m deliberately publishing it quickly and soon after the conference in order to try and get a bit of feedback before evolving it further.

What have I changed from the original Scrum Master Maturity model that inspired this proposal?

  • Crucially, it’s a circular model. It’s not a timeline. This represents the fact that the team never stands still. The team always changes. New people will join with different levels of experience and new ideas and, of course, people will leave. It is important to realise that you are constantly moving around this circle as your team evolves. There is no start and end state.
  • I’ve extended the model to incorporate the team as well as the Scrum Master and also show the relationships between the two.
  • I’ve simplified some of the text and made it a bit less ‘wordy’!

You can see the original model that inspired this work below. Full credit to the original author of that model, Ángel Medinilla.

ScrumMaturityModel

Deutsche Borse – 2014

A slightly disappointing Deutsche Borse competition this year. I personally found 3 of the 4 displays a bit ordinary and pretty uninspiring. This might be a bit controversial and I’m definitely no art critic, but the work on offer from Lorna Simpson felt like a collection of 1950’s selfies!

There was however a very clear and deserved winner in Richard Mosse; his Enclave series on the conflict in Eastern Democratic Republic of Congo is really unique and pretty powerful.

Mosse used a large format camera and discontinued infrared colour film formerly deployed by the military to identify camouflaged targets. Green foliage is shown in vivid shades of pink and the resultant effect is very dramatic.

Richard Mosse 4

richard-mosse-nowhere-to-run-2012-web

Richard Mosse 3

Richard Mosse 2

What an amazing piece of work – not often you see a completely different take on conflict photography…

PS If you are visiting I’d highly recommend the John Deakin exhibition instead (or as well), which includes a few very nice portraits taken on the streets of Soho.