Saturday, March 12, 2011
Monday, April 26, 2010
Thursday, March 18, 2010
An interesting problem for prioritizing an agile project is the relationship between what is most important and what is needed. This might seem as a paradoxical problem as the thing which is needed is the one which is important. But it is not, and in this post I will try to note down how this can be.
A crude summary of the concept of prioritization might say it is an activity which prevents you from working on the wrong thing. Commonly a set of features which makes the product reach a critical use case. This activity also takes a look at these features and breaks them down into further prioritization to make the product tighter. Then you start building it.
So far so good, to describe why this is not quite as simple as just figuring out the priorities I will fall back on my usual comparison with music production. When you are about to create a piece of music you will have references, either explicit ones that you talk about with the production team or implicit ones that you are silent about or even innovations. These references help you prioritize. This is practically done by something called music analysis and there are some models for this. The ones I use have a mix of formal and informal properties and I won’t dig into these more than describing the simplest level.
Imagine that you listen to a song, now think about which thing in this song is the loudest. *waits a little* Ok, you found an important instrument, maybe a snare drum, a base or something else. Then think about an instrument that you hear quite often. *waits a little more* Ok, you found another important instrument.
In the world of music production this analysis keeps going on for quite a long time, it keeps on going on during the production and it is also done on the finished song. You might start with the hi-hat which is relatively quiet, then a cymbal appears, then a sidestick, a kick, a ride, a cymbal fill and a snare drum. That’s a reasonable set of instruments used to bring in the drums. And you will use the same hi-hat at a few different intensity levels a lot of times before you are done.
The variation of experienced intensity or even volume is sometimes described as dynamics. A good song will have a lot of almost quiet and very subtle sounds going on which gives ambience, harmony and feeling to the whole song. Without these your music is crippled. Imagine making a song with only the loudest and most intense instruments. Some musical genres almost do this, electronic dance arrangements come to mind but these also contain subtleties which are harder to put your finger on.
Now imagine that you have very little experience with music but the company you work for has decided that it is strategically important that you manage the production of the music played in the marketing campaigns for the coming five year. It has to be about five minutes long and sound a bit like a disco song made in the 70’s, and you have a budget which affords you two people working for about a month.
This is a relatively easy mission for an experienced music producer, but it’s quite challenging to the beginner. When you meet your two musicians that will make the music for you during the coming month and you describe your mission they will start asking unpleasant questions. Maybe, so which of the 70’s disco songs should we take our influences from? Since there are vocals in 70’s disco we’ll have to figure out who will sing and what that will cost. How good of a singer do we really need? Is it ok if the singer is a bit flat? Or maybe better to remove the singer and then aim at a more instrumental arrangement? Oh, since you can’t answer these questions for us let’s just listen to this reference and prioritize the parts you think are the most important, then we’ll put them in the song one after another until we run out of money.
So now we have figured out that the base, the kick drum, the organ and the vocals are the four highest priorities. Which one should we finish first? This is a kind of question that will kill you if it happens in the music industry. In this particular example case it is a symptom of a conflict which is based in lack of understanding between the customer and the production team. The two musicians know that they can’t reach the goal of the client on budget and starts to force the client to reduce the scope. To successfully navigate out from this problem the client has to budge on something which was defined in the strategy.
If this happens in the music industry you got a decent solution, just buy the song you want from whoever made the original in the 70’s. In the world of interactive software you don’t have this luxury, your options are limited and all of them are unpleasant. The statistical solution is to start answering the questions and actually building the prioritized things until the money is spent. The market will treat your product as it deserves.
Interactive software, just as music, is riddled with challenges of a dynamic nature. I’ll pick the easy part and talk about feedback here. An example of very intense type of feedback in interactive software is a shaky camera movie. The user clicks a button and then a movie starts playing where the camera shakes and there are loud sounds. A less intense type of feedback is a slight highlight on the button which lights up when the player places the mouse cursor above it.
Imagine that you need to prioritize these two against each other. Which is more needed, which is more important? The answer to this question will depend on who you ask. From my perspective it really depends on the dynamics of the overall production and your concept but the general notion is that increased dynamic range is better than a focused one.
The other day I came upon a tactical production technique which helps with this problem but it appears to have been invented for another purpose, which was to help the team finish within budgetary restrictions. The tactical solution is to bring in items from the whole spectrum of priorities to each product iteration, aka sprint. This has to be done with some consciousness of course, pick suitable low priority items to go with the high priority ones.
This way your metaphorical “music” will end up having Drums, rather than a Snare and a hi-hat. But who is the drummer? ... that's another topic.
Tuesday, February 16, 2010
Monday, February 15, 2010
Wednesday, February 10, 2010
There has been a lot of almost mainstream media whining about how projects fail despite using an agile development methodology. Lots of blog posts about how agile cause trouble and how scrum fails in companies.
This post aims to start a journey which looks at my perspective of this trend. The journey begins with looking at the businesses which invest in projects and we’ll begin with separating these into two major factions.
Faction 1: Profitable business.
The profitable business has found a way to reproduce a profitable sale. Steve Blank uses the phrase “repeatable sales model”. My interpretation of this is that there is a potential market value which is reliably converted into money through the business activities. The repeatability causes a reliable equation to play out where you have a high chance of staying on top of positive revenue through conducting very low risk maneuvers until the equation changes when you have the option to adjust to maintain your profits.
Faction 2: Not yet profitable business
The not yet profitable business has bigger costs than earnings. This is quite simple and includes everything which is not yet profitable. In many cases you can see a profitable business include portions of this in the profitable equation, for example by making design improvements or product line extensions. The more common scenario is however attempts at creating a profitable business out of an idea.
Now that we have these two major factions we have a tool for understanding several ways to achieve failures which will make any methodology fail. Since everyone has learned that the typical waterfall project is going to fail by default it’s not that interesting to talk about, but we’ll try and stick to general failures which can be blamed on Agile.
To predict how you will fail you can start with asking yourself: where does the money that finances the project come from? If it is financed by an already profitable business you have a particular case. If it is financed by venture capital you have another and if it is financed by yourself, often as some type of hobby, you have a third. Among these three candidates you have one in particular which spells uncomfortable failure louder than the others. The least loud failure is when you are paying yourself. No one expects success from a hobby. If you are funded by venture capital you are expected to fail about 90% of the time. No one is surprised when investments fail to find a return. The loudest failure is when an already profitable business invests in unprofitable projects. These also seem to be the ones which plays the blame game and tries to blame agile methodologies for their failures.
If you look at an already profitable business from a capitalistic perspective you would think they should not invest in a new “not yet profitable business” and rather send that money to their investors. But for various reasons they generally don’t operate this way but attempts to reproduce profitability in new innovative manners. These become complicated matters.
A profitable business has generally spent a great lot of effort to achieve their profits. As a game designer knows you will be conditioned by expending effort at achieving a goal. So the profitable business has been conditioned by its own success. This conditioning is cultural within that company. This culture tends to have an agenda which prioritizes protecting the profitable business against risks. The practical implementation of this protection is commonly called bureaucracy.
Bureaucracy causes risky product experiments to have such a great cost that they have to be cancelled before they reach the market. It is better to send the investment immediately into the trash bin than to use it to cause a potential harm to an already profitable business. This also has the benefit of creating plenty of work for bureaucrats who thereby can be hired to handle the paperwork.
Eventually this causes polarization within the company where creative forces such as marketing eventually is urged to brute force the bureaucracy to revitalize a now aged brand. They can see their market share slowly being poached by competitors. At this point in time the culture has set really well. The creative forces rally enough of a budget to overcome the cost hurdle set by the bureaucrats and begin their project.
Since times change and you learn that using “traditional methodologies” will cause failure this project must begin to work with an Agile methodology, they usually try to work with scrum.
The root of the problem here is that scrum does not remove the cultural conditioning which practically has become embodied within the bureaucratic parts of the company. There will be plenty of reasons to interpret the new project as a risk to the profitable business and thereby justifying interference.
I don’t know if there is any particular solution to this problem but I do believe that a better understanding of this structure will reduce the costs of failure for any business which is investing in any type of projects. And this is just the beginning.
To propose a practical solution to this I will recommend making investments into new business areas at a healthy distance from currently profitable businesses. Mere proximity might increase the cost of failure.
From my experience with scrum I interpret some of the rules as engineered to refuse interference from bureaucracy. These rules cause a kind of cultural power struggle within an already profitable business when scrum is introduced. Power is usually owned by the bureaucrats and scrum becomes the loser and an embodied target for the blame game.