10 tips on how to prevent business value risk
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
Presentation
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Recorded at:
Shaw and Fowler About Forging a New Alliance
Presented by
Scott Shaw and Martin Fowler
on
Oct 06, 2008
Length 01:14:17
How would you like to view the presentation?
In case you are having issues watching this video, please follow these simple steps to help us investigate the issue:
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
1. Right click on the video player and select Copy log
2. Paste the copied information in an email to video-issue@infoq.com (clicking this link will fill in the default details in most email clients).
Note: in case your email client hasn't automatically picked up the email subject, please include in your email the URL of the video too.
3. Done.
We will investigate the issue and get back to you as soon as possible. Thanks for helping us improve our site!
Summary
Scott Shaw, Director of Services at ThoughtWorks, and Martin Fowler, Chief Scientist at ThoughtWorks, talk about the need for a new relationship between the business department and the IT department. Studies have constantly shown that the main culprit for unsuccessful projects lies in miscommunication between the business people and the IT ones.
Bio
Scott Shaw is a manager and technologist with over 15 years experience building large-scale, distributed software systems for a variety of business domains. Martin Fowler is one of our industry's most well known thought leaders having had an influence in the adoption of OO, refactoring, patterns, agile methodologies, domain modeling, UML, and XP.
About the conference
ThoughtWorks recently began hosting events for Business and IT Leaders as well as technology practitioners to share insight and best practice across the industry. The briefings and the Exec Breakfast series are all grounded in reality - speakers are active practitioners, passionate about their work. The events focus on technology in relation to business issues, rather than being deeply technical.
Scott Shaw, Director of Services at ThoughtWorks, and Martin Fowler, Chief Scientist at ThoughtWorks, talk about the need for a new relationship between the business department and the IT department. Studies have constantly shown that the main culprit for unsuccessful projects lies in miscommunication between the business people and the IT ones.
Bio
Scott Shaw is a manager and technologist with over 15 years experience building large-scale, distributed software systems for a variety of business domains. Martin Fowler is one of our industry's most well known thought leaders having had an influence in the adoption of OO, refactoring, patterns, agile methodologies, domain modeling, UML, and XP.
About the conference
ThoughtWorks recently began hosting events for Business and IT Leaders as well as technology practitioners to share insight and best practice across the industry. The briefings and the Exec Breakfast series are all grounded in reality - speakers are active practitioners, passionate about their work. The events focus on technology in relation to business issues, rather than being deeply technical.
RelatedVendorContent
Getting Started with Stratos - an Open Source Cloud Platform
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
Agile Maturity Model Applied to Building and Releasing Software
Related Sponsor
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
- This article is part of a featured topic series on Agile
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
lean, war for talent and IT organisations
by
Gerald Loeffler
Posted
Re: lean, war for talent and IT organisations
by
Christopher Churchill
Posted
Re: lean, war for talent and IT organisations
by
Mike Granger
Posted
To Infoq
by
Christopher Churchill
Posted
Re: To Infoq
by
Deborah Hartmann
Posted
Re: To Infoq
by
Christopher Churchill
Posted
The same second post with proper formatting.
by
Christopher Churchill
Posted
Lean Software Development Value Stream Map
by
Mike Bonar
Posted
Re: Lean Software Development Value Stream Map
by
Christopher Churchill
Posted
by 2020 - any made up number is as good as statistically proven?
by
Stan D
Posted
-
let me pick on two aspects of this otherwise very good presentation:
the idea that the IT department should be abolished because IT and business suffer from a communication gap is needlessly naive. most workflows and value chains in organisations cut through several departments, and still these departments have a reason to exist, not the least because one must pick some meaningful way to structure a large group of people. finding efficient and effective ways for people to collaborate across departmental boundaries is a common challenge for management, and "project teams" are the typical answer. IT departments are not special: for the actual work in a software development project, it is largely irrelevant what department the team members originate from: the existence of IT departments need not stand in the way of excellent project execution.
on Lean and the war for talent: for 20 years we've been studying the Toyota way, Kaizen, Agile, Lean, whatever you may call it, and we've learned a lot. but the facts of renumeration in organisations fly in the face of this approach's core principle that it is the people "on the ground" doing the actual work that know best what to do and how to do it: moving up the organisational hierarchy is now financially rewarded more than ever. the renumeration gap between those that carry the workload and those that carry "responsibility" becomes wider by the day. and i expect that it is no different at Toyota.
cheers,
gerald
www.gerald-loeffler.net -
Spot on!
Furthermore, let us not forget that the Toyota model was never successfully applied to software, people claim to do it successfully well (We see organizations talk every day about lean and kaizen and a factory based process for developing software), I have yet to see a successful project that emphasizes a lot on lean and toyota and kaizen. :-(. The reason is every enterprise software, or software for any type of problem domain, is a new invention, no "process" or factory assembly line model can reasonably produce enterprise software. And we still have not reached the age where we can download modules off the web and integrate them with our application without a huge amount of research. Even then the modules fail in production, and well what do you know, since I did not write them, It is very very tough for me to debug and find out where the problem lies, whether it is in the module or the rest of the subsystems in my app. Due to this and a myriad other reasons, there are not much of "reusable components" for enterprise software at all. Of course we have frameworks which leverage a lot of the development, but apart from that, the core components of the domain model such as order management in a retail domain, there are no frameworks which can do it in a "plug and play" fashion, even for vendor frameworks such as ATG, Comergent, there is a lot of configuration, extension to etc etc and much much more complex than customizing mechanical parts in a toyota factory. Things like applying the toyota model to software were invented by people sitting at golf courses, without even interacting with the folks that were doing the heavy lifting at their desks.
I think Agile is a excellent process that claims to embody the spirit of software development that, there is nothing ceremonial about building software, Humans have their limitations of expressing in code, what they involuntarily do every day, and also it is difficult to test the entire state space of even a medium software application. Errors will occur in production, Compare this with a car produced at toyota :-). There should not be any errors in the ECU at all, and all cars adhere to this, the reason being:
1. the lifetime of an ECU is approximately 15 years, even though the brands of cars that the ECU may be installed in might differ
2. The functionality of an ECU is relatively small when compared to an enterprise application.
Hence developers have the time to test the ECU extensively, before launch and make sure that is atleast 7 sigma compliant.
Now, we can see how the Toyota model can only be applied to building cars and not building enterprise software.
We are now going back to dynamic languages and DSLs most of which have support for minimal static analysis, which will further put us back with regards to testing the entire state space of an application. Probably we need something like a Java ++++ in static analysis atleast, if not statically typed, to bring us closer to production ready code, faster and quicker.
The reason for the war for talent is to be frank, intelligent folks get turned off by venturing into the software world. Reasons being:
1. Some organisations emphasize Agile and Lean and develop complex enterprise apps with tight deadlines and very tough customers that frown when they see even a single error in production. Due to this, employees are forced to sit the whole day and night to test rigorously and develop with all the 'ilities' and then at the end of the day, they are paid pittance. This is happening in many organizations, some of which we assume to be awesome in tecnology.
2. I think the higher management in IT organizations need to stop calling the developers and architects as "resources". This sounds very "factory like" and is very de-motivating. Organizations will have to take a major step to prevent calling lower level heavy lifters as "resources". Call them "Consultants". Makes more sense too.
3. Most IT organizations contain an upper management of "blood suckers". If there was a way for employees to sit 24 hours a day for 7 days for the full year and pay them 10$ / hr, and the outcome of that would not result in the employee's death or any health hazards, these blood suckers will first push the button for that. They don't understand that apart from making money, there are certain responsibilites and values that they should have. Ironically, most of these companies have their slogan as "Respect for Human Values" or some shit like that, what a load of shit a$$.
I did not believe when my friend, an MIT grad on CS, decided to move to catering and became a chef. When I asked him why not IT dude, come on, people out there need you, this was his reply " 1. Work life balance. 2. High Job Satisfaction 3. No Recession (Duh. For food ??) 4. Excellent Renumeration (some chefs in star hotels earn 105000$/annum (without the 24 hours work, work on weekends etc.)
I could go on and on, but lets stop it here, all of us on Infoq know why people don't join IT, because ... ahem.. because of first hand experience ;-). -
Infoq,
Could you maintain the carriage returns when you add the posts to your persistent store? My carriage returns gets lost and see how ugly the above post looks like. I know there are some tricks to maintain the carriage returns, but how am I supposed to know that the first time I ever type something on Infoq?
Please add the functionality to maintain and reproduce the carriage returns for the posts.
Thanks. -
Spot on!
Furthermore, let us not forget that the Toyota model was never successfully applied to software, people claim to do it successfully well (We see organizations talk every day about lean and kaizen and a factory based process for developing software), I have yet to see a successful project that emphasizes a lot on lean and toyota and kaizen. :-(. The reason is every enterprise software, or software for any type of problem domain, is a new invention, no "process" or factory assembly line model can reasonably produce enterprise software. And we still have not reached the age where we can download modules off the web and integrate them with our application without a huge amount of research. Even then the modules fail in production, and well what do you know, since I did not write them, It is very very tough for me to debug and find out where the problem lies, whether it is in the module or the rest of the subsystems in my app. Due to this and a myriad other reasons, there are not much of "reusable components" for enterprise software at all. Of course we have frameworks which leverage a lot of the development, but apart from that, the core components of the domain model such as order management in a retail domain, there are no frameworks which can do it in a "plug and play" fashion, even for vendor frameworks such as ATG, Comergent, there is a lot of configuration, extension to etc etc and much much more complex than customizing mechanical parts in a toyota factory. Things like applying the toyota model to software were invented by people sitting at golf courses, without even interacting with the folks that were doing the heavy lifting at their desks.
I think Agile is a excellent process that claims to embody the spirit of software development that, there is nothing ceremonial about building software, Humans have their limitations of expressing in code, what they involuntarily do every day, and also it is difficult to test the entire state space of even a medium software application. Errors will occur in production, Compare this with a car produced at toyota :-). There should not be any errors in the ECU at all, and all cars adhere to this, the reason being:
1. the lifetime of an ECU is approximately 15 years, even though the brands of cars that the ECU may be installed in might differ
2. The functionality of an ECU is relatively small when compared to an enterprise application.
Hence developers have the time to test the ECU extensively, before launch and make sure that is atleast 7 sigma compliant.
Now, we can see how the Toyota model can only be applied to building cars and not building enterprise software.
We are now going back to dynamic languages and DSLs most of which have support for minimal static analysis, which will further put us back with regards to testing the entire state space of an application. Probably we need something like a Java ++++ in static analysis atleast, if not statically typed, to bring us closer to production ready code, faster and quicker.
The reason for the war for talent is to be frank, intelligent folks get turned off by venturing into the software world. Reasons being:
1. Some organisations emphasize Agile and Lean and develop complex enterprise apps with tight deadlines and very tough customers that frown when they see even a single error in production. Due to this, employees are forced to sit the whole day and night to test rigorously and develop with all the 'ilities' and then at the end of the day, they are paid pittance. This is happening in many organizations, some of which we assume to be awesome in tecnology.
2. I think the higher management in IT organizations need to stop calling the developers and architects as "resources". This sounds very "factory like" and is very de-motivating. Organizations will have to take a major step to prevent calling lower level heavy lifters as "resources". Call them "Consultants". Makes more sense too.
3. Most IT organizations contain an upper management of "blood suckers". If there was a way for employees to sit 24 hours a day for 7 days for the full year and pay them 10$ / hr, and the outcome of that would not result in the employee's death or any health hazards, these blood suckers will first push the button for that. They don't understand that apart from making money, there are certain responsibilites and values that they should have. Ironically, most of these companies have their slogan as "Respect for Human Values" or some shit like that, what a load of shit a$$.
I did not believe when my friend, an MIT grad on CS, decided to move to catering and became a chef. When I asked him why not IT dude, come on, people out there need you, this was his reply " 1. Work life balance. 2. High Job Satisfaction 3. No Recession (Duh. For food ??) 4. Excellent Renumeration (some chefs in star hotels earn 105000$/annum (without the 24 hours work, work on weekends etc.)
I could go on and on, but lets stop it here, all of us on Infoq know why people don't join IT, because ... ahem.. because of first hand experience ;-). -
Lean can certainly be applied to software development. Here's value stream map that I created to demonstrate the method:
mikebonar.blogspot.com/2008/01/last-year-i-crea...
Note the starburst indicating business users perform functional testing. -
Lean can certainly be applied to software development, for that reason, even the Toyota model can be applied to software development. Whether you produce successful software out of it, still remains to be seen. I have seen atleast 150 projects out of which 34 were done by Fortune 500s (not exaggerating), out of which 44 were lean, out of the 44, only 6 delivered value to the customer, and all of these 6 projects were paying high renumeration to the developers. Lean does not mean that your developers are motivated (if the salary is low). And no motivation for developers, means that there is something inherently bad in store for the project. Most organizations pay pittance to the software developers with low salary and expect to work on lean, which is not advisable. If you want models like lean to work, renumeration has to remarkably high.
-
Thanks, Christopher, and sorry for the ugly result. It's a known issue, but I've passed along your comment as well.
Note that an html < br > tag does work. Agreed, though: it's annoying.
deb -
I dont think it should be that much of a big deal anyways to add it. Sites like javaranch has it. :-).
-
It is a bit funny that number 2020 is used. I guess there is some plan behind that? Any links to the vision realization plan or pointers to the New Alliance? I'm a great believer in this vision, but in my opinion it requires attitude/processes/education revolution to happen soon to achieve the vision by 2020. My response here: plainoldstan.blogspot.com/2008/10/software-hous...
-
I totally agree, the IT departement is really important. It can't be seen as an obstacle to communication, but more as a way to make the other departments work together. I really liked the video and i think it brings great ideas, but i do have to agree with the last comment.
Mike Granger
www.chickenrecipes.net
10 comments
Watch Thread Reply