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.

In the previous post I referred to a post that points out that there is a clear distinction between method and methodology, and that methodology means the study of scientific methods. After looking to wikipedia’s definition of methodology and more specific the following definition:

“Another key (though arguably imprecise) usage for methodology does not refer to research or to the specific analysis techniques. This often refers to anything and everything that can be encapsulated for a discipline or a series of processes, activities and tasks. Examples of this are found in software development, project management and business process fields. This use of the term is typified by the outline who, what, where, when, and why. In the documentation of the processes that make up the discipline, that is being supported by “this” methodology, that is where we would find the “methods” or processes. The processes themselves are only part of the methodology along with the identification and usage of the standards, policies, rules, etc.” 

I have to say that the literature I read uses the word methodology a lot in this context. Although the software literature doesn’t follow the distinction this post describes, the definition of the word methodology nowadays includes the use of word in the software community. And so our vocabulary grows with probably people for and against it.

In the following post a reminder is made of the correct use of the word method and methodology. In a lot of software literature this distinction is not made. I don’t/didn’t follow it either.

The 6th comment is very funny.

“I cdnuolt bleveiee taht I cloud aulacity uesdnatnrd waht I was rdanieg. The phaonmneal pweor of the hmuan mnid, aoccdrnig to a rscheearch at Cmabrigde Uinervtisy, it dseno’t mtaetr in waht oerdr the ltteres in a wrod are, the olny iproamtnt tihng is taht the frsit and lsat ltteer be in the rghit pclae. The rset can be a taotl mses and you can sitll raed it whotuit a pboerlm. Tihs is bcuseae the huamn mnid deos not raed ervy lteter by istlef, but the wrod as a wlohe. Azanmig huh? yaeh, and I awlyas tghuhot slpeling was ipmorantt!”

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.

In the previous post I talked about my experience with companies choosing almost randomly an implementation methodology for their project. I stated that it looks like not much research is done in the determination process of an implementation methodology. This can have negative consequences if the implementation process doesn’t tackle the business problems well and doesn’t match or maximize the capabilities of an implementation team.

The experience I have with implementation methodologies in a Dynamics Ax environment is that mostly a waterfall like method is used. No evalutation is made to use other methodologies and so iterative and agile methods are not taking into account. Even when it has been argumented thousands of times that this methodology doesn’t provide the best results. The V-model method and the Regatta method are 2 reoccuring methods. Although I personally haven’t experienced the use of the Regatta method from close. Both are looking very alike, except that Regatta looks to be more tuned for customization projects and business needs, for which I think it can really work, while the V-model is a frame with a bigger lack of business related implementation issues. I have the impression that the old dinosaur (Waterfall) has been kept alive by companies who only look to the obvious direct result, and lose touch with the investment from the customer and the employees. Even when the result falls below expectations and definitely on a quality level, the implementation methodology is not seen as an important cause.

To create with more assurance quality in your product and business, reduce cost to implement and maintain the product, and to maximize business value, a structured implementation methodology is almost essential. Luckily a lot of methodologies are nowadays available in the literature and a lot of fine, detailed and understandable papers and books can be found. Still choosing one for you project, using it in a correct way, and this in a good business context doesn’t look that evident.

Choosing an implementation methodology is part of the business case process. Although at the moment I question if they get the necessary attention in the overall determination process during the business case process or after. I experience that the functionality the product will provide gets more attention than the implementation process. In the long run the product brings the most value, but the process in which it is formed will determine what the product will be. An implementation process is an essential driver for the products functionality and quality, still it looks like this argument is not strong enough to give it its full required attention. It looks like almost every IT-company uses for every project the same implementation methodology and not much research and value is given to the importance of the quality providing task of the process in which the product will be implemented. This even when there is a big difference between projects were there is the development of a new product with lots of uncertainty, and simple customizations. These 2 edges: uncertainty and certainty should certainly be drivers in determining the right way to tackle the business problems.

Undergoing change is something companies aren’t enthusiastic about. They like to stick with what they know and try to get the most out of the established business culture and methods. On the other side, there is an equilibrium point where other methodologies give the opportunity to provide more business value. When this is reached or passed, the business value is no longer maximized with the current methodology. Change or at least research for change should no longer be put aside. This may sound like obvious it is important to notice. Lots of time, money, human resources and knowledge get lost if the methodologies don’t get the right attention. Finding this point and taking the right action is definitely a difficult part. Certainly a good way to look in is in the direction of the standardization efforts, but most of all looking sinecerly and objectively to the problems in your implementation method, culture and business.