| Agile – changing the rules of the game! |
Last week, we touched upon the changing rules that Technology VCs
are adopting and how that is changing the face of new product development.
This week, our focus is on how Agile is changing the rules of software
development.
When Agile first started making an appearance, it was viewed as
yet another development fad. But with Agile showing dramatic
improvements in delivery time, quality of software and a reduced
number of strategic mistakes compared to the waterfall
model, it has taken a broader role in software development today.
A number of companies practice Agile as a product development methodology
from project inception to delivery, support and end-of-life phases.
However, Agile is not about using Scrum, Extreme Programming or
RUP. It’s about using the best agile practices to respond
to today’s frequently changing business needs. Using the waterfall
model, frequent changes to software is difficult - the development
cycle is long, systems are over engineered and end up costing a
fortune.
Agile as an alternate development methodology evolved from
the need for dynamic systems that can rapidly adapt to change.
One basic tenet of Agile – simplicity – comes out of
this need. Build the simplest possible system that satisfies today’s
requirements and when tomorrow comes, be ready to adapt.
Agile is not fool-proof though. It is still evolving and there
are some situations where it may not be applicable. The trick is
to find out the right mix of techniques from Waterfall, Agile and
other development methods that suit your particular product development
needs, adapt those techniques and implement them!
Featured articles
10
things to know about agile
Software
architecture challenges and significance in an agile world
The
Agile Roadmap
Applying
Usability to the Software Development Process
Agile
progress report
Well-formed
teams and Agile: An opportunity to thrive
Jump-starting
agile projects
|
| Upcoming
Teleconferences |
“Why
are great products so rare? What does it take to build one?”
April 30, 2008
|
| Recent
Post |
Are
you facing difficulties in justifying tools investment?
The IT department in my organization gets several requests to
purchase or develop tools from different functional teams. Typically,
there are requests to buy tools for code reviews, RAD, issue
tracking, packaging, etc.
Earlier, we used to treat these tool requests as stand-alone
requests and decide on it based on the usefulness of the tool,
cost, priority/need to buy the product and other factors.
But today, when we get a tool request, we ask a few fundamental
questions right at the start:
- How is the tool going to change your work life?
- How will your productivity be affected – will your
work output increase or be faster?
- How will the quality of the output improve?
|
|
