Idea’s Around Agile Development

“In the confrontation between the stream and the rock, the stream always wins, not through strength, but through flexibility.” – Buddha

We’ve been bouncing around ideas recently regarding our processes and how to deal with contract negotiations while still remaining agile, not sounding ambiguous in our language with the client and still protecting ourselves from future technology changes in an un-standardized market. Here’s a great read that I found online regarding agile development titled “Agile Processes by Robert C. Martin”. The document offers potential solutions for Mercatus to leverage in the future.

The points I really found useful in each section were as follows:

• Individuals and interactions over processes and tools.
  • People 1st.
  • Let the team configure the development environment based on need.
  • A good team isn’t necessarily the one with the players that have the most skills but the one with the players who gel well and work together.

• Working software over comprehensive documentation.
  • No documentation is bad, too much documentation is worse as the documents take a lot of time to produce and then even more time to keep in sync with the pace of the project and usually turn into sources of misdirection.
  • Create and maintain a short rationale & structure document that the team produces then keeps in sync from month to month. When a new member joins the team they work closely together to transfer knowledge in an interactive manner.
  • Produce no document unless its need is immediate and significant.

• Customer collaboration over contract negotiation.
  • Software cannot be ordered like a commodity this leads to poor quality and project failure.
  • Successful projects involve customer feedback on a regular and frequent basis, rather than depending upon a contract or a SOW. Reference Contract Example Below.

• Responding to change over following a plan.
  • When we build plans, we need to make sure that our plans are flexible and ready to adapt to changes in the business and technology.
  • A better planning strategy is to make detailed plans for the next few weeks, very rough plans for the next few months, and extremely crude plans beyond that.

Contract Example:

The author negotiated a contract for a large, multi-year, half-million-line, project. The development contract was paid out a relatively low monthly rate with large payouts when they delivered certain large blocks of functionality. Those blocks were not specified in detail by the contract. Rather the contract stated that the payout would be made for a block when the block passed the customer’s acceptance test. The details of those acceptance tests were not specified in the contract. During the course of the project the team worked very closely with the customer and released the software almost every Friday. By Monday or Tuesday of the following week the customer would have a list of changes for the team to make to the software. The team would prioritize those changes together, and schedule them into subsequent weeks. The customer worked so closely with the team that acceptance tests were never an issue. The customer knew when a block of functionality satisfied his needs because he watched it evolve from week to week.

The requirements for this project were in a constant state of flux. Major changes were not uncommon. There were whole blocks of functionality that were removed, and others that were inserted. And yet the contract, and the project, survived and succeeded. The key to this success was the intense collaboration with the customer; and a contract that governed that collaboration rather than trying to specify the details of scope and schedule for a fixed cost.

“If you learn only methods, you’ll be tied to your methods, but if you learn principles you can devise your own methods.” – Ralph Waldo Emerson

The Principles to developing great software:

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
• Business people and developers must work together daily throughout the project.
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working software is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity, the art of maximizing the amount of work not done, is essential.
• The best architectures, requirements, and designs emerge from self-organizing teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

What are your thoughts around agile development?