Lean opportunity
Aug/090
Organizational issues come into discussion every time we talk about agile adoption. Creating a really lean and agile organization has been found very difficult. It has been asked whether that is even possible, not to talk about being sustainable.
In current economic situation savings are the appealing part of lean thinking. The more important part, empowering the ordinary people, is hard to justify. On the contrary, power is restricted to the (upper) management especially when we talk about costs. Layouts are also used to save. Fortunately, the availability of software development jobs is still quite good, which means that volunteered change of ones job is the way to do that.
To many organizations becoming lean means layouts. Some of the them even get rid of unnecessary management layers. But, the big but. Really working together as teams and collaborating parties is far away if we are not talking about Japan where jobs are for life (maybe still). Layouts do bad to morale and motivation and organizations look like frozen. No innovations, no new ideas, just unspoken fear and risk avoidance. Obviously, becoming lean means losing fat, but it also means that you will become more energetic, capable. I am speaking now both the people in individual level and the organizations.
We have learned that economic downturns will end some day. So, the tactic of waiting has become popular. We assume that we can just sleep the bad time away and continue as usual. Unfortunately that is not how the market economy works. Downturns are the time for restructuring the businesses. Some old ways of doing business will be gone forever and new businesses have to be started. You lose your opportunity if you dig to your pothole.
So, instead of just keeping your old cows and killing the calves, you should consider doing just the opposite. Getting money from your cows is of course important especially when you are running out of cash, but old cows do not milk forever. You must have courage to take your changes.
Here I am talking about the opportunities of lean and agile software development. Being effective and capable of utilizing the opportunities is always fashionable. Now we have the theories of lean thinking available. The question is, do you take the opportunity or does your competitor.
8 years of lean software development in Tieturi
Aug/091
Kalle Huhtala’s talk about practical experiences of lean software development is now down-loadable from the site of the Projektipäivät. It is in Finnish, sorry. Unfortunately I could not take part of this day but knowing Kalle, I am sure that it was a good talk.
Tieturi is a training and coaching house but we do some in-house software development to create solutions for eLearning. These projects are quite small and Kalle’s team serves multiple customers at a time. RePa is an excel sheet that is used to manage the tasks and resources. It can be classified as a kanban, because there is only one list of things to do. A dedicated one hour weekly meeting is used to have the coordination discussions in addition what happens ad hoc in the team room.
Experiences of RePa are quite good as you can assume when you hear that we have used that for eight years. Our process has helped us to balance the work in progress and resources that we have. Limiting work to capacity is important because failures or false promises are not an option in small projects that we do.
ELearning is the answer that queue theory gives to trainer’s value stream. You can start learn as soon as you have bought the solution and you can proceed on your own when you have time. There is no need to gather large numbers of students to classes. The solutions are smaller than several days that you typically spend to a class. You can spend just minutes to learn something that is very specific to your actual need. For example, if you want to know how to use links in Wordpress, you could just start a video that teaches to you to do it.
Vacations and creativity
Jul/090
Like most of Finns I have my vacation this month. As typical Europeans we have quite long vacations and sometimes people think that it is a kind of waste that reduces productivity.
It is well admitted that people need sleep to be productive. Overtime and trashing at work is quite typical in our profession. But still we ignore the agile principle of sustainable pace. After months of overtime people are so burned down that it is a miracle if they get any significant output.
The time that has not been allocated to a specific purpose might become the most productive part of all. Vacations are wonderful places for that provided of course that you do not have a tight schedule for your holiday. You may guess that I do not behave like that. Actually I live one day at a time. I have about 50 topics to this blog, several books to read and few home computers to upgrade. Most importantly I have now time for exercise. Weather has been good for walking and for work in the garden. I do not run marathons like some of my colleagues.
I have always combined walking and thinking. New ideas pop up when I walk. That is wonderful time considering them thoroughly.
I have a mini-laptop, Asus EEE 901 with 20GB SSD using Ubuntu 9.04 to be exact. It is an excellent tool for surfing the web and maintaining this new web site. I appreciate its small size, long battery life and connectivity. This is my first really personal computer - it is with me all days long. Now it is possible to take notes and have them with me. It is my extended memory.
I remember the word creativity in the title, so let’s talk about that now. One part of creativity is brainstorming - a wild burst of new ideas. It is only possible if you have free non-allocated time. In a tight schedule you pick the most obvious solutions and hurry on to get things done. During the vacations you have that luxury. I do not mean that you should spend your holidays to thinking work related things but people like me do it anyway not because someone pays for it but because it is fun.
Blogger’s Information Security
Jun/091
Let’s talk a little about my experiences with the first months of this blog. One of the most important reasons to start to use my own domain was to get rid of legacy email-addresses that gather a lot of spam.
Changing my email-address everywhere was not as difficult as it sounds, because most of the incoming mail was from mailing lists that I have subscribed and they had means to change that address. Oddly enough, one of large economic magazines, Talouselämä, has a mailing list which has no way to cancel the subscription or I did not find it.
The amount of spam was actually less than what I had thought - less than spam 10 mails a day. Filters are quite capable of classifying these as spam and the ones that get through are easy to spot visually.
Hardest thing is to find people who send me email only few times a year. That requires a good address book and/or good scanning of your email database. I have registered a lot of software during the last decades and some of them might want to contact me. At least one book store that I used more than 10 years ago, persistently sends their offers to me. These ones are quite close to spam, but there has been a real business relationship.
Starting a blog introduced me to another problem - comment spam. Akismet spam filter is quite effective and in this blog I am afraid that some real comments gets filtered. I am sorry about that. But still, a good comment has something to do with the post that you are commenting. Just, “I liked that”, does not. Because I have had Russian at school, you can’t lure me with Kyrillic letters.
I am an advocate of freedom of speech especially in Internet. See more about this topic in EFFI . So, I prefer anonymous comments without any emails and homepages. Links are considered harmful in information security point of view.
So, I still welcome comments.
How to grow a good developer
Jun/090
I read Malcolm Gladwell’s book Outliers It was well worth of its cost - 7 euros, because it is well written an easy to read. The ideas were not actually new, but getting an idea of how successful people are made is made clear. Bill Gates was one of his examples.
First of all you need luck to succeed. For example Bill Gates was one of the lucky few young people who had unlimited access to computer time in 1968. Second very important thing is 10 000 hours of hard work. Creating a professional skill in any area of life requires 10 years of enthusiastic learning. You have to be lucky to have a good “university” for that. It was Hamburg for the Beatles.
Success is not as much of IQ as employers are used to think. An old study of Lewis Terman, a professor of psychology, has shown that the success of people with high IQ is not as good as we typically believe. The geniuses that he found did not succeed much better than ordinary people. Gladwell conjectures that IQ has a threshold value. Your IQ must be good enough to get in into good universities but above that other things are more important. Creative thinking is more open ended than an ability to solve puzzles that have a single right solution.
Now thinking about growing good software developers. Most important thing is to have that 10 000 hours of work. It is also important to have multifaceted experience. A 10 year career of COBOL-programming in same domain area or even a piece of software is not more than 10 times one years experience. I even wonder what has kept the person in a position where he can’t learn anything new.
I emphasize attitude, the passion to do ones work. It is a known hiring guideline to hire the attitude and train the skill, but this is much easier to say than actually do. The same frustrated looser that you fired may become a passionate star of your competitor. So, it is not so much about selecting people but about creating a corporate culture. An that is really hard, especially when your business environment is difficult.
Agile and lean software development is all about people. It is not about processes and tools as should remember from Agile Manifesto. Nevertheless, the people focus on the Scrum process and kanban in Lean believing that the change of process is the silver bullet. I admit that I have seen remarkable increases in teams’ motivation when they have adopted Scrum, but I assume that the correlation does not mean a causal relationship, especially if we ignore the human part of agility.
In this post I have intentionally ignored what Gladwell said about cultural background. Read that from his book 
8 years of Lean Software Development in Tieturi
Jun/090
The program of our forthcoming talk is now online.
Projektinhallintapäivä 12.8 (In Finnish)
This 45 minute talk will describe the system that we have used in developing eLearning solutions for our customers and of course something about the experiences we have had. The system is basically a kanban organized by one list of tasks to do supported by a weekly meeting.
Agile acquisition and fixed price
Jun/090
I have been quite busy lately and not been very active with this blog. However, discussion about agile acquisition has become more acute because there are few failed purchases in public discussion. I mean AKE and TEO, who’s purchasing procedures have been questioned by Valtiontalouden tarkastusvirasto. See more (in Finnish)
General public and politicians typically react to problems by requiring more front-end design and rigor to the procedures. This makes the situation worse, because it increases unnecessary costs and bureaucracy.
At first we need to understand that hiring a designer is different than buying something that can be accurately defined before the purchase. When you buy design work minimizing the cost is not the only and not even the most important consideration. There are huge quality differences in the various solutions offered by the vendors. Comparing them is not straightforward and easy. One of them could propose a COTS solution, another something based on SOA and 3rd one a fully tailored solution. Obviously, it is not possible to define exact requirements without any idea of the implementation. Actually defining the exact requirements is exactly what the development project is supposed to do. If I knew exactly what I want I would not need the designer. The designer is hired for contributing while we work together to create the forthcoming software.
Because software development is a common endeavor with the buyer and the vendor, asking a fixed price is somehow skewed. I, as a buyer would probably get the maximum price with all of the risks included in the prise. If the competitive pressure keeps the cost too low, my vendor can very easily compromise the quality. It is also useful for me that my organization has an interest to lower the costs by removing unnecessary features. Prioritization is rarely happening in fixed price projects.
But I still have a budget, idea of return of investment. To keep the costs in bay I need to collaborate with the vendor to spend the money wisely. Monthly deliveries of done increments of functionality are a safe bet. If the vendor can not deliver, I have to stop the project (and have that allowed in the contract) and try something else.
Agile acquisition
Jun/090
I have added a comment to Agile Finland’s forum
Neuvottelumenettely needs promotion
The Finnish law of public acquisition does not require that we do competitive bidding using comprehensive requirement specification. Public buyers does not, however, know the allowed negotiation procedure (Neuvontamenettely) that is more suitable for purchasing software development services. So, agile community should do promotion to improve the situation.
Read more details in the discussion chain. I have corrected the word neuvontamenettely to neuvottelumenettely.
Scrum Team availability
May/090
If you read XP or Scrum books or online sources you find that team is a stable group of developers who work full-time to accomplish the goal. The recommended way of estimating its capacity is to use historical velocity and team members report effort remaining in hours to have daily updates of the burn down charts.
In agile estimation the estimate of the complexity of the features, often expressed in story points, is the easy part though not trivial. In my thesis I have a small experience report about the variability of the feature sets, but I will leave that now. Instead I want to talk about the variability of the team’s capability to implement what they have promised.
In real life the organizations are not so lean that they have dedicated teams for the development. Instead, each developer has responsibilities in multiple projects and also critical maintenance work that must be done as soon as possible. An of course, they are also vacations, trainings, corporate administration and common meetings.
Some the capacity variation mentioned in the previous chapter is known or can be estimated in the Sprint planning. Using just velocity averages assumes that this variability is irrelevant and averages out in a large number of Sprints. But if we know that most of developers have their vacation in July, then it is just reasonable to take that into account and adjust the promises accordingly. In my own Sprints I have asked every developer individually how many person days is he/she available for Sprint work. That is best guess of the capacity at the moment. An then the team limits the work into that. Naturally, there is a mathematical relation between velocity in story points and capacity in person days. So you can still use story points as your unit if you want.
We could argue about the best guess of the capacity. In historical average velocity we take into account the average changes of the availability of the developers, because we count only the story points of realized features. It could be better estimate of the capacity if the developers have optimistic bias in the Sprint planning. But in averages we don’t have known capacity deviations as we have if we ask the capacity from the developers.
The real variability of the capacity occurs during the Sprint. It is not enough that team members report the effort remaining of each task. Suppose that I have promised to be available 15 person days in the Sprint and I get an urgent need to put 10 days to something else. Then it is quite natural that I tell that as an impediment in the daily Scrum as soon as I know about it. The consequence might be that a feature is taken away from the Sprint. Obviously the burn down chart would have told the same thing but not so early.
I think that it is relevant to take availability variations into account in Agile projects, because they have impact on the stress level of the developers with all of its consequences. The variability has also consequences in releases especially when we work in a project which has many teams that depend on each other. Realistic daily view of situation is needed.
That’s it today. A long story of a small but important detail.