Do you get value from your retrospective?

A retrospective is a meeting where the team stop working and take a step back to review how well they are working and what they can do to improve.

It is generally done every sprint (or every two weeks if there is no sprinting going on).

The theory is easy – the team share their views on what went well in the last fortnight, what did not go well and what they should keep doing or change as a result.

In practice though, it often turns into a therapy session where people share opinions about the way the world is really bad (or even how the team is awesome) and then they wander off without taking on any action items.

So when your team have lost their mojo and the retros are getting stale maybe it is time to do a retro on the retro.  Similarly, when you first start out as a team, it is often good to define what you might want to get from your retro.

Read More »

I thought training was easy – what is going on here?

I spend a lot of my time training people in areas such as agile project delivery, business and product innovation and business analysis. Allegedly I spend around 50% of my time running training sessions, while I also spend time consulting or providing “transition management” to help an organisation through change.But against all expectation I have been seeing an increase in demand for training over the last year and seem to be spending 90% of my time running training or facilitating workshops. This is great because I am getting a steady and interesting supply of work.  But it also led me to start wondering how the training landscape is shifting.

Read More »

The dark art of office politics for IT leaders (part one – why is it stressful?)

Apparently office politics is a horrible thing that other people do.

But many of the emerging IT leaders I speak to get told they need to be better at “soft skills” and “influencing at a senior level”.  What this often means is get good a politics.

Sadly a lot of office politics seems to involve people playing games to get their own way at the expense of everyone else. This skill can be learned and might seem useful, but it is not what I am going to talk about here.  I am going to talk about “how do the good guys get the right outcomes when people have competing interests or needs and some people seem like knob-heads”.

Read More »

Focusing questions and project charters are great, but where do you start?

I am starting a bunch of small projects at the moment and people are rushing to help define the solutions.  That is great but I am (as always) nervous that we are providing solutions before we really understand what we want to solve.

I like to define the problem (or vision) and then a rough plan to get there and with this in mind I have already published an article suggesting teams use a project charter and possibly a product statement, but where do these come from? 

I usually start right at the beginning, by asking people what they want and then asking what they mean by that – I call that approach a “question compass” because it is useful for finding your direction right at the start of things.

But even with all those links, how do you go from “hi, there my name is James – what would you like today?” through to “Cool, here is an initial project charter – it will allow us to address the enclosed focusing question … that will be $3.2M if you choose to continue, have a nice day”.

Read More »

Famous BAs in history: Mark Twain on interviews

I stumbled on a letter from Mark Twain where he comments on “the interview”:

Inteviews are pure twaddle

Controversially, he claimed that interviews are appalling and should be completely abolished … which would seem to be a strong position for a business analyst to take these days. But then Mark Twain was around at the beginning of last century and we have learned a lot since then. Maybe he just didn’t know any better.

Read More »

Would you hire a project manager to plant a tree?

Many great ideas fall on deaf ears. So organisations bring in project managers to make sure we implement good ideas properly.

Good project managers define and clarify the idea, break the idea into features and then deploy the features into production. But quite often, people just don’t make use of the shiny new features they have been given.

Which is another way of saying that the great idea fell on deaf ears. So some organisations bring in change managers (and trainers and technical writers) to make sure people understand the new idea.

Good change managers make sure that the project is visible to stakeholders, supported by the important stakeholders and that the features being deployed are explained properly to the users. But quite often, the users go back to their old ways after a week, or they complain about the new features and the “stupid” projects that created them.

Which is another way of saying that the great idea fell on deaf ears.  So what goes wrong? Why do so many good ideas fail to get adopted?

Read More »

It may be logical, but does it make sense?

If you have been reading my blog, you have probably heard just about all you want to hear about logic for a while. But I suffer from the opposite problem – Logic-o-philia (not a real word).

But a comment on a recent article reminded me that I can be completely logical, and still not get my message across, if what I am saying is inconsistent with what people already think.

Read More »

Talking about retrospectives on another blog

I was running a course on “facilitating workshops in agile projects” when some of the crew asked what different questions they could ask in retrospectives (instead of just “what worked and what didn’t).

We got talking about the retrospective at the end of a project.  So I published a story of sorts on how to run a retro for 70 people at the end of a project.

At the end of the discussion I promissed to publish some of my comments so I put them together in a short story about running a retrospective.  You can read it hear if you are interested:

Unusual predictors of team success

I was reading Daniel Pink’s book “Drive” and I came across a passage about predicting which teams are likely to be successful.  It describes a guy who counts the number of times he hears people use the word “we” and the number of the times they used the word “they” when referring to their own company.

Apparently the “they” teams are likely to fail and the “we” teams are generally successful.

This made sense to me because when I have always listened when managers use the terms “we”, “you” and “I”. The dodgy managers I have worked for tend to use pronouns like this:

  • “They” or “management” want us to … rather than “I would like to … “;
  • “You” messed up or “team member x messed up”; and
  • “I delivered” something.

I even heard a manager once say “if it was up to me I would do … but you know that management wouldn’t accept that”.  Which was interesting since the person I was talking to was “management”.

On the other hand I have also had good managers and I have noticed that they tend to say:

  • “We” messed up or “We” have a problem;
  • “You” did a good job; and
  • “The team” delivered something.

But I have not previously thought about actually counting the times members of the team say “they” versus “we” so I think I will try that next time I am auditing a project or coaching a team.

A similar thing I have used in the past though was to see if the team (particularly IT teams) refer to their internal customers by name (eg Brian or Mary) or whether they refer to them as “the business”.  It’s interesting how often people refer to “the business” as the customer. 

So my new predictor of success for teams I coach is going to be based on

  1. The number of the times they use the term “we or us” versus “them” and the number of times they refer to stakeholders by name versus using the terms “they”, “management” or “the business”.
  2. The number of times team members use the term “we delivered something” versus “I delivered something”. 
  3. The number of times the team say “we stuffed up” versus “x stuffed up”, “they don’t know what they are doing”, or “that’s not how I think they should have done it”.

What do you think – will there be a strong correlation between the use of different pronouns and team success?

Ask the team about technical debt – the creeping doom graph

I was just talking about the sad state of affairs where some teams know they are making life harder by taking shortcuts or creating workarounds that will slow the team down in the future. In fact, my grandma had some pretty good advice on this:

There never seems to be time to do things properly – but don’t worry, there will be time tomorrow to react to the crisis that resulted from  what you didn’t do properly today.

To avoid this crisis management though, here is a simple way to measure the “technical debt” we are creating today.

Put the following table up on a white board and have each team member put their vote into the appropriate box.  For politically charged projects youmay even have a secret ballot.

When we deploy our changes, the system will be … -2 -1 0 +1 +2
More complex (-) or simpler (+) than before          
Harder (-) or easier (+) to maintain and support          
Harder (-) or easier (+) to enhance or build on next time          

Rather than voting out of 5 however, they are comparing the system before they touched it to the way it will be after they deploy their changes.  Specifically their votes will be as follows

  • 0 means that there is no real change in the measure;
  • + 1 means things are better than before and +2 means a lot better; and
  • – 1 means things are worse or more complicated than before and -2 means even more so.

Now simply average the answers to give a score for each question. 

Hold regular retrospectives or reflection sessions should highlight the ongoing impact of building (or removing) complexity from your life.  But if you want a solid predictor of the impact is will have over time, try using this creeping doom graph (which can also be a virtuous circle graph if you are actively making things better each week).

Creeping doom or virtuous circle of improvement?

Or better yet – give me a call.  I will come and run a couple of workshops for the team to help them see where they are creating un-needed complexity for themselves.  And more importantly I can help them turn the creeping doom graph into a graph of positive improvement – honestly … it can be done.