Recently, I was entertained by hearing complaints from a friend regarding their Agile practice and how impractical and inefficient it seemed. This conversation led me to think about our own agile practices at Phurnace and other companies for which I’ve worked. It is my experience, since the Agile boom, companies tend to adopt a hybrid approach that is typically a collection of agile practices mashed up with traditional practices from which people feel comfortable. I reviewed some of the basic principles of Agile software development and found several common pitfalls.
Individuals and interactions over processes and tools
Agile projects are geared to expect change. Agile practices expect that management, sales, and product leadership frequently change project requirements. Recognizing this as a reality rather than denying it leads to a more honest and accurate approach for your organization. Thus, agile projects must explicitly abandon traditional planning in favor of direct interaction with individuals. With a clear focus on high value features and releasing valuable software often, a software team can adapt to frequent changes yet consistently deliver additional product "value”.
Traditional team management use tools such as Microsoft Project to breakdown work items that look into the project's future. Resources are allocated, dependencies are tracked, and tasks are mapped to individuals. This plan is traditionally managed by identifying the "critical path" for final delivery. Any change or diversion from the plan forces the plan to be re-worked. If the project has little variance, this approach is effective. However, most software projects change often resulting in making the project plan irrelevant.
One pitfall is that most hybrid approaches continue to use traditional tools to chart out a project plan which only confuses the leadership. These estimates are put into a Microsoft Project chart to determine which stories are feasible for the next iteration. This piece of planning, even on a smaller scale, is often out of touch with reality. The reason lies behind the estimates. A spreadsheet or Gant chart of numbers fails to communicate many of the inferences and risks that would otherwise be learned by direct interaction with the team members or the lead. In essence, given a 3-4 week timeframe, relying on your team's depth of knowledge and experience thru personal interaction is a better measure for the feasibility of tasks.
The second pitfall with this theorem is around processes. Adding unnecessary processes under the name of “Agile” is, in my experience, the most abused part of the practice. For instance, daily or frequent standup meetings are very effective for encouraging frequent collaboration and communication between your team members. However, if the traditional “weekly development meeting” is simply expanded to a “daily development meeting”, it only achieves 5 times more wasted time.
Working software over comprehensive documentation
The most important thing in a software organization is consistently creating software that provides value. Frequent collaboration with your collegagues often replaces the need for short-lived documentation. Rarely, does an internal design document or test plan add value to a product suite; while actual development or test execution can produce another valuable release.
The pitfall often found in a hybrid approach is not usually around typical documentation such as test plans for design documents. Instead, organizations adopt traditional practices such as weekly status reports and require so-called-Agile “daily” status reports. Daily status reports are just another form of comprehensive documentation leaving less time for working on software!
I am sure many people experience issues with Agile development while also seeing huge improvements over the traditional practices. I am very interested in hearing any feedback or opinions. In a follow-up blog, I plan to address the other two theorems:
Customer collaboration over contract negotiation
Responding to change over following the plan
In Agile Software Development
Comment (0)
Read More...
I recently read on 
Apple's iPhone represents a revolutionary mobile platform that has attracted people of all sorts to download the SDK and take a look. Today, it seems I search the internet for "iPhone" related information only to find hundreds of rants. Most rants are either about the lack of Flash and/or Java support for the iPhone. Perhaps this is because the world is full of developers who know Java or Flash, but not Objective C?