For a short period of time I was employed by Q-Labs, a company dedicated to process improvement within software development. However they seem to be stuck in a traditional thinking with a rigid requirements process and heavy project planning upfront, trying to be predictive instead of adaptive. And for some reason they keep promoting CMM/CMMI.

In their latest newsletter (in swedish) they describe how they made Intentia (now Lawson) become more efficient. The measures they suggested were clearly non-agile, focusing on prolonging the project planning period in the beginning of a project and making predictions about future plans. They also give them the advice to be less adaptive.

Being a company dedicated to software process improvement, I find it somewhat strange that they hardly even mention agile methods and processes on their web site. I bet that I can help Intentia become even more efficient using agile methods.

Links:
Q-Labs newsletter

Uncategorized | 1 Comment »

I haven’t been posting for a while now due to vacations and I promised myself not to think about work during this period.

Originally I planned to be gone for another 4 weeks, but change of family plans made me return early to prepare for a lenghtier period of parental leave during the fall, while my wife goes back to studies and until our smallest boy is big enough to go to child day-care. Embrace Change!

This also means I have to end my present customer assignment as a CM. But I will still try to work, partly from home, 20-40% to keep up with some of my other tasks, including keeping this blog alive.

Uncategorized | No Comments »

Capturing requirements in large “non-agile” enterprises seem to follow a common template:

• Business stakeholders are anxious to catch all of their known requirements into the first release.
• Users generate hundreds of detailed requirements that often bear little relationship to the business problems that need to be addressed.
• Most requirements are given the highest priority.
• Requirements are signed off before handed over to design and implementation.
• The requirements represent today’s view, which will most certainly have changed by the time all requirements are implemented.

In Methods & Tools’ latest newsletter Ian Evans shares his experiences on Agile Delivery at British Telecom, where he addresses the problem above as well as other problems related to agile adoption at an enterprise level.

Uncategorized | No Comments »

I don’t remember where I heard this but I still want to share it:

Leadership is about helping people cope with change, while management is about coping with complexity.
Leaders set direction, managers plan and budget.
Leaders align people, managers organize and staff.
Leaders motivate, managers control.

Uncategorized | 2 Comments »

15 September I will give a breakfast seminar on the subject Lean configuration Management, where I will tell what agile and lean principles can do for CM regarding productivity. Or the other way around I will tell the agile community what CM can do for them.

This means I will continue writing my paper on the same subject. I am also happy to have recruited a co-author, Daniel Karlström, PhD, who will help me improve the academic quality of the paper.

Uncategorized | No Comments »

A familiar atmosphere characterized the fist day of the conference and many good speeches were given. To highlight a few of them:

• Jens Østergaard, Agile Development - gave an introduction to the agile manifesto and Scrum. (Jens was the one who certified me as a scrum master.)
• Jeff Sutherland, Patientkeeper - shared his experiences on hyperproductive and distributed Scrum teams, having team members in USA, Canada and Russia. Jeff Sutherland is a very convincing speaker with high credibility, since he has thorough hands on experience on the subject. He bloody created Scrum!
• Tom Poppendieck, Poppendieck LLC - shared his experiences on a Scrum implementation filled with all sorts of obstacles in an organisation full of problems. They have drawn some valuable experiences that he presented in an excellent way.
• Boris Gloger, SPRiNT iT - shared his knowledge and experiences on the subject of Retrospectives.
• Mary Poppendieck, Poppendieck LLC - talked about agile contracts and why fixed price contracts should be avoided. I have discussed the same subject in a previous article, so it was very interesting when Mary took the subject even further and shared her knowledge about the Toyota way of doing this.

I will not participate on day 2, which is a full day tutorial on implementing lean principles.

Uncategorized | No Comments »

Jeff Sutherland just posted his view on the three questions of the daily scrum meeting:

• “What did you do yesterday?”
• “What will you do today?”
• “What is blocking progress?”

Why the Three Questions in the Daily Scrum Meeting? - Worth reading!

Uncategorized | No Comments »

While continuous integration triggers a build and automated tests as soon as anyone checks in or integrates the latest code changes, it is still needed to check in frequently to stay out of integration problems.

Continuos testing however runs the automatic tests continuously in the background as soon as the individual developer compiles his code. This way the developer gets immediate feedback both on compiler errors as well as regression test errors and the time and energy to keep the code well tested is reduced.

Read more:
Continuous Testing - research and an Eclipse plugin for continuous testing.
Continuous testing and CruiseControl - article by David Saff, developer of the plugin

Uncategorized | No Comments »

Still most of my writing efforts are focused on the paper, but I did some reflections on process improvement that I would like to share.

Process improvement is not about changing the process. It is all about changing people. Three things are needed to implement a change, and all three of them are needed.

1. awareness – that a change is needed. If the awareness that something needs to change is missing, nothing will happen.
2. will – to carry out the change. Same here, if the will to change is missing, nothing happens.
3. action – if the awareness and the will is there all it takes is action, but it is still needed.

I.e. it is not enough to hand over some new nice process documents and wishing the customer good luck. It all starts with creating awareness to change the process and then continues to create motivation and will to change the process, within the people of the organization from management down to the developer team. This is done with coaching and mentoring on site in projects with the customer.

Comments are welcome…

Uncategorized | 2 Comments »

At the moment I am writing a paper on Agile CM and I have some great ideas. I’m not sure what will be the result of this but I will probably make an effort to send it for review to a conference. If it is accepted I will let you know.

Uncategorized | No Comments »

Most people aren’t promoted because they are good listeners. They get promoted because they are good workers, or worse, good talkers.

Sometimes we think of successful sales people as persons that are good at talking and being persuasive, when in fact they should be good at listening and being receptive. Listening is the most effective way to learn what customers value. Can we afford not to listen?

Many people don’t listen with the intent to understand, they listen with the intent to reply. As listeners we can think approx. 500 words per minute, while the normal speaking rate is 150 words per minute. This gives us room to formulate the response in advance, but doing so you might miss out valuable information. Formulate your response after you have listened out everything that is said.

Want to become a better listener?
The Art of Listening

Uncategorized | 3 Comments »

One of the foundations of agile methods are quick feedback loops. Agile development methods aim for quick feedback to the end users. Meanwhile continuous integration is a way to provide quick feedback to the developers about the quality of their code.

Continuous Integration (CI) is a practice within Configuration Management where the integration, building, testing and reporting is automated by tools. As soon as a developer has delivered any code changes a tool is triggered that automatically builds, baselines, tests and provides a report of the status of the code base.

Integration should be done often by developers to avoid any big bang integrations that are complex to solve. Frequent deliveries are valid here too.

The reason for introducing CI is to automate tasks in order to decrease manual overhead in an (agile) environment with short iterations, frequent deliveries and collective code ownership.

Learn more about CI by taking a look at these excellent links:
Continuous Integration - article by Martin Fowler
Continuous Integration - article on Methods & Tools
CI link list - a list of CI links in a CM wiki
Cruise Control - an Open Source tool for continuous integration
Cruise Control Wiki

Uncategorized | No Comments »

The agile track at the JAOO conference this year sounds really interesting:

“What makes agility work? Meanwhile agile methods are state-of-the-art. Many projects around the world are using Scrum, XP, Crystal Methodologies, or other known or self-made agile methods. However, not every project is succeeding using agility. This year we concentrate on the things that make agility work. Thus we’re looking at the readiness for agility of the development organization as well as of the client organization and at ways on how to measure and improve the effectiveness of agile teams.”

Especially interesting is how to measure the effectiveness of agile methods. I need proof that it works in my arguments with some clients.

JAOO conference

Uncategorized | No Comments »

The main problem with peer reviews (or software inspections) is that they belong to a traditional way of looking at software development. In agile methods there is no need for peer reviews.

In traditional software development (waterfall, V-models and RUP) testing is pushed to the end of the development cycle and because of the very long cycles/iterations it becomes expensive to find and correct errors. To cope with this problem it is often considered, by the QA, to be a good idea to introduce peer reviews to find errors earlier in the cycle. However this is only treating the symptoms instead of finding the cause of the problem. One problem is that the process is too heavy and instead of slimming the process, adding peer reviews makes it even heavier.

A better way to solve this problem is to introduce agile ideas into the process e.g. short iterations to get quicker feedback, working closely with the end users, collective code ownership and using testing to support the development instead of just finding errors i.e. test driven development.

Software Inspections - an article by a guy who is thinking in a box, and who probably doesn’t agree with my article since he makes a living from inspections. Read his article to see the waterfall approach and treating the symptoms instead of attacking the cause.

Update [2006-08-22] Some views on code reviews:
Code Reviews Considered Hurtful
The Spirit of Code Reviews

Uncategorized | 2 Comments »

The daily standup meeting is a common method within agile development, but could be utilized regardless of development method.

The Scrum meeting is a short daily status meeting described in the Scrum method. The team gathers each morning for a standup meeting where each team member in turn gets to answer three questions

1. “What have you done since the last meeting?”
2. “What will you do until the next meeting?”
3. “What obstacles are in your way for completing your tasks?”

The questions should be in relation to the backlog to always keep focus on the items on the backlog.

The reason that this works so well is that we expose problems as soon as possible. This is the same principle as the “Stop the Line” culture of the Toyota production system that the Lean Software Development is all about.

Read more about the daily standup meetings here:
Agile Meetings - a great article from the STQE magazine
Introduction to Standup Meetings – article from DSDM consortium
Lean Software Development – a gold mine of interesting publications by Poppendieck

Uncategorized | 2 Comments »

The speakers are decided and the program is printed and ready.
See you there…

Uncategorized | No Comments »

Being a scrum master is basically the same as being a coach, in this case team coaching. Coaching is about creating self awareness and making the coachee take responsibility himself. As a coach you are not supposed to reach any goals or solve any problems for the coachee. The same goes for the scrum master, it is not about managing and it’s not about solving the problems for the team. It is about creating self-awareness that makes the team take responsibility and helping the team focus on their task.
Coaching is what makes a self-organizing team.

These articles also come to similar conclusions:
Agile Management is Servant-Leadership (Agile Advice blog post)
Agile Coaching

Uncategorized | No Comments »

I have decided to try to terminate personal development talks (PD-talk, Swe. pu-samtal) in favor of coaching. I have tried coaching during a period for a chosen handful and it has turned out successful.

I want to support the employees in their personal development by enabling them to focus on their goals. The idea is to have a coaching session every month where we can talk about their goals and obstacles, to help keeping focus on these issues. This enables us to put up both long term and short term goals and to follow them up on a regular basis.

A PD-talk once or twice a year doesn’t allow us to put up short term goals in a successful way, and putting up long term goals without dividing them up into short term sub-goals looses focus.

For a consultancy business where most of the consultants are located externally at customer sites it is of even more importance to have a close dialogue with their nearest manager.

Yes there could be conflicting situation being a person’s manager at the same time as coaching them, but we have to live with that. The benefits still outweigh the disadvantages. Coaching is essentially about raising self-awareness and taking responsibility.

How do we do this then? My idea is that we kick-start with a coaching education for all managers and then we create a coaching schedule and simply start coaching. After a while we follow up and evaluate eventual needs for more education or perhaps a coach for the coaches.

Two educations that we are evaluating at the moment:
Coach2Coach
Mercuri

Uncategorized | No Comments »

This project took place several years ago, way back when I still was coding, mostly for Oracle databases. The customer was in the financial sector and the IT department was quite immature and had basically no formal processes or methods at all, no written requirements and no version handling.

A bit frightening at first, but we (unknowingly) adopted an agile approach:

• We worked directly with the customer who sat almost beside us dictating the requirements without any filters.
• Code was king - as soon as we got an idea we coded it to get a feel of it and showed it to the customer.
• We didn’t document - the code was the documentation.

Looking back we actually followed the Agile Manifesto.

The result was that the development went at a tremendous speed. But having no process also meant problems of course. To mention a few:

• We didn’t have an exit criteria. I didn’t know when I was ready, which meant that I eventually ended up in a really boring phase of endless changes back and forth, making me finally leave the project.
• Maintenance of the system would be quite challenging.
• We were a small team, but if team size would grow I believe we would have ran into more problems.

I think that adopting an agile method like Scrum would have taken care of some of the problems and let us keep the development speed.

Uncategorized | 1 Comment »

I have evaluated my blog experiment and decided to scale up. In this process I have renamed it, moved to a new domain, did a complete graphic redesign and finally moved all the previous posts, so everything should be here. I know I shouldn’t rename and move it, but I want to do it before it (hopefully) grows too much.

What about the name then? Well I am a member of Mensa so why not? I think it works pretty well, it’s easier to remember than the old one. And the IQ? 156 on the Catell scale, meaning top 1% of the population.

Well, enough bragging. Come on in and read. If you like it go ahead and subscribe or bookmark it. Or why not both?

If you have any feedback, please comment!

Uncategorized | No Comments »

The reason for human domination on this planet is our extraordinary ability to adapt to change. But why do we try to fight this ability within software development?

Only changes in the near future can be predicted, for the rest we have to adapt and overcome, like soldiers. Any change, even a small one can invalidate a whole plan. A goal however, is more stable and can survive even major changes. That is why an agile team must strive for a goal, not a plan, while responding to changes on the way to the goal.

The Horizon of Predictability is the distance into the future that a team can be reasonably sure that plans will be stable. Any further into the future plans start to get uncertain and even further the future becomes totally unpredictable.

The horizon of predictability varies depending on the environment, but is for most IT organizations not more than 30 days, i.e. the iteration length of a Scrum sprint.

To minimize the overhead in short iterations consider automating your environment e.g. continuous integration, daily builds and automated tests.

Read more here:
Change is constant - blog post at Agile Advice
The pros and cons of short iterations - blog post at Agile Advice
How long is a time box? - blog post at the Pragmatic Architect
Predictability Paradox - whitepaper by Mary Poppendieck

Uncategorized | No Comments »

Sure MS Project is a powerful tool. However it is not suitable for agile projects. It’s not even suitable for software development at all.

MS Project is based on the waterfall method. It teaches users how to make complex and complete plans upfront. It makes the plans almost invisible for the team. It’s hard to track real progress and there are no backlogs. Sure it could be done with some efforts, but it’s not designed for it.

There are people that agree with me:
Why GANTT charts where banned in the first Scrum (by Jeff Sutherland)
Why MS Project Sucks for Software Development
The definitive guide to why MS Project Sucks…

Uncategorized | 2 Comments »

This is one of the best descriptions of agile methods I’ve heard:

Agile methods are adaptive rather than predictive. Instead of planning for a long time span and fear change, Agile methods embrace change and adapt accordingly.

Uncategorized | No Comments »

Bring out your calendars and cross out 12-13 june!
Softhouse will be arranging Agile Øresund, which is an agile conference in Malmö. We have already booked a couple of agile celebrities:

• Mary & Tom Poppendieck – the authors of the award winning book “Lean Software Development: An Agile Toolkit”.
• Jeff Sutherland – co-creator of Scrum.

Stay tuned for more info…

Meanwhile read this:
Softhouse
Poppendiecks
Jeff Sutherland
“Lean Software Development: An Agile Toolkit”

Uncategorized | No Comments »

Unfortunately I missed the Agile Configuration Management meeting the other day. I got some material anyway that I read through. It was draft documents, so I was not allowed to spread them. However I made some reflections that I would like to share.

Since there is no explicit Configuration Management (CM) role in an agile project someone could easily make the mistake believing that CM is not taken seriously in agile methods. CM is all about managing changes in a controlled way, and agile methods embrace change.. right? So it should be quite natural to have CM in agile projects then? It is, but it’s not done in the same way as in more traditional projects.

CM in agile projects is about collective code ownership, continuous integration, frequent releases, refactoring and must be distributed among the developers. High demands are put on the team because of the short iterations, frequent releases and close collaboration with the customers. Appropriately applied it will improve the pace of change and is actually necessary for success.

CM is seldom mentioned when talking about agile methods. Instead we expect teams to rely a lot on tacit knowledge. What needs to be done however is to put CM on the agile agenda and make CM activities in agile methods more explicit.

More info:
Another whitepaper from LUCAS about SCM practices in XP teams
LUCAS homepage

Uncategorized | No Comments »

this is the best overview and explanation of Scrum that I have encountered so far, please have a look!

I have mentioned Scrum often in my posts. Scrum is an agile software development process.

The Scrum Development Process

Uncategorized | No Comments »

Retrospective (from Latin retrospectare, “look back”) generally means to take a look back at events that have already taken place. (Cut from wikipedia.)

Within software engineering it often means to have a review meeting with the whole project team at the end of a project or an iteration to discuss what was successful and what could be improved and also how to incorporate the experiences into future project and iterations. The retrospective can be done using different methods, and they could be formal or informal.

Questions to be answered during the retrospective should include:

• What did we do well?
• What did we learn?
• What should we do different the next time?
• What still puzzles us?

In this blog I do retrospectives of my own as a way to write about experiences from different projects that I have been in.

A retrospective gathering will be held in Germany this spring 3-7 April, 2006.

Read more:
“Project Retrospectives: A Handbook for Team Reviews”, by Norm Kerth
Retrospective Gathering 2006
www.retrospectives.com (Norm Kerth’s website)
Presentation about retrospectives
Another presentation about retrospectives

Uncategorized | No Comments »

Normally we don’t associate configuration management with agile processes, but nevertheless it is needed even in an agile project. The keywords with agile configuration management are “frequent changes and integration” and the CM process needs to support it. It’s about having the correct amount of process. Not too little, then the codeline will degrade, and not too much, then the workflow is disrupted instead of supported.

However the difference to traditional projects is that in agile projects there is no dedicated CM role. Instead the CM activities are carried out by the team, where everybody needs to have a certain amount of CM knowledge.

Lucas will shortly arrange a meeting at LTH around the subject: “Software Configuration Management in Agile Development”.

Read more:
Lucas meeting
SNESCM coffe meetings
Forum post on topic

Uncategorized | No Comments »

If you are still not convinced about agile methods maybe you should join this conference?

Waterfall 2006

Uncategorized | No Comments »

Spin-Syd is arranging a meeting around the subjects of “Extreme Testdriven Development” and “Extreme Continous Integration”, i.e XP. The host of the meeting is Erik Lundh.

Spin-Syd is a network for exchange of knowledge and experiences around software processes in southern Sweden.

Read more here (links in Swedish):
Spin-Syd meeting 2006-02-14
Spin-Syd
XP explained

Uncategorized | No Comments »