What the Agile Manifesto Looks Like When Implemented, Part II

Continued from Part I

If you have already looked at Part I of this soliloquy, we've traversed the primary idea of the Agile Manifesto which suggests that the journey of software development and delivery is
...constantly and purposefully evolutionary through teaming, pairing, mentoring and teaching by example - with no end in sight; in other words, we're never done and we're always changing and improving.
Let's take a look at the remainder components of the Manifesto and further explore what the Agile Manifesto looks like when implemented in your work enviroment.

Manifesto for Agile Software Development

"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 items on the left more."

Let's look at the next five elements of the Manifesto.

"Individuals and interactions over processes and tools."

Constant, collaborative, communicative interaction between team members is the goal. If you notice, this happens naturally every day in the line at the cafe, near the water cooler, in the parking lot, and before and after meetings. Most people are naturally social. This particular aspect of the Manifesto simply suggests that there is value in having a process and having a tool. However, there is more value in having people talk, develop relationships, be real, trust each other, and describe, postulate and solve problems by conversation and interaction. This is a very easy facet to see and understand in our work environments.

One symptom of imbalance is if people spend the majority of their time updating a tool, auditing against a process, discussing templates, or calling high-ceremony, high-attendence meetings ... the focus is most likely on things that help us serve customers, not customers, customer problems or team mates.

Any bloke that works for a living will tell you that having the right tools will make the job easier; however, having the right tools does not a good deliverable make. You could give me all of the best, most expensive and high quality tools that exist to make a sidewalk ... though I haven't the faintest idea what to do with them. Liken this to chaps who spend exorbitant amounts of money on golf clubs, associated clothes and shoes to look crisp and impressive on the course, but haven't a clue regarding effective golfing. The tools may be helpful in the long-run, but are clearly not the priority as being a master craftsman precedes the value of master quality tools.

To serve a customer, create a relationship with a customer and get to know them, their environment and their problems by spending time with them, talking, and generally just being around. To lead a team and be part of a team, create a relationship with each individual, be around, talk and discuss things on and off-topic. What we always find is that the problems customers tell us to solve are usually different than the solutions they actually seek. If our focus is on the relationship, the true problem will reveal itself through time. If we focus on populating the tool, using the process, or delivering a template, we'll most often receive that for which we asked.

According to Jim Highsmith at the Agile 2007 conference, the average requirements document is approximately 17% complete, and usually around 8% correct. This suggests a number of things:

  • Customers may not always know what they want until they see what they don't want;
  • Trying to get all requirements defined up front is a waste of money and time; and
  • If the average requirements document is around 8% accurate, perhaps we should spend more time exploring problems and solutions directly with the customer and less time populating a document or tool.

"Working software over comprehensive documentation"

The previous conversation leads right into this one quite obviously. If we know that the average requirements document is around 8% accurate and that customers do not truly know what they want until they see what the don't want, then perhaps we need to deliver something right now so that we can get this process of discovery going at a quick clip. In other words, rather than taking weeks and months to create documentation about things the customer believes they want, take two weeks and deliver working, tested software that the customer can see, feel, touch and interact with in order to glean a reaction and potential project redirection. So the manifesto clearly suggests there is value in some documentation; however there is more value placed on working software that a customer can react to and modify, than a document.

What this looks like in a healthy environment? As a quick example, if you were to spend three hour with a customer helping them articulate their problems and business needs, and then have them prioritize the list from 1 to N ... you're already on the path of adding immediate value through working softwre and a working relationship. Then, if you were to evaluate and take the top one off the list that appears to offer the most business value and is technically acheivable (managed risk) in a short period of time - deliver it in two weeks. In two weeks you will have helped a customer think through their top problems and needs and have shown them working software from which they will recalibrate themselves for the next sprint.

If you were given the choice of the aforementioned experience, or waiting three months for a document that discusses a solution - which one would you choose?

"Customer collaboration over contract negotiation"

If serving a customer requires a partnership - nay, dare I say relationship - then spending time with a customer, talking and solving problems is the goal behavior. Ordinarily when we collaborate with someone, we're working hand-in-hand to think, talk, evolve, postulate, prove, disprove, and otherwise journey together from a mutual starting point. What this often looks like in collaborative relationships is two people standing shoulder to shoulder at a marker board drawing ideas, debating pros and cons, and otherwise sharing in peer level discourse. This type of relationship may grow through multiple meetings over tea, multiple phone conversations, or a constant exchange of ideas via marker boards, napkins or windows...sometimes planned, sometimes spontaneous. Whether walking the park, sitting beside each other or going video, the collaborative relationship is seemingly omnipresent, unbroken, and continual.

Inversely, many people seem to substitute a hierarchy of detailed contracts as having more value than forging a relationship between customer and vendor. Some people choose to craft a contract of conditions, constraints, assumptions, risks, issues, hard dates, hard deliverables, hard costs, and service level agreements as if everything is known on day one with surety. Having a contract is of course legal and likely wise in most cases; however, when the contract defines the relationship to such an extent it nearly represents an anti-relationship, we're killing collaboration through documentation. Couple this with Highsmith's earlier data suggesting 17% of requirements documents are actually complete, and 8% of these are actually correct ... by opting for a detailed contract over collaborative evolution with the customer we gamble that we're capable of being a part of the 8% at the point we sign a contract and we're spending our time and money on the wrong activities - which is to deliver working, tested software in as short a period as two weeks.

"Responding to change over following a plan"

People are interesting creatures. If we provide a list of requirements to a contracted test group and ask them to automate said requirements as tests, they would. Many times, they would automate only those things requested of them or literally articulated in the requirements and nothing more. If the requirements were actually a user story list and associated acceptance criteria, the testers may not look for upper and lower bounds, combinations, negative tests, or even explore alternative paths in the system - they would automate what was provided and requested.

Similarly, again reflecting on the 17% and 8% Highsmith metrics, coupled with the fact that the customer will change their mind after they first see what they don't want, were we to create an N-100 or even N-1000 line task based project schedule that says "do this, then this, then this" and so on ... what do you think would happen? Of course, people tend to focus on "what's next" on the list of tasks rather than "what's next" on the path to meeting a particular customer need. When we create an elaborate, detailed, or otherwise time investment heavy plan, we tend to focus on using the plan rather than making context driven decisions along the journey to our goal...we tend to do what we are told (or what is suggested).

And if I'm given a framework within which to think and act, and along comes a change, my instinct is usually to protect the framework upon which I'm focused (in this case, it may be a project plan) from being compromised. Seems funny, but we see it time and again; people tend to work very hard to create project plans and really do not like to have them jumbled up along the way. We tend to like constants.

What does it look like in an healthy environment when we choose to respond to change versus follow a plan? Well, rather than preventing, discouraging or otherwise befuddling a customer's desire for change by using change prevention boards and processes, we actually invite change on a regular basis. We leverage the customer to identify everything they feel is important and we tell them what we believe is achievable in the next delivery sprint of perhaps two weeks. While we are delivering, we further invite the customer to not only add new items to the list, but to re-prioritize the list in preparation for the next sprint on the way in two weeks. At the end of the sprint when we demo our working, testing product to the customer, we invite defect observations, change observations, reactions, emotions and general feedback so that the customer tells us what they want changed ... and all this without pain, toil and penalty for the customer. Invite change frequently, often and on purpose.

"That is, while there is value in the items on the right, we value items on the left more."

Processes and tools, comprehensive documentation, contract negotiation and following a plan all have a place in serving a customer and delivering value-add solutions. However, when given the opportunity .. choose to spend time with individuals over having in-depth processes and tools discussing interactions and individual; choose to deliver tested, working software in short bursts rather than lengthy documents discussing such a thing; choose to work with a customer to solve problems rather than creating contracts that define the relationship and solution; and choose to invite and respond to change as quickly, proactively, and often as possible rather than following a plan for the sake of honoring the plan.

Summary? Choose to practice being a person.

No comments:

Post a Comment