Dan Rawsthorne wrote an interesting post about “Scrum is Effective, not Efficient“. I don’t follow fully so i made some comments. I write it here again because it has some aspects that are related to software architectures and which are important to produce quality. To have the full context of this post it is important to read Dan’s post.

Dan says: “The more feedbacks you have the more effective you’ll be… “

I think the amount of feedback is not so important to determine the  effectiveness, what is more important is the quality of the feedback which is aligned with business goals. Can’t a few good feedbacks be enough to know how effective you are? You can specifiy some quality scenario’s for measuring your effectiveness. Ofcourse lines of codes or function points are to vague and don’t tell much business/product relevant effectiveness. Thereby, finding the right feedback through quality scenarios can help to reach the effectiveness efficiently instead of going for a lot of feedback.
Maybe it is not easy to specify precisely what needs to be done, this is where agility comes into the picture i think, but in general every project has some clear business (case) goals and for those, quality scenarios can be provided to measure the overall effectiveness.

Dan says: “In order to be efficiently agile, you would need to have feedback loops that got you the answers you needed as fast as possible, and have as few feedback loops as possible. And we don’t know how to do that, now do we?

If you can specify how to be effective, and you say that agility is effective it means you can specify effectiveness, than you can specify a way to reach it efficiently. I think too that agility is effective and i would measure it with quality scenarios. This also gives the possibility to have a reduced set of feedbacks related to the Q scenarios and allow us to get there efficiently because we know our goal.

Dan says: “…if you can’t produce the right product every time (or virtually every time) then don’t start adding efficiencies to your process.”

Why can’t you add efficiencies in your inspect and adapt cycles?  Rethinking and implementing the way to produce a powerfull effect can also ask for incorporating some efficient steps.

Dan says: “waterfall is efficient — agility is effective”.

I think if you say it is efficient, it means that it also has to be effective.  Saying something is efficient means its result is effective.  So in the conclusion it sounds to me that waterfall is the ultimate way to go, which i doubt and probably also not the one of Dan.

When I was surfing for some waterfall related information a nice site popped up WATERFALL vs. AGILE METHODOLOGY. It is a nice comparison of the 2. The bottom line in this comparison is the aspect of certainty and uncertainty. if I need to make a choice I would sign the Manifesto for Agile Software Development. Having certainty in your implementation process is unrealistic and the Agile methodology gives a nice frame to handle the uncertainty right away.

Important to mention is that both of these methodologies position analysis, design, development and testing, but only form a basic frame and are general. When these “development” methodologies are positioned in a real business context, they have big gaps, which are issues that are very important for the business who demands the product. Gaps like

• how to communicate the request and the change to the relevant stakeholders,
• how to do the request and change follow up,
• how to tackle quality (architecture, user interface design…),
• how to handle functional and datamigration,
• how to do the documentation and training,
• how to handle releases,
• how to handle the needed infrastructure,
• …

Development aspects are tackled with these “methodologies, but the business for which the product needs to create value is not positioned well. Application lifecycle management or more widely a full implementation methodolgy is needed. It is not the development method but it are the other implementation processes that the business experiences the most and it are in those parts they need to feel confident. Confident that for their needs a solution is build. These needs also mean: Does the business need to experience a lack of information of how and when their request is tackled? Can the architecture and its automated processes be undocumented so a top level view is unfamilar and what is realized unclear? Is it ok that the user interface is still widely discussed a few weeks before the go live and it feels unfamiliar? Will the development company still want to do the billing run 10 months after the go live? …

The development method can’t live without the other processes and a fit between the 2 is needed. Additions to the methodologies are therefor very important. The methodologies can’t be used without putting it into a business context, without matching it to the full (daily and future) business needs.

Looking to the bigger picture makes the complexity and also the possibility of uncertainty in the implementation process even bigger. This gives me the idea that only a more Agile approach in the development process can create the most assurance for quality on all levels. This by taking the right time to achieve maximum quality on all levels, ofcourse still with determination, and anticipating change in the development process.