Thinking Inside a Bigger Box

Two of the hardest problems of software development are integration and what we could call business-IT alignment: The whole organization working towards the same goal.

SOA claims to address both of these problems. After listening harder than I’ve ever done before to SOA evangelists, I think I understand what mechanisms SOA proposes to solve these problems. I think the idea of SOA is based on a set of rather bold claims:

• Web Services standards will solve the technical integration problems (”the WS-* claim”)
• Centralizing integration will solve the governance issues surrounding integration (”the ESB claim”)
• Modeling use cases as workflows of services will solve the business alignment problem and promotes reuse (”the BPM claim, part I”)
• The flexibility to restructure the workflow between services will enable business agility (”the BPM claim, part II”)

I hope that an SOA evangelist will agree that these are important claims in SOA. Even if he will disagree with my evaluation of them.

Read the rest of this entry »

When I give talks on agile, people often ask the inevitable question: “When is Agile not appropriate?” My response is that I don’t really care what people call what they do. What I am concerned about is the quality and frequency of the feedback that informs the control and decisions regarding project management and technical decisions on my project. I find the idea that you might not want to improve your feedback to be very odd.

But I think I understand what the real question may be now. Feedback comes at a cost. You have to actually release and deploy your system. You have to write and maintain test cases. You have to conduct meetings with the team and the stakeholders.

What cost should you be willing to pay for better information?

I can only speak from my own experience. Currently, we have two-week long iteration. The release, demo, planning and retrospective activities take about one and a half day out of each iteration. So the “feedback cost” is about 15%. I don’t think I would like my project to devote less than 15% of its effort towards implementing a feedback cycle. If you spend days integrating your project every iteration, a one week iteration won’t work for you. I don’t recommend doing fake iterations where the iteration degrades into a planning window, either. So if it takes me several days to do a proper iteration, I would rather have longer iterations.

Here is where I depart from the spirit of the question, though: If it takes you several days to integrate your project, how do you plan to act when you have to fix problems in production? A long feedback cycle is a high risk. If you can’t iterate frequently, this is a sign you need to fix your process, not that you should adopt a waterfall approach.

This post is a Norwegian language summary of a talk I did April 14th, 2008

Jobber du smidig? Jeg jobber ikke smidig. Men jeg jobber smidigere enn jeg gjorde for tre måneder siden og enda mer smidig enn jeg jobbet for et år siden. Og om et år kommer jeg til å jobbe enda smidigere.

Men Smidige metoder handler ikke om et mål, de handler om konstant forbedring gjennom bedre og hyppigere feedback.

Read the rest of this entry »