Archive for the ‘Techniques’ Category
Posted by James King on August 18, 2010
Today I ran a workshop on workshops and predictably one of the things we did was brainstorming.
But one of the participants was a little bit bored with putting post-it notes on the wall, so we replaced our standard brainstorming with “what would someone else do”".
This approach can work really well in either a coaching session or a workshop.
The idea is that if we already knew what to do about something there would be no issue and no need for coaching or a workshop. So rather than asking “what can we do” and being stuck with our usual thinking we ask “what would someone else do”.
For example, I might ask you to answer the following questions to shift your thinking:
- What would you never do that someone else might try?
- What would your parents do?
- What would a leprechaun try?
- If we just found out out competitor had solved that problem, what would they have done?
- What would your evil twin do?
- How would Buffy the Vampire Slayer deal with that? What about Spike?
- What would never work?
- If you were back at school, what would your friends have told you to do?
- What would you tell someone to do?
- What would Homer Simpson never think to do?
The aim is actually to ask more than 7 odd ways of solving the problem that we would not normally think of doing. The reason for trying more than 7 is that someone told me that the first few approaches we think of are often repeats of the same ones … plus 7 is a lucky number.
But in our workshop one of the crew was a more inventive. This is what he did:
- Break people into teams of two;
- Allocate a fictional (or famous) person to each group;
- Give people to brainstorm some suggestions their fictional person might come up with;
- Share the ideas with the group; and
- Ask people to state how they could combine different combinations of the suggestions to come up with something that is actually sensible.
It worked really well in the group. The only improvement I thought might work well for next time was to consider using some deliberately different characters to find some extreme suggestions, for example:
- One team be Santa Clause and the other Scrooge; or
- One team be Britney Spears and the other my great grandma.
Try one of these approaches next time you are stuck for ideas and let me know if it works.
Posted in Decisions, Techniques | Leave a Comment »
Posted by James King on August 18, 2010
I am running a workshop workshop today – a workshop on workshops.
Actually I am running a training course for some experienced facilitators and the course is about how to run workshops better.
So I have been reviewing conflict management techniques, ways of engaging un-engaged participants and issue resolution techniques.
Interestingly I have just noticed (yet again) that some of the workshop techniques (affinity diagrams and speed dating for example) work for both mitigating “strong personalities” and influencing the “passengers” to stop sitting back and start contributing.
Then I decided to throw in the question compass some abstract/concrete thinking and some fun things like options generators.
But now I have decided to lead with one of the least sensible seeming yet most useful techniques – the grammatically nonsensical question “how do you mean”.
Another facilitator taught me this one – it does not actually make sense so there is no right answer … which gets people to blurt out any answer .. which helps then explore what they really want to say. I am not quite sure why but it frequently seems to work.
So – 10 experienced facilitators and the first and best tip I will give them is just to ask a dumb sounding question.
I will see how it goes.
Posted in Arguing | 2 Comments »
Posted by James King on July 31, 2010
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.
Posted in Consulting, Measurement, Reflection, Techniques | Leave a Comment »
Posted by James King on July 31, 2010
We often say that we are focused on quality and yet only report on time and money when reviewing our projects.
Or we report on “the number of defects” but not on the actual “quality”, not “the ability to maintain this system when we go live”.
I think this is because people often thing that measuring quality and maintainability is hard. But here is an easy (if not fully robust) approach to measuring quality.
Each retrospective (or team meeting or implementation planning meeting) we can ask the team to report on their own perception of the quality of the work they are producing. But rather than asking for an objective measure of quality, we ask how they view their work compared to last time (the last iteration or a typical project done by the team).
To do this we ask a question and score the answer as ”0″ if the quality (or other factor) is the same as usual. If it is better (or a lot better) then the answer is +1 (or +2). On the other hand if it is not as good as usual then the answer is -1, or -2 if it is a lot worse than usual.
For example we could have the following survey for the team to complete prior to the retrospective:
| When we deploy this into production … |
-2 |
-1 |
0 |
+1 |
+2 |
| The quality of what we produced will be … |
|
|
|
|
|
| I will be proud of what we produced |
|
|
|
|
|
| Production support’s feedback will be … |
|
|
|
|
|
These ratings are not designed for a project office to use in assessing projects against each other but rather for the project team themselves to use in deciding how they are travelling and how to tune their own performance.
Posted in Implementation, Measurement, Techniques | Leave a Comment »
Posted by James King on July 31, 2010
I have been in several conversations recently about how we take refactoring and technical debt into account when estimating work on IT projects.
For those not up with the jargon – refactoring involves improving or simplifying your code without changing the functionality. This means that the code can run faster and more reliably, be better maintained etc.
Technical debt is the concept that if I take short cuts to get a project into production then I am borrowing from the future – in other words someone in the future will need to do more work to make up for the fact I am doing less now.
Unfortunately though, even if I do all the work that needs to be done now, the system I build will become less fit for purpose over time if it is not constantly maintained and refactored which means that all systems have some level of technical debt in them.
In fact when you talk to some teams they will go to a lot of trouble to avoid making changes to particular systems or system components because they are “delicate” or more accurately unstable and scary to work with.
One of my favourite tools for taking this into account when I am estimating the cost of adding or changing features in a system is the a “heat map”.
Essentially a heat map is a map that shows where to expect trouble in a system and where to expect smooth sailing.
To create a heat map, simply take any model of the system and shade or colour different areas of the model to indicate the ease or complexity of working on different each area. Things that can be taken into account include whether there are automated tests in place, areas of spaghetti code, areas that involve complex integration code, areas the developers know well or anything else the team feels is relevant to the complexity (and therefore estimated effort) involved in working on different areas of the system.
The team adjust estimates involving different areas of the system in line with the “heat” of the particular area.
Heat map
Once the team has created the heat map they use it to update their estimates for changes that involve different components of the system.
I the team are using relative estimating techniques like planning poker they they will simply discuss which areas of the system are impacted by the change and then take this into consideration when voting on their estimates.
If the team are estimating by time, then they might agree, for example, that any work involving the lightly shaded “a bit scary” components will take 20% longer and work involving the “bad lands” will take 200% longer.
This is a simple way to take a lot of complexity into account when doing your estimates without having to go to a great deal of effort.
Posted in Consulting, Decisions, Implementation | Leave a Comment »
Posted by James King on July 24, 2010
When auditing a project (or taking over a project or even taking on a senior role in a team) I like to go and talk to everyone in the team.
When I do, I generally ask them the same questions to get a better feel for what is going on.
I really liked a set of questions I picked up from a book called “The First 90 Days”, so I use a modified set of them:
What is your role?
- What does that mean?
- How would you explain it to my mother?
- How would others explain what you do?
How confident are you the project will meet it’s objectives?
- What are the objectives? Really?
- How clear are you on the objectives?
- What do management think the project is doing?
- What do others think?
- If it fails, where will it probably have gone wrong?
What is the biggest issue facing the project?
- What would happen if we could get rid of that problem?
- What would need to change to get rid of it?
- How could we deal with that problem?
- How is it impacting us/the project? How does it impact you?
- How are we currently dealing with it?
- Why is it still there? What is stopping us deal with it?
- What should we do about it now?
What is the biggest unexploited opportunity in the team?
- What would have to change for us to exploit it?
- What would happen if we did?
What would you do if you were me?
Most projects are really really complicated. But most people know how well it is going or how scary it is if they have time to think about it. So I find you get a pretty good overall understanding if you just ask everybody these questions.
Posted in Investigation, Reflection, Risk | Leave a Comment »
Posted by James King on July 24, 2010
I was talking to a colleague recently and promised to share some of the questions I ask when auditing a project (or taking one over).
My first question is generally “what is the project about?” But that generally leads to a vague answer. So I use my “question compass”:
My question compass
These are the questions I use to get a basic orientation when analyzing just about anything. By way of explanation though, I don’t always use the exact wording shown.
When asking “what do you mean” I use a technique that sounds really simple and is surprisingly effective – the “nouns and verbs” technique.
I listen for a noun in a sentence and then ask “what do you mean by ‘noun’?”. When I get a response I ask about one of the verbs in the response “How do people currently ‘verb’?” or “How do you envision people will ‘verb’”.
I keep doing this for a little while even if I think I know what people mean because it is amazing how often it clarifies my understanding. Then I pick one of the things the person said and ask “why are we doing this project?”.
I do use the famous 5-whys technique to probe more deeply (ie ask why several times) but I also add the question “why else?”.
I was once told that we do things for two reasons – the right reason (the one we tell people) and the real reason. I think it is a quote from someone famous. But it certainly clarifies my thinking when I ask this question.
My next question is “Is that true?” and I ask this one in a number of ways:
- What would the team say the purpose is if I asked them?
- Do all the steering committee share the same understanding?
- How do you know that is true? How do others know?
- How would you know if that was not the case? (my favourite question).
Almost there – but I still have one last question – “So what?”. Like asking if something is true, asking so what can seem a bit blunt. So I ask it in a couple of different ways:
- What impact is that having?
- What would happen if we didn’t do it?
- What would the impact be over the long term if we don’t do it?
- What will happen if we do it? What else will happen? What won’t happen?
- What are you hoping won’t happen if we do that?
- What will the team/customer say when it happens?
After these questions I generally at least have some idea of what is going on – which is often the best place to start.
Posted in Investigation, Reflection, Risk | Leave a Comment »
Posted by James King on April 5, 2010
We set up a stand at the recent Software Development Conference to run the Agile Release Planning Game I designed.
It seemed to go down really well, so I have decided to make the game available publicly if anyone is interested in using it.
In the game, participants are a group of scientists and engineers who are stuck on Mars after a “less than successful” landing. They are on a mission to make scientific discoveries but must now rebuild a basic infrastructure for survival before returning to their original mission.
Participants then create a strategy based on rebuilding their ship, building a base and/or returning to their basic goal of research. In doing so they must make trade-offs between quality and velocity.
The game introduces concepts such as release planning, iteration planning, velocity, release planning trade-offs, building by feature and adaptive planning.
The game is designed to be led by a facilitator, but can be run without one. The release planning game takes around half an hour to play and can be replayed multiple times to explore different concepts in more detail or to improve the outcome based on lessons learned in the first attempt.
Different options allow the game to be played as a very simple introduction to the concepts of release planning or a more complex game involving more realistic trade-offs and decision making under conditions of uncertainty and pressure.
In addition, there is an extension included in the game that focuses on planning within the iteration (or sprint) rather than across the wider release.
Let me know if you are interested in learning more, or even trying the game for yourself.
Posted in Capability growth, Decisions, Events, Games, Products, Risk | 6 Comments »
Posted by James King on April 4, 2010
I believe that a lot of decision making is negatively impacted by unclear delegation.
The result is that both the delegator and delegatee (if such words existed) want the right outcome and behave intelligently – but act on different information or assumptions.
So it should help when delegating decisions to a group, if you am really clear on what decision you want made :
- Not just the item that is up for discussion but also whether people are helping you decide what the solution should be or just how to implement the solution that has already be decided; and
- Not just whether you want to talk about a decision but what outcome you want to achieve in the meeting.
For example – pick one of the following for the decision in question:
- I have made a decision and I want to explain it to you, as well as get your feedback;
- I am going to ask for your ideas and then make a decision;
- We are going to decide this together, but I will decide if we cannot reach agreement;
- We will decide this together and we need to all agree before we move forward;
- Let me know what you want to do as a team and I will back you; or
- Everyone can decide their own course of action separately after we have discussed the decision.
Similarly – set one of the following as an expectation before you ask the group to make a decision – At the end of this discussion:
- I want everyone on board with the decision and acting on it;
- I want the decision made, but we can come back later and talk about how to implement it; or
- I want everyone to go away and think about it, so we can come back and make an informed decision later.
It often surprises me how a little clarification leads to a realisation that we were much less clear as a group than we thought we were … which means we were probably wasting our energy working in different directions.
Posted in Decisions, Implementation | Leave a Comment »
Posted by James King on March 20, 2010
According to a recent article by Mckinsey, only 28% of the managers they surveyed thought that their organisations generally made good decisions.
That’s a pretty scary statistic if one of the most important things we want management teams to do is to make good decisions.
The article explains some of the common causes of bias in decision and positions behavioural economics as a way of understanding and countering our natural biases.
It amazes me how often I have people talking in training courses talking about how to cope with bad decisions and how cynical they are about the decisions made “higher up the chain”.
So I have made my own decision – I will start adding some information here that helps with making better decisions.
I will probably add some more links as Mckinsey publish more of their articles on behavioural economics. This will help us understand the biases we have and their impact. Similarly I will publish some more tips on arguing to help with identifying flawed and biases arguements.
But my own theory is that many people start with reasonable ideas and would make good decisions … except that they are given the wrong information to use in making the decision. So I will also start publishing some of my own tips on how to delegate or be delegated to.
I know this sounds simple, but I continue to observe a lot of intelligent, well meaning people getting into a mess because they either don’t challenge each others’ ideas, the a scared of having their ideas challenged or they are not sure what they just got asked to do.
Posted in Decisions, Investigation, Observations | Leave a Comment »
