Of course, any discussion of Agile values starts with the Agile Manifesto. The first sentence declares that Agile development is about seeking better ways and helping others. Then, as if espousing self-evident truths, the founders present four relative value statements. Finally, they emphasize appropriate balance, saying that the relatively less valued items aren’t worthless: implying that they are to be maintained inasmuch as they support the relatively more valued items.
While there is value in the four relative value statements, I believe most successful Agilists value the first and last statements more. So to me, the core Agile values are continuous improvement, helping others, and balance.
There’s a lot written about Agile behaviors, but as I read most is geared toward scrummasters or managers, and most is about transitioning from the waterfall world. Starting from the premise that Agile methods are established, focusing on participants rather than managers, and based on the assumption that behaviors are grounded in values, this post details the values and behaviors I’ve observed of those who succeed as Agile team members.
Many new in their careers or new to Agile development shy away from making suggestions or calling out errors. Successful Agilists not only call out errors and inefficiencies, but also are receptive to constructive comments about their own work.
For example, a colleague recently found “select * from…” in a production SQL query. Generally speaking, the select * construct brings back all of the columns from the table(s) in a query, and is considered bad practice for a number of reasons. She quickly called out the issue and suggested that we immediately start team code walkthroughs, saying that walkthroughs would not only prevent egregiously bad coding practices but also help bring us all up to speed on every team member’s work, and expose us to innovative techniques that we otherwise might not see.
Clearly this individual had been thinking about how to improve our coding practices, and modeled the continuous improvement value by jumping on an opportunity to lift team quality and consistency.
The Agile retrospective, when properly done, helps team members evolve toward behaviors supporting continuous improvement by providing a safe environment for offering improvement suggestions, thereby encouraging behavior like my colleague’s.
An Agile team member finds him or herself in a web of social relationships with other team members, the scrummaster, product owner, and in many cases with a business person who will be the direct user of their application or report. In this setup, an unhelpful person stands out like a sore thumb, typically either changing or leaving after a short tenure.
However, I’ve seen some who stand out as exceptional even among a mutually supportive group. For example, one individual on an Agile team was assigned the difficult task of correcting a particularly troublesome lookup function. No one wanted to work on this gnarly logic because the supporting data was complex and self-contradictory, requiring complex coding to accurately untangle repetitive and erroneous data. He threw himself into the task, uncovering and fulfilling previously unrecognized business needs and explaining our challenges to previously dissatisfied users. In the process he became recognized as the authority on the business area concerned and significantly raised the credibility of the team and its work.
Agile team members find themselves rewarded for being helpful in difficult situations. Assisting others quickly becomes a win-win due to improvements in product quality and goodwill all around.
The balance question often manifests in the common misconception that there’s no requirements analysis or documentation on an Agile project. Of course requirements are involved in every app dev or reporting effort (how else would you know what to build?), so this assertion is really all about developers not wanting to write things down.
As Albert Einstein was paraphrased, “Everything should be made as simple as possible, but not simpler.” Those who minimize documentation in Agile methods place the wrong emphasis on the phrase “just barely good enough”. Rather than just barely good enough, the point is to make documentation and planning just barely good enough. As the linked post makes clear, the art of stopping work on something when it adequately serves the purpose takes practice to master.
Here are my personal guidelines: First, code and UI or visualization are paramount. No documentation is required if the code is standard or understandable, or if the UI/viz is self-explanatory to its audience. If either isn’t the case, the writeup should be sufficient, minimal, clean, and readily available to its audience at the time when they will need it. For example, in the Tableau dashboards I develop, if the derivation of measures and dimensions on the dashboard isn’t obvious, I include the image of a spreadsheet with definitions as a separate tab. Is this the best possible solution? No. But it is quick and easy for me to put together, readily available to the user, and stored along with our code and minimal documentation for later enhancements.
Looking at the other relative value statements, we value the items on the right inasmuch as they support the relatively more valued items on the left:
- Individuals and interactions over processes and tools: Today’s Agile projects run based on process frameworks like SAFe or Scrum, and use tools like Jira or VersionOne. Scrummasters who are converted waterfall PMs often misinterpret these tools as instruments of control rather than facilitators of interaction. In early iterations Agile team members should help the scrummaster understand the Agile perspective, complying just enough to keep him or her out of trouble with waterfall-oriented program managers while helping transition to a collaborative Agile perspective.
- Customer collaboration over contract negotiation and Responding to change over following a plan: Helpful, innovative Agile developers are delighted when they meet customer needs and disappointed when they don’t. If needs change, however suddenly and for whatever reason, the Agile developer wants to make it right. Agile values don’t preclude recording a plan to meet a user’s needs and setting an expected target date, but they do preclude resistance to changing the plan when conditions on the ground change, either for the developer or the user.
There’s a lot of complexity and detail in Agile frameworks, and much to be learned about Agile development. However, developers who model the core values of continuous improvement, helpfulness, and balance naturally demonstrate the behaviors that make Agile development successful.