New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
A Growing IT-Business Gap: Agile to the Rescue?
Posted by Amr Elssamadisy on Jul 10, 2007
A recent survey indicated that the gap between IT and Business is growing and that might signal a change in how enterprise technology is run. There are increasing reports of IT not meeting business needs. Does Agile address these issues - and if so where is the evidence?
itWorldCanada reported on a survey that there is a need for better communication and understanding between IT and Business:
...the future of the IT professional no longer lies in acting as an important support system or innovative visionary but as a “utility.” According to him [Michael O’Neil, Info-Tech Research Group research fellow and author of the survey] , as technology becomes more and more an integral part of the enterprise, the role where IT functions as a discrete, advisory body will disappear; those left behind, he said, will be the “bits and bytes types” who want to work with the nitty-gritty of IT (such as network admins or coders), while the majority of IT professionals are assimilated into areas pertaining to business processes and strategy.
This was inline with an article provocatively named Fire Your CIO? If he's not implementing strategy, show him the door. :
The “new CIO” needs to be both an executor and a strategist. He or she should understand business processes first, and the latest technologies second. By working with the CEO and other key executives, this CIO should quickly ascertain the key strategic priorities that the organization must tackle. The “new CIO” will then translate these strategic imperatives into a technology plan that rigorously focuses on return on investment, and on streamlining the business rather than implementing a particular system.
So - what does this have to do with Agile? There is a definite focus on the Customer and Business Value - at least in the rhetoric. But does Agile deliver when it comes to strategic priorities? As far as we can tell, it really depends on what you read.
The most common recommendations when it comes to Agile processes and practices are inward looking and at project level. The vanilla Agile methods are focused on project success and look to satisfy the customer that is part of the team. There are many inspect-and-adapt cycles, but they focus on project status and progress. Daily stand-up meetings, iteration demos and reviews, and retrospectives are all inward-facing practices and do not take external business value explicitly into consideration beyond having a Customer or Product Owner.
There are, however, some in the field who recommend looking at external business value - that is, what software projects have to offer to the business. In last week's Agile Measurement - A Missing Practice? we reported on different strengths and weaknesses of Agile methods concerning measurement. In Appropriate Agile Measurement: Using Metrics and Diagnostics to Deliver Business Value, we were told what makes a good measurement candidate. The paper was silent on whether these were outward facing metrics or inward. One of our readers commented:
I've been at this business just shy of 30 years and have yet to see a formal, published study any time after project completion to say the ROI that we projected was met or not. Is that the kind of measurement people are after? Anybody here do such studies regularly?
Also, series of articles have been written about how to incorporate and measure an organization's business value when considering Agile development in the Agile Journal December 2006, January 2007, and March 2007 issues. These articles vary from asking and answering "how do you know an Agile Project has succeeded?" to suggestions on aligning day-to-day activities with business imperatives, to bringing Lean, Agile, and Theory of Constraints together to target your particular environment's business needs. Liz Barnett wrote:
How do you know if an Agile project has succeeded? The typical response I get to that question is a blank stare or moment of silence, depending on whether the meeting is in person or by phone. And if I do get an answer, it's usually accompanied by a "we're just starting" comment. The challenge is twofold: development organizations are notoriously weak in collecting metrics and reporting on their projects and, when using Agile processes, many teams are challenged to demonstrate if the change from traditional approaches was worth it. As IT costs and business pressures escalate, it is critical that a development shop can demonstrate its value to the business.So - are we there yet? Probably not, but we are moving in the right direction. The questions are - does this solve the problems raised in IT organizations and the growing gap? Do these IT departments know about Agile development? Or have they tried it and failed to find the successes reported above? Is there more that the Agile community should be doing to explicitly address these issues?
- 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
RelatedVendorContent
18 agile and lean practices for effective software development governance
A Guide to Branching and Merging Patterns
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!
Stop it!
by
totoro totoro
Posted
Re: Stop it!
by
Dave Rooney
Posted
Re: Stop it!
by
Floyd Marinescu
Posted
Business understanding, not agile, is what is needed
by
Dean Schulze
Posted
Re: Business understanding, not agile, is what is needed
by
Marco Abis
Posted
Re: Business understanding, not agile, is what is needed
by
Dean Schulze
Posted
Re: Business understanding, not agile, is what is needed
by
Marco Abis
Posted
Re: Business understanding, not agile, is what is needed
by
Marco Abis
Posted
Re: Business understanding, not agile, is what is needed
by
Dean Schulze
Posted
Re: Business understanding, not agile, is what is needed
by
Marco Abis
Posted
Re: Business understanding, not agile, is what is needed
by
Chris Matts
Posted
Re: Business understanding, not agile, is what is needed
by
Les Oliver
Posted
Re: Business understanding, not agile, is what is needed
by
Dave Rooney
Posted
Agile or not, connect your business and IT people
by
James Taylor
Posted
why business value should be different?
by
suba bose
Posted
Re: Agile or not, connect your business and IT people
by
Arnaud Blandin
Posted
Re: Agile or not, connect your business and IT people
by
Arnaud Blandin
Posted
Agile and Business
by
Chris Matts
Posted
Another study on the disconnect between IT and business strategy
by
Dean Schulze
Posted
IT as strategy execution
by
Dean Schulze
Posted
Some Assertions
by
Amr Elssamadisy
Posted
Re: Some Assertions
by
Deborah Hartmann
Posted
-
Please stop this Agile nonsense!
-
Why?
-
If you buy what is posted above, then what it needed is an understanding of your companies business needs and strategy. Agile doesn't recognize that. The Agile Manifesto and Declaration of Interdependence don't mention strategy, alignment, or business analysis. Once you understand how software can help your company reach its strategic goals then you can talk about how best to implement it. That's where agile may come into the picture. Agile is more at the tactical level than at the strategic level.
Offering Agile in response to the above is like telling someone who is trying to decide whether to buy from Boeing or AirBus about the virtues of hybrid cars. You're talking about different domains.
The quotes above indicate to me that software engineers need to become better business analysts, not necessarily Scrum masters. While agile and business analysis skills are not antithetical to each other, the idea of programmers needing to improve their understanding of business is not going to appeal to XPers. -
Agile or not you need to get your IT folks and your business people to collaborate to develop and update systems. Rule engines offer a way to do this and are something you can use with agile methods too.
JT
www.edmblog.com -
Totoro, firstly would you please have the courtesy to use your real name? Second, you can stop agile right now, just uncheck the checkbox next to agile on the left side of this website and you won't see anymore Agile content.
thanks,
Floyd -
Whatever the development methodology, agile to waterfall, why should the criteria for project success be any different? It can be delivering software per prescribed quality within scope and budget; or for that matter whatever quantified business value the project was supposed to meet.
-
While I undertand what you mean I think one, if not the biggest, benefit of Agile IMHO is exactly that: a sort of Business Awareness. Sorry to link a post of mine but I wrote about this some time ago: www.mythodology.com/technicality-business-aware...
-
Dean, I would agree that Agile doesn't specifically recognize alignment with the business. That's mainly because Agile was intended from the start to solve the very tactical problems of building good software within a reasonable amount of time.
Having said that, though, once that problem was identified and practices put in place to ameliorate it, becoming more involved with the business falls into place naturally. I've worked with teams using Industrial Logic's Industrial XP, which has specific practices such as Chartering to deal with the business side of the equation. These were added to XP specifically to expand the code-centric tactical focus to a more strategic focus.While agile and business analysis skills are not antithetical to each other, the idea of programmers needing to improve their understanding of business is not going to appeal to XPers.
Not at all... I'm a programmer and XPer, and I have always tried to learn as much about the business in order to be able to build the best possible software. I know quite a few other people who would tell you the same thing.
There are also business people who strive to learn enough about the technical aspects of software development so that they understand what's going on and can make informed decisions. There are also business people who don't care about the technical aspects. IMO, the best situation is when you have developers who learn a bit about the business and business people who learn a bit about the technology. After all, it takes both good developers and good business people to make a project successful.
Dave Rooney
Mayford Technologies -
Marco,
I like the phrase "Business Accumen" in the post you link to above, but unfortunately business accumen is not one of the Agile values. Your post illustrates the point, however, that agile means just about anything to just about anyone. If there's a problem in IT then agile must be the answer because we can re-define agile to be whatever fits the current discussion. The word "agile" is becoming meaningless.
Try telling a bunch of XPers that they need to get their heads up, out of the code and become better business analysts. Stop refactoring your code and spend lots more time with subject matter experts. Create real documents that get reviewed, modified, and then put into document control for the benefit on non-technical people instead of 3 x 5 cards that get thrown away. Spend lots more time in meetings so you understand your companies strategy.
Just a guess, but they'll probably call that BDUF and say it isn't agile. -
I also saw this today:
The Society for Information Management, a professional group, recently published a report that suggested that perhaps half of the chief information officers in the U.S. aren’t as good as they should be, often because they lack business acumen, ...
blogs.wsj.com/informedreader/2007/07/09/the-it-...
When your CIO lacks business accumen then agile is not the answer. Offering agile as the answer to this endemic problem is pretty lame. -
Hi Dean,
read any _serious_ book about Agile, article, discussion forum with real practitioner and so forth and you will find people talking about "delivering beusiness value".
Most (as in 99%) of the people I know who are in the business and know and try to do Domain Driven Design are Agilist.
About the "XPers": go and search for it on the official mailing list (if you manage to make yahoo groups search functionality work ;-D). Whoever define herself a "XPer" and doesn't do is not an "XPer", is just someone who is trying to do what he is used to covering it with a new buzzword. A central idea of XP and Agile is poly-skilled people who can wear many different hats when needed. This is an essential part of the approach since the very beginning.
I would separate though the "work with subject matter experts" from "create real document instead of 3x5 cards". It depends on the reasons why you need that documents and the intended audience: more often than not cards are enough, sometimes you need cards with more details (and lots of people use a wiki for that but it doesn't really matter).The same is valid for "spending lots more time in meetings". -
Sorry, I forgot :-)
I like the phrase "Business Accumen" in the post you link to above, but unfortunately business accumen is not one of the Agile values.
From "Principles behind the Agile Manifesto":
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
and
"Business people and developers must work together daily throughout the project."
agilemanifesto.org/principles.html -
From "Principles behind the Agile Manifesto":
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
and
"Business people and developers must work together daily throughout the project."
agilemanifesto.org/principles.html
That says nothing about understanding and executing your companies strategy. If all you focus on is delivering software then you're not understanding what this thread is about. -
Two things have become clear to me so far in this thread:
The premise for this thread is that Agile can address the disconnect between business and IT, but that premise has never been demonstrated. Why is agile better at this than waterfall or code-and-fix?
There is a significant difference between working with business people to deliver "valuable software" and executing your companies strategy through IT, but almost no one recognizes this. How many people here even know what their companies marketing or financial strategies are?
Pointing to a sentence or two in the rational for agile principles about working with business people on a regular basis shows how far our work is from executing strategy. The agile principles don't even mention understanding strategy, let alone executing it. -
I was adressing your "Agile/XP people don't want to do business analysis and spend time with subject matter experts, they just want to cut code head down" :-)
-
assertTrue: Business Strategy is not addressed by Agile anymore than other development methods
assertTrue: Agile - in its vanilla flavor - only addresses project issues, and does focus on the business in terms of the value its software delivers. This is more than done with traditional methods.
assertTrue: Agile has been evolving in many directions. One of them is aligning with business value at the corporate level. (notice I did not say business strategy)
assertFalse: Business Value = Corporate Strategy
assertTrue: Business Value is highly correlated to Corporate Strategy
assertTrue: IT and Business Strategy alignment IS a problem that needs to be solved independent of methodology.
Do these tests pass?
Amr -
I agree with James, it is important to connect the business and IT folks.
In my experience one very useful way to get those guys work together is through the use of a same language: BPMN.
BPMN represents a process that can be both understood by business and IT.
True BPMS like Intalio|BPMS really help processes to be implemented the way business wanted them to.
On various BPM implementation projects, we used a methodology derived from -
The Agile Community has moved on since the original manifesto. I now regard it as a historical document. The process required to update it would probably be a right pain to agree.
Those of us in the Agile BA community have been moving to address the business / IT disconnect.
A few years ago Andy and I wrote an article where we stated "A project generates business value when it increases or protects revenue or reduces costs in allignment with the strategy of the organisation."
Kent McDonald has just written an excellent article "A Business Value Focus for Portfolio Management" www.cutter.com/offers/portfolio.html . Kent is Agile and a member of APLN which means it can be regarded as Agile. Funnily enough, the word Agile does not appear in the abstract.
To be clear:
Agile <> XP + Scrum
Agile >= XP + Scrum + Lean + DSDM + TOC + Evo + BDD + ... (Flavour of Month)<> -
I just realised that people seem to be saying Agile is not doing stuff related to business value and strategy. If you are interested I can dig out some of the older material on this. There are a number of people looking at this area (not as many as TDD though ;-) )
At the moment, a couple of my top interests are...
1. Real Options (which are all about business value and then some)
2. How we get the accounting standards (FASB, ISA) changed so that companies can invest in IT in a sensible way. This is what the lean manufacturing world had to do. -
The Agile Community has moved on since the original manifesto. I now regard it as a historical document. The process required to update it would probably be a right pain to agree.
Those of us in the Agile BA community have been moving to address the business / IT disconnect.
Wow! I agree with Chris =0) -
> Business Strategy is not addressed by Agile anymore than other development methods
Hmm. True enough. However, agility's emphasis on transparency should inform strategy, and the lack of requirements and design "inventory" should reduce losses incurred by rapid changes in strategy.
22 comments
Watch Thread Reply