-
0
0
On February 11-13, 2001, at The Lodge at Snowbird ski resort, overlooking the Wasatch mountains of Utah, seventeen independent thinkers, self-described as “The Agile Alliance,” met to talk, ski, relax, and try to find common ground.
Representatives included those with backgrounds in #ExtremeProgramming, #Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation heavy software development processes.
What emerged was the Agile ‘Software Development’ Manifesto, a set of values (seen in this image) and the “12 principles of Agile Software”.
While I have written several articles discussing each of the principles in detail and examining their validity in today’s world, the intent of this article is to discuss a common fallacy around these values. I will soon follow this article with short discussions of each of the values while providing you with some potential practices you could adopt that support an agile mindset and could improve your organizations overall success.
The Values of AgileManifesto.org
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to 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 items on the left more.
A Common Fallacy
The most common fallacy many coaches have heard is the utter disregard that “there is value in the items on the right” above. It is important to understand that agile does not ignore process, tooling, documentation, contracting, or planning, instead embraces these things. What it does, however, is place greater emphasis on the realization that these things are only a small part of what is needed to be successful. The ability to interact and collaborate amongst us and with our customers will enable us to respond to changing environments and ultimately deliver better functioning products and more value quicker to our end users.
While “the items on the right” will change within a truly agile environment, they do not fully disappear, nor should they. We will need processes to follow for our teams and organizations to more efficiently track the work we are doing, while ensuring every team member completes things in a way that doesn’t jeopardize compliance with varying rules and laws, among other things. We need tools to help us track and measure our individual, team, and organizational effectiveness, to inform us as we retrospect our sprints, and to continuously gauge our improvements and their implementation success.
Documentation is important and often falls to the waste side as several agile teams forget to include it in their policies (definitions of done). It may end up falling to a downstream team as part of an organization’s project management or SDLC practices. This is fine, and each organization needs to determine what’s best, but we should ask ourselves if documentation is best done iteratively or as a gated phase near the end of all development efforts? In either case, we must realize that we should be spending far more time creating working products than we should be documenting how those products are supposed to work.
Speaking of documentation, contracting should be considerably different in an agile environment. While I’ll discuss agile contracting in a later article, the need for a contract which is flexible, and fair, is extremely important and shouldn’t take months to establish. We will always need to negotiate contracts with our customers, end users and vendors alike. We should write them in a way that allows for flexibility to shift in an ever-changing environment. Involving our customers early and often throughout the process rather than looking to haggle with them and understand and fix every requirement up front is of dire importance. The days of hardened, fixed contracts should be far behind us, but there will always be a place for negotiation with those with whom we are doing business.
Lastly, agile doesn’t do away with planning, it embraces it. However, what it does do is attempt to embed some flexibility into the plan by breaking work down into smaller chunks, gaining feedback on that work, and then adjusting quickly based on that feedback. We still need to understand our team’s capacity and steer our planning in a sustainable way, but we need to build in some buffer as the principles and values we are following guide us to building better products that are continuously adjusted to meet our customers changing needs over time. We plan iteratively, and in a scaled setting incrementally, to ensure we are meeting the needs of our customers with the highest value products based on their feedback. We embrace flipping project management constraints on their head and fixing time and budget while remaining agile in what scope is accomplished and how. As anyone who has served in the Armed Forces can attest, a plan is only good until first contact; this remains true in waterfall and is embraced in agile.
In short, we need to continue to embrace the items on the right and realize the value they bring to our organizational health. While agile encourages us to embody those things on the left a bit more, the overall intent is to shift us back to a more customer and quality focused mindset where everyone is happier while maintaining some of the organization that has allowed us to scale our businesses over time, remain compliant, and successfully grow.
