This meshes with my experience and travels to hundreds of companies. There's no clear-cut winner right now. Which method is used depends upon who's in the company. The move to agile often starts with developer, and then there's the rare company where it starts higher up.
Another barrier to agile adoption is that a lot of companies still find it difficult to get business people to participate at a level that's optimal. It's hard to break the mold or the habits that have grown in these types of companies. How does the divide between the software development and the business sides impact product quality?
My pet peeve is the lack of our ability to tie development effort to business, to tie quality to profit/loss, to treat software as an asset -- or not. It's easy from a high-level point of view to only look at the application, the amount of money it's made since deployment.
Companies are used to hardware-oriented IT where you get a bigger server and you can quantify it with some kind of metric. It's more difficult to quantify new features, to quantify that this change in the software cost this much to create and then made us this much after deployment.
Ideally, what I consider development is that the users ask for the features and just tell them how much it's going to cost. Then, they need to understand the business impact of getting
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
those features. For us it's no skin off our backs to make feature X or feature Y. What's iffy is if the business leaders are smart enough to make the business call once we explain that feature X costs 10 bucks and makes you $100 and feature Y costs $100 and only makes you $10. In your writing and presentations, you've said that agile requires highly skilled teams. Why is that?
|  | ||||||||||||||||
| |||||||||||||||||
I feel that the savvy business folks understand that a skilled handful of IT far outweigh the masses of unskilled labor. But there are plenty of companies that do not treat software like it is a capital asset.
It's hard to imagine that something the company relies on for paying salaries and so many other critical processes isn't considered a capital asset. Could you image a car manufacturer not caring about what goes into building the car?
It's hard for lay people to understand what software is and why they should treat it as a tangible item. It's a poor job of trying to link business values to the efforts around building software. You've suggested that gathering too many requirements might be counterproductive. Others have told me that many projects don't gather enough requirements. Could you explain some key points of your approach?
The key is to understand which requirements are critical to shaping the architecture and can greatly affect the project, and which ones are "cheap" and do not matter that much. The former are often short-changed in projects because either the team is naive, or because these are "harder" to get right. The latter are often littered all over the place because they are easy to come up with and people think it is "progress" to have "more." The concept of working on quality and testing from the get-go in projects seems logical, yet I still hear about QA and testing being done at the end of the process. Do you see the former approach being adopted more? Why might there be resistance?
TDD (test-driven development) and quality at every step is still a big challenge. Mostly, I think, due to inertia that teams haven't done it that way very much. There is a false lust for features at the expense of quality and tests. I could go on.
Some people like and some don't like or understand the value of test-driven development. I'm constantly struggling to get the team I'm working with now to write more tests. Rather than write a test when a bug is found, they'd rather jump in after the fact and fix the bug. We found a bug. We wrote a test. Now we know with some level of confidence that that bug won't ever appear without a test in front of it. Let's save money now and not worry about the future. It's a funny scheme of things.
Join the conversationComment
Share
Comments
Results
Contribute to the conversation