Page 73 - DCAP405_SOFTWARE_ENGINEERING

Software Engineering

Notes anticipation (Postrel 1998). Does that mean no one in Boston ever responds to change and no one
in Silicon Valley ever plans? It’s not so much either/or as it is a fundamental, underlying
philosophy within which situations are juggled accordingly.
Being Agile means trusting in one’s ability to respond more than trusting in one’s ability to
plan. Good explorers both anticipate when the rules of the game have changed (or are about to
change)—that is, they define the context—and can also operate flexibly within a given rule set.
Obviously, if the rule set itself is too prescriptive, it leaves no room for agility. Without some
rule set, however, agility can become rudderless reaction.

Self Assessment

Fill in the blanks:
1. Agility isn’t a one-shot deal that can be checked off the organizational ……………………..
list.
2. Agility is a way of life, a constantly emerging and changing response to ……………………
turbulence.

3. Agile projects are not controlled by ……………………………. to plan but by conformance
to business value.

5.2 Agile Process Model

Computer science is a young science. Computer programmers my age were trained by engineers.
That training dictated how we approached software development for an entire generation. But
now after decades of building software to be expensive, unwanted, and unreliable we have
come to realize software is different. Building software is more like creating a work of art, it
requires creativity in design and ample craftsmanship to complete. Software remains malleable,
often illogical, and incomplete forever. Agile software development is based on fundamental
changes to what we considered essential to software development ten years ago.
The most important thing to know about Agile methods or processes is that there is no such
thing. There are only Agile teams. The processes we describe as Agile are environments for a
team to learn how to be Agile.
We realize the way a team works together is far more important than any process. While a new
process can easily improve team productivity by a fraction, enabling your team to work effectively
as a cohesive unit can improve productivity by several times. Of course to be eligible for such a
big improvement you must be working at a fraction of your potential now. Unfortunately, it
isn’t that uncommon.
The most brilliant programmers alive working competitively in an ego-rich environment can’t
get as much done as ordinary programmers working cooperatively as a self disciplined and self-
organizing team. You need a process where team empowerment and collaboration thrive to
reach your full potential.
The second change is making the customer, the one who funds the software development, a
valuable and essential team member. When the dead line gets close a traditional approach to
reducing scope is to let the developers decide what will work properly and what won’t. Instead
let the customer make scope decisions a little at a time throughout the project.
When your customer, or domain expert works directly with the development team everyone
learns something new about the problem. True domain expertise and experience is essential to
finding a simple, elegant, correct solution. A document can have plenty of information, but real

66 LOVELY PROFESSIONAL UNIVERSITY