Archive for the ‘Methodology’ Subject

Some of the problems I see in Agile Methods – Part 2

Sunday, November 22nd, 2009

Another problem I see in some Agile Methods is a lack of flexibility about the rules they propose. I see that as some kind of contradiction: for example, Scrum is empirical only for things that it does not define beforehand.

“Don’t change Scrum” is something that Ken Schwaber wrote in his book Scrum and the Enterprise. Here’s his rationale for this: Scrum isn’t a process that you can modify to fit your enterprise. Instead, it exposes every dysfunction in your enterprise while you build products… Whenever people change Scrum, it’s because they’ve run into a problem, dysfunction, or conflict that they do not want to face and fix. Instead, they change Scrum so that the problem remains invisible and remains deadly to the enterprise. If you allow this to happen, you will have lost Scrum’s primary benefit”.

(more…)

Some of the problems I see in Agile Methods – Part 1

Tuesday, November 10th, 2009

First of all, I admit I do not consider myself an expert in Agile Methods. Yes… I’m a Certified Scrum Master and I’ve been involved in several agile projects. But let’s say I don’t know enough and have enough experience to consider myself an expert. Even with this, I will dare say which are the issues that I don’t see addressed correctly in these methods, or at least in the typical “Scrum + XP” combination that used in most cases in Industry. The risk here is that someone will quickly reply with a link to explain how these issues can be solved. Oh well… I’ll take that risk.

I also want to say in advance that in general I have a positive view on Agile methods. I think they are an interesting packaging of useful practices and that they have made a huge contribution to development practice in general. I also value some new practices like TDD and Continuous Integration that have provided smart answers to increasing challenges of software development.

(more…)

Co-evolution – Brooks did it again

Wednesday, October 21st, 2009

In a previous post I commented about Fred Brooks’ great conference when he received the Turing Award. He named it “The Design of Design”. In that conference he spends a lot of time discussing life cycle models and explaining why the Waterfall model is wrong (“dead wrong” as he calls it). And he also presented what he thought was a better model: the co-evolutionary model, attributing it to Maher and Cross. In this model, from a Problem P1 you get a Solution S1. And from P1 and S1 you get a new problem, P2. And from P2 and S1 you get a new Solution, S2. This simple concept explains that the problem and the solution evolve in parallel. And it’s one of the good things that Agile Methods have adopted. If you use agile methods, your lifecycle model is not only iterative and incremental. It’s also co-evolutionary. Let me explain this better.

(more…)

Significant Design Up Front, When?

Tuesday, August 25th, 2009

So in my previous post I said that nowadays there are fewer cases when building models before building the actual code of an application makes sense. In which cases does it make sense? More explicitly, in which cases should we spend a significant amount of time creating architecture and design models before we run to code? Let’s ignore for a while safety critical applications and “for other reasons very critical applications”, the easy answer to the question (I know that more and more applications are becoming critical, but still I want to focus on the other ones, at least for this post). My question is equivalent to asking “when do we need significant design up front”?

(more…)

A change in focus for Software Engineering

Wednesday, July 29th, 2009

soft My friend Hernán Wilkinson sent me a link to a blog post that included a reference to a very interesting article by Tom DeMarco. Just as a reference, De Marco is one of the classic authors in Software Engineering. When I studied systems analysis more than 20 years ago, his book on Structured Design was like a Bible.

I agree with almost everything he says there, but still I think that he takes it too hard against his own work, and I want to relate this to my previous post, because what he proposed in “Controlling Software Projects” is something that even in 1982 didn’t work in all software development projects, although from what he says it looks like he didn’t realize that at that time. But the key is that they worked in many software projects: in the types of projects that DeMarco was involved in then. So, probably his mistake was not to mention in what types of software development projects the techniques he was proposing had proved to be effective or were important in relation to what they were trying to achieve. Also, it’s easy to say now that some things proposed 27 years ago are not true anymore. Just as an example, “The Mythical Man Month“, Brook’s classic essays book that is a must for any software professional, has many things that are plain wrong if tried to applied nowadays, as Brooks himself recognized when he said “Parnas was right, I was wrong”.

(more…)