I got an email invite from Clarke Ching to answer some questions about Evo + Scrum. He had asked Tom Gilb some questions as a part of his Agile Thinkers web site and Tom had turned him on to my work. I was reading through some of the Tom���s responses and came across one of the questions which was essentially ���Where did we go wrong���? In other words, how did traditional (aka waterfall) methods become the standard in the first place?Tom provides a great response in his brief history of where we went wrong. Some things I found particularly interesting include:
Connection between the US Department of Defense, Dr Winston Royce and Barry Boehm in establishment of waterfall as preferred method for development software systems.
Software development done outside the US DoD (and not influenced by waterfall thinking) actually figured out iterative development on their own and had better results
Tom places the blame at the doorstep of top management and leaders whose lack of responsible management has essentially allowed the problem to exist.
I don���t know much about the first two, but I do know about the third one. While I haven���t had the breath and depth of experience as Tom, I have certainly experienced it in many of my engagements with all types of clients.
In my experience, top management is often challenged when it comes to understanding what they���re really trying to accomplish when they start a project or most any initiative. There���s lots of meetings, gathering the requirements, assembling development teams, procuring software and hardware, risk assessments and project plans. Busy. Busy. Busy. And then there is the budget. Even busier.
Lots of people get in a flurry without any sense if the project they���re starting is the right project. It���s the big assumption. But even if it is a good project, is it the project we should be doing next? Is it the right project now? Unfortunately, nobody���s focused on building the right thing, they���ve already progressed passed this to building the thing right. So how do things get to this situation?
The lack of responsibility rests at the leaders who are either not engaged or do not understand their organizations true objectives. This also includes what resources they have to devote to improving the organization and a specific set of priorities amongst the objectives. It���s too bad, because a little due diligence on the former would pay large dividends in not only time to market, but also cost savings and reduced risk.
I hate to say this, but Agile methods like Scrum and XP just further reinforce these bad behaviors because they completely skip over this critical first step. Just like traditional project methods, they assume you���ve figured out the right thing to do (like building a specific product or doing a specific project) and just focus on helping you build the thing right. Not that this is bad, you need to be able to execute to deliver business value, but organizations and teams miss enormous opportunities to deliver real business value quickly, and with low risk and little budget, if they���d only try understanding what���s important to their organizations and focus on the satisfying a few key objectives.
When will this start to change?
I���m trying to change this with my work by introducing some of these concepts to clients in the course of projects we get asked to do. And I know others like Jens Egil Evensen are also getting it. But in my experience, sometimes it���s a tough sell, sometimes clients get it right away and sometimes clients have no interest. It���s a mixed bag, but slowly I see things improving.
Most often if I���m brought in to coach a team new to agile or struggling with agile adoption. These are typically product or solution organizations, but sometimes Fortune 500 companies. Relatively quickly most teams pick-up the mechanics of Scrum and as time goes by, they pick up the art of sprint and release planning. Eventually maybe estimation. But what is almost always lacking is an understanding of the organization���s real objectives and whether the project we���re doing is the right one. In other words, why is the organization spending $1, $10 or $100 million on this project and not that project?
Even if it you���ve got the right project, what are the few critical success criteria that would deliver real measurable value to stakeholders buying the system and those financing it���s development?
Simple, common sense questions are rarely discussed:
Has anyone clearly defined success?
How about failure?
Has this been communicated to everyone?
If this is defined, can we measure our progress towards delivering value with respect to budget spent?
Sadly, simple questions like these are almost never probed by organizational leaders in positions to influence the direction and success of projects and teams. What seams so simple is unfortunately not common in practice. So I agree with Tom that lack of responsible management can only fall at the doorstep of the leaders who fail to grasp these basic concepts. It���s quite sad really.
Will the next generation of business and IT leaders start to change this? I hope so, but as of yet don���t know of any MBA or MIS degree program teaching these concepts, so we may be headed the wrong way for some time to come.
