Archive for the ‘Agile’ Category

There are other admirable companies besides Toyota

I have currently read the book Maverick! from Ricardo Semler who is CEO and owner of Semco Group, a Brazilian company. Normally you can read today a lot of Toyota and it’s sophisticated and very successful practices and general management style. But Semco is a company which started as very traditional managed company, with a very unspectacular product range, hydraulic pumps and dishwashers in a country which was definitely not known as successful economy. Ricardo Semler and his very creative co-workers have build up a company which seems to be very unique in the world: the structure is build on the best values of democracy, capitalism and socialism, it survived a hard economic system and produce very low organizational overhead. The Semco Way is based on fairness has proven that if you trust people and keep them responsible a more effective and agile company can emerge.
I highly recommend to read this book, it helps to understand why traditional management structures are ineffective and no way to go in our fast changing world …

UPDATE: His second book, The Seven-Day Weekend, is different from his first. Maverick! is basically a biography of Semco, the newer one is written from a more outsider like position and, more interesting, after Semco has become a very large, diversified group of different companies. So this book is written in a bit more like style of an general management advisor, but never the less highly recommended.

Found a missing piece

I’ve currently read the book Agile Management for Software Engineering written by David J. Anderson and I have to say that the book really fill a gap in the description of agile practices. Anderson describes very well why agile methods work and that maybe have the same impact as the Toyota production system models had on the manufacturing side. Besides explaining the advantages very well, the book provides to not so common highlights: the comparison of a cost oriented management method against throughput oriented, the reasoning why most resources used for software development are constrained ones and, unique for a book on this topic, metrics to keep track of an project, plan buffers and quantify the output value.
An other interesting point, and rightfully so, is that he emphasis that the phases of software development are always the same, analysis, design, implementation, test and deployment, only the the time then and the way how they are executed are different.
The second part of the book makes a very good comparison between traditional management methods and various agile ones, namely XP, SCRUM and FDD (Feature Driven Development). All methods are presented with metrics for planning, tracking and costs so he can directly show how and then each has advantages.
The book is available since some years but because I was not so fond of the ideas behind FDD, which I misunderstood somehow, I never read it until now. After reading, I highly recommend it for everyone who thinks that a piece of knowledge was missing if you have to argument in favor of agile methodologies and practices.

Why motivation is more important than skills

Software development projects are always a challenge especially so if they are realized very fast and with the help of agile practices. By far the most important skills inside the team is the motivation to take the bait and the willingness for taking responsibility of his own work. Technical skills are necessary but by far less important. Skills are always teachable and every technical skill can be learned by everyone if he really wants it. But if you are not believing that you can successfully finish your work or it does not matter what you do, the project is nearly lost. Software projects are always a very uncertain territory and you have to change your path very often. For not getting lost it is essential that you know what your target is and you really want to reach it.

Currently I’ve the problem that my team has skilled and experienced members but the motivation to finish the project or to throw in more than the minimal acceptable amount of work. The project is already on a critical path but no one cares. The reason is in this case that trust in the success and the usefulness of the project was lost shortly after the start of the project (or never existed). The company management changed the path sometimes, feature creep is happening and there is definitely not much trust and expectation that the result will be finished in time and is valuable. So there a lot of external consultants, internal company struggles for influence and some unmotivated teams. So how could this problem solved? In my opinion only in that way that you have accept the current situation, appeal to the professional pride of the team members and try to finish all with less than the real existing amount of capabilities. After the finish line, full stop and rethink the whole eco system because it makes certainly no sense to go one step further.

This is the first time that I have the situation that the environment to realize a software project is so poisoned that the willingness to finish a project is nearly zero. I heard such stories from bog development shops as they could be found in large companies for internal software but it was new for me that you can paralyze also small teams completely. For the future I know now that the only way to solve the dilemma is to react on the first singes inside the team and fight back internal or external attacks on the moral. The last possible solution is to stop the project as soon as possible because otherwise it will become a tour de force

Managing “long running” stories

Sometimes, if you work in a iterative and time boxed development process, you are struggling with stories which include a long running operational task. Normally the actual implementation and reporting costs you not much time, the problem is that the operational task, such as import of large data sets, needs a lot of time and only the complete completition of the task will close the story. The first chalange is, how to estimate such stories? If you only take in account the actual work, your estimation is very low, but you know you cannot compare it to other stories estimated. On the other hand, if you estimate somehow the effort and the duration of the story, you are also not telling the real truth, because most of the time until the story is finished, you are not working actively on it. Sometimes the situation is event worse if such a story takes longer as your timeboxed iteration and extreme extension is no option. So what to to? My solution so far:

  • Split the story in two, one which covers your upfront work and implementation, the second covers the tasks for completing the story (check results, write reports …)
  • Leave the actual operation task uncovered, the initial story starts in one iteration, the finishing story in any following iteration if you are damned sure the task will be finished
  • Estimate not the duration of the lung running part, only the tasks itself
  • Optional, watcher stories/tasks can be defined

With the splitting of stories, you can handle the tasks inside a iteration, make a commitment to them and finish them in time. I’ve had this problem actually with really long running database imports which somehow were to long for short sprints (2-4 weeks). So I was looking if someone had the same problems with this kind of stories but found no solution. If anyone knows a better method or has knowldge this specific ideom was described already in the literature, give me a word.