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.
Continue reading “Do you get value from your retrospective?”
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.
Continue reading “I thought training was easy – what is going on here?”
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”.
Continue reading “The dark art of office politics for IT leaders (part one – why is it stressful?)”
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”.
Continue reading “Focusing questions and project charters are great, but where do you start?”
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.
Continue reading “Famous BAs in history: Mark Twain on interviews”
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?
Continue reading “Would you hire a project manager to plant a tree?”
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.
Continue reading “It may be logical, but does it make sense?”
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 … Continue reading Talking about retrospectives on another blog
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 … Continue reading Unusual predictors of team success
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 … Continue reading Ask the team about technical debt – the creeping doom graph