What the Agile Manifesto Looks Like When Implemented, Part I

Part II

As time goes by, many more people pick up Agile books, attend conferences, classes and user groups, and declare themselves to be "Agile" in some way, shape or form. A challenge lies in the fact that while many people state themselves to be practicing some form of Agile behavior, do they really know why they believe that they believe, or what it really looks like in action? Do all Agilists understand the evolutions of the belief system they profess in public places, or have they simply gotten a free t-shirt at a conference and put on their belief system when getting dressed in that new shirt?

If by chance someone is starting anew on an Agile exploratory journey, that is of course outstanding and should be cultivated. And if someone has been on an Agile journey now for a number of years, it only means they are not new at it, but certainly not "done". Let's explore the Agile manifesto components, what they mean, and what it looks like in action when one sometimes refers to themselves as an "Agilist". In particular, let's look at the first sentence...


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 break it down.


"We are uncovering better ways of developing software by doing it and helping others do it."

This sentence suggests the journey 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.

What this looks like when done incorrectly in a workplace: As happens sometimes, were someone to document the development and delivery process at a company, put it up on the wall and suggest 'this is the process' as if the picture or document were an epilogue to a long, unwanted journey of pain ... it is often perceived (and sometimes intentionally communicated) as a declaration of law, complete and sound in usefulness as is. When we later discover the need for a process modification, the method of changing a process sometimes has its own process thereby making it difficult to veer from the base, and seemingly impossible to evolve it. A documented, baselined, published, measured, and audited process sometimes becomes the deliverable, the demi-god, and the purpose for employment. Unless one's company specifically designs and sells processes as a product, most of us are employed to deliver value to a customer, not a process map discussing the delivery of value.

There should always exist a pattern of behavior associated with delivering software such as sprints, sprint planning and review meetings. No, it should not become so sacred that changing it violates normative laws of existence. Just as we invite the customer to change his or her mind in time for the next sprint, so should we be inviting improvement or optimization per sprint. Have a process; do not craft it in granite then worship it as changeless.

What this looks like when done correctly in a workplace: 'Constantly uncovering better ways of developing software' suggests constant observation, constant platform for expression of observations, and a belief that these communicated observations are actually heard, valued, supported, or otherwise encouraged to be implemented.

What this looks like in Toyota's workplace is the ability for any line worker to shut down any line, at any time. In other words, when they see a problem that needs to be improved or addressed they are expected to address it.

Underwater divers are taught something very similiar in their early education when told that anyone can call off any dive at any time for any reason. In this case, when something is observed that needs changed, it usually means a life is potentially, or literally at stake. If you find yourself embarrassed to bring attention to and enact change while diving, said timidity may likely cost a life.

Ross Perot, founder of EDS, noted his favorite kind of employee as one who would see a problem, address a problem.

In our software development and delivery environments, this constant invitation for change takes on many faces - all may or may not be automated - though all require human intervention.

  • In one environment, change is invited by starting every sprint planning meeting with a ten minute retrospective simply asking, "What should we do differently this sprint?"
  • In another environment, change is invited by having a new scrum master for every new sprint such that all team members have opportunity to not only lead, but to understand how to follow.
  • In another environment, change is invited by having development staff be a part of demo and sales cycles for thirty day rotations so that fresh technical perspective is brought to the table to the benefit of sales, and first-hand sales process experience is brought back to the development teams for context.
  • In yet another enviornment, change is invited by having development staff be a part of product development/direction whereby feature requests are decomposed into themes, epics, chapter, stories and acceptance criteria in preparation for relative sizing and corporate prioritization meetings.
  • In yet another environment, change is invited by not only having sprint reviews at the end of every sprint requesting customer feedback, but including the customer in the journey of daily scrums, product backlog prioritization, feature to user story to acceptance criteria definition along the way.
And the latter part of the statement, "Discovering better ways ... by doing it and helping others do it" suggests that it is not enough to give someone a book, send them to a class, or for thirty+ minutes have them listen to an *mp3 or watch an *mp4. The optimum method of constantly discovering better ways is to do it together. What does this look like on a daily basis in our development environments?

  • In one environment it means physically co-located teams who are not only working on the same goals, but working on them together, at the same time ... eating, drinking, and breathing both the goals and the journey - together.
  • In another environment it means physically pairing two team mates together to work on the same piece of code, same acceptance criteria, task and/or story - discussing the structure and evolution of a test to prove yet unwritten code, followed by one coding while another contributes by looking for efficiencies, suggesting alternatives/options, and validating progress along the way.
  • In yet another environment it means on-demand peer to peer video capabilities such that there is a face connected to the conversation in real-time. The tele works well, as does interactive chat; though there is additional value in seeing and experiencing facial response associated to speech, demeanor and intent.
  • And in another environment, a vendor may spend frequent time with a customer helping them to understand how to assess a feature request for business value in terms of net present value (NPV) versus simple return on investment (ROI), how to break it down into parts and pieces, and how to understand the development/delivery environment well enough to leverage strengths and conditions of the team and environment.
There was a time when many people believed software development was a collection of nerd-like people, identified by unique sets of numbers as asset labels, with ne'er a developed social skill, sitting in cubes all alone without need for sunlight or inclusion in every day business. Today, we know this logic to be ridiculous and very simply - wrong. For every layer of separation between a developer and a customer, we increase the probability of delivering wrong solutions.

The very first sentence of the Agile Manifesto suggests that developing and delivering useful, working, tested software that reflects a direct, daily business need of a customer ... is social; and above all else ... moment by moment evolutionary between the developer and the customer.