Posted by James King on April 16, 2011
I am running an “advanced BA course” next week and as part of the course we will be exploring the concept of strategy from a business analysts point of view.
One of the trainers I work with (Shane) recommended we provide the participants with a book called “Stand Back and Deliver” by Pollyanna Pixton, Niel Nickolaisen, Todd Little and Kent McDonald.
Posted in Decisions, Idea management, Investigation, Observations | Leave a Comment »
Posted by James King on February 5, 2011
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?
Posted in Decisions, Idea management, Leading change, Reflection | Tagged: change management, ideas | Leave a Comment »
Posted by James King on September 8, 2010
This blog is normally a collection of my own thoughts rather than a source for links to other people’s thinking.
But it seems a lot of companies are now deliberately asking others to do their thinking for them, so it seems fair enough for me to do the same.
Here is an interesting link to an article on crowdsourcing.
http://knowledge.asb.unsw.edu.au/article.cfm?articleId=1202
So my question is - if you can even outsource your thinking, what does it mean to be an organisation in the new world order?
Posted in Decisions, Investigation, Observations | 1 Comment »
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:
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:
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:
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 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 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 :
For example – pick one of the following for the decision in question:
Similarly – set one of the following as an expectation before you ask the group to make a decision – At the end of this discussion:
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 »
