By Marco Heerebout. I use this blog with a focus on my profession and related subjects and opinions. I'm active in the field of system development and software engineering, applying and mentoring Agile principles and Scrum, most of the times in a leading role or as Scrum master.

Sunday, October 4, 2009

The Principle of ‘Results Beat All’

Reactions: 
"The top strategy is ‘getting the stakeholder results’. Meeting requirements is more fundamental than any other process or principle."

The above text and principle comes from the writing of Tom Gilb. From his Competitive Engineering (CE) book. I'm kind of a fan of Tom Gilb. Since I got into touch with EVO, a "methodology" which could be seen as an early Agile approach of software engineering.

I just read the text because a tweet of him brought me to 100 CE principles, which are very valuable to "us". It triggered me because last week I had a tough dicussion with some people about the current status of a project.

In that discussion I was searching for the reasons of why the project still wasn't finished. The roughly expected date of delivery was about 3 months ago, but the end of the project is very hard to see and predict. I understand all excuses and reasons for not delivering yet but really can't understand that there is almost no understanding about having a HUGE problem.

I explained the team that we are not able to see any results now and that we expected to really SEE progress every sprint. The reaction was that a lot of progress has been made and that there is a lot of software that is of high quality, very flexible, future proof and now only the front-end has to be finished. And if I had taken the effort to look at the code and other non-functional artifacts, I could have SEEN progress (so it was "my own fault that I didn't see progress", WT*???). And of course, the expected date to deliver the system was unknown. No wonder we still have projects that never end or are way too late/expensive.

How can we become happy and build up trust if we don't meet the requirements? (the requested ones, with real value!). Having top-notch software without having delivered any requirements is worth nothing and therefor not really valued by the stakeholders. The top-notch quality software is normally implicitly expected.
The answers is of course to deliver the requested results by meeting the requirements. It is very simple but still not easy to get it done. And besides that, the progress transparency is adding trust. Show the progress made, the efforts it took and how long is still needed for delivering the remaining requirements agreed upon. Estimating may be hard initially, but try and improve...

The summary of this is that it's very wise to follow the basic rules and principles of proven approaches. I apply Scrum and will improve+adapt it where needed. But the basic goal doesn't change, deliver results ASAP!
The top strategy is ‘getting the stakeholder results’. Meeting requirements is more fundamental than any other process or principle.

Currently I'm working on a project approach to show and emphasize the focus on results. We expect to help customers with some short term need in one month!
When we start a project we need the global requirements and the required result. Together we create the product backlog and focus on the stories that make a system valuable and usable after ONE month! Of course not every project is completely done after one month but we are fully focussed on getting the stakeholder results available ASAP. Finishing, beautifying, fully integrating and extending the system afterwards is perfect common sense. But the value and results are there and our customer starts gaining from the added business value NEXT* month!


* if we are able to start NOW, we deliver NEXT month.

<

No comments: