I’m not certain when agile was first used to describe software development, but over the last few years, it’s become the term of choice for so many in describing their environment and approach (though not always the actual methodology being utilized).
So what does Agile methodology really mean? Let’s start with a couple of very basic descriptions:
- Waterfall is rooted in having all requirements in advance, then going off and building to these very exact specs. There’s not a lot of opportunity for change, and when alterations to specs are needed, they can be costly both in terms of time and money. Never mind the fact that they don’t tend to allow for evolving or changing needs from the perspective of the user (who by the way typically has little or no voice once the build begins).
- Agile is about getting things started and teams producing quickly. It seeks to provide a more fluid or dynamic approach, allowing for the user to be highly involved in the software development process, and thus brings a highly adaptive development environment. Change is expected, and adaptation is not overly expensive because it’s inherently accounted for. The user is always highly involved throughout the development process – because the process never ends.
There are lots of good styles of Agile out there, including my personal favorite known as Kanban (internally we used to call it hyper agile), but they all generally adhere to the basic tenets of agile development. They value changes and adjustments, feedback, and discussion – especially with users. They make room for gut checks all along the way, making sure that the product is continuing to bring value for the user. Course corrections during development are part of the plan and necessary. Extending from the first set of delivered product functionality, the agile methodology is about bit by bit refinement and improvement through constant communication with the user.
There’s also an agile style that just pretends; it’s really waterfall in disguise.
In Agile, user stories are created to replace all of the upfront requirements of Waterfall. But, when user stories come with too many detailed criteria, are too far time-removed from creation and selection, or require too many internal and management or other approvals, and [important] don’t involve the user in the overall process, aren’t we really just describing Waterfall with some window dressing? In this style, teams tend to spend much of their time on predicting project durations and feature sets and writing specifications and technical documents instead of interacting with users. Despite the application of select agile features such time-boxed development iterations, or Scrum style management, this isn’t a particularly agile approach. It tends to run counter to true agile philosophy.
From the Agile Manifesto, we should value:
- Individuals and interactions over processes and tools;
- Working software over comprehensive documentation;
- Customer collaboration over contract negotiation;
- Responding to change over following a plan;
That is, while there is value in the items on the right, we value the [bold] items on the left more.
The impact to teams following this pseudo-Agile style can be significant because people are often out of sync, the voice of the customer is often not heard (or worse, heard and not acted upon). Think about a situation where a user story is created based on initial customer discussion, then implemented weeks or months later, only to find after release that the requirements were not well understood at the outset. User interaction throughout the process is critical and can help eliminate or minimize these types of scenarios.
So what style is your shop? If it’s an Agile impostor, then you might want to re-evaluate to make sure you’re really getting the benefits Agile has to offer, making sure that your teams (and your organization) are completely on board; being somewhat Agile isn’t really Agile at all.
Greg… Good points. Sometimes it is very hard for business leaders to wrap their heads around agile methodology since by nature business people usually look for defined dates and predictability (“predictable” = profit). Dev people, on the other hand, are less concerned with such things especially if their focus is on developing a quality product. The art is in learning how to work with these distinctions and instill confidence in the business leaders thus enabling them to comfortably embrace the inherent deadline ambiguity of agile. This process takes time and repeated success in producing good products… but is well worth it in the end for everyone concerned.
Hi Peter,I could be misinterpreting the inetnt of your post but it feels to me that most startup business are already practicing agile techniques possibly without even knowing it. If they aren’t they likely won’t be in business long. For example we are a software and services startup – we use agile to develop our software, but I would argue that our entire business is being evolved the same way – iterative development. We reassess market conditions constantly, look at strategy quarterly, experiment with new pricing models, new services etc etc.We are now actually even trying to take some concrete concepts from agile software development and deploy them across the business (of course we are adapting them accordingly). for example – we are now taking the concept of a morning scrum/morning stand-up and moving that to every functional area of the business. Of course some of the details don’t carry over well from development to other groups, however the core tenants of rapid communication, shared commitments and self organization apply to all.In the end – Agile is a mindset not a process or method. many forget that.Cheers,Kevintwitter: kevnd
To implement agile meooodhltgy when outsourcing software development you need to follow a specific procedure. We maintain a website that offers similar service. In agile development the entire project is broken down into a number of iterations. For each iteration, that typically lasts for not more than three weeks, the complete development process (i.e. planning, designing, coding and testing) is followed thereby minimizing the risk. On completion of each iteration, the software is released to the customer. The feedback received from the customer is then incorporated in the software.Please visit the above site to get answer to your problem.