Posts from software product manager and project manager

Menu

Tag Archives for review

I participated Scandinavian Agile Conference 2012. Conference was organized well and I think many people enjoyed that day. I participated to Human Touch track but also had last lesson from Marc McNeill. Here are main points which I remember from sessions. Note: This is how I understood things and which I felt were important. There was introduced other things as well but I focused on the things which I write here.

This was the first lecture of the day and somehow it was a bit difficult to follow (at least for me). Here are some notes.

As software development is usually complex thing to do it is not wise to have a lot of rules to make the process effective. You should only give a couple of basic constraints which team should follow and the rest they can figure out by themselves. This was illustrated with complex traffic places where you can either have many traffic lights or just some traffic circles with simple rules. It’s usually faster to use basic rules in the traffic circles than wait all needed traffic lights turning to green.

It makes sense. Similar way for example coding standards can be used in company level. Standards guides teams with simple rules. Otherwise team can decide what kind of implementation it will create for the product (naturally there is other constraints as well but I want to keep it simple with this example).

Other point was how to find next stories to be implemented. Dave proposed approach of diary. Users don’t need to write exact problems what they have but instead weekly they keep a diary of their work. This way it’s easier to analyze what kind of problems users have. And then software company can notice that they could do (or already have) solution to challenges that users currently have. It’s like mixing new customer needs to new technology.

Other good example was how to find new business things. He told example where ordinary people were asked to tell what kind of things they would like to have in their garden. Those requirements were added to list. Then technology companies were asked to write a list what kind of things they have. Then there was analyzed those just created two lists and finally matched possible technical solutions against gardeners visions . This produced couple potential new usage of technologies to new things in garden.

This was quite much from retrospectives. One point which I found interesting was that usually you should use more time to plan new improvements instead trying different things quickly. Planning takes time as there is needed to listen many people opinions (because usually it is complex context and no one alone can know best solution) and you need to compare different options. Then after you have done research then you have to implement improvement quickly. After that there comes checking how improvement was and then learning about it. This is a common practice and introduced also in Toytota approach. It’s also interesting to think how “fail fast” ideology is related to this.

Mark was discussing about creating environment where users and developers can work together. This is the way how developers can really understand what users need. They can stand in customer shoes and emphasize their problem. It will not require more than for example 1 day from month. It’s very valuable. Also prototypes should be used as much as it can be to minimize cost of failures.

When discussing with some colleagues we somehow founded that in other tracks there were also discussed a lot about importance to work near the customer. I’m not sure if it was theme of the day but at least that was main message which we got.