“Gentlemen, this is a football.”
Vince Lombardi
Welcome to the first of the Basics of Agile series.
Basics are profound things. The more elemental, the greater the impact.
Admittedly, if you are well experienced in Agile and see this article series, you might feel a bit like the Green Bay Packers when Coach Lombardi uttered the famous quote. “Gentlemen, this is a football.”
“Yeah, Captain Obvious.”
But knowing what it must be like in most locker rooms when a great team is underperforming, perhaps the team was instead thinking, “where can I hide?”
Many coaches are known to “peel the paint” at halftime. Instead, the Packers hear this most elemental instruction. They relax a bit and start to remember their training, what they have worked on all season. I can hear the team now, or at least their thoughts – “Yeah, Coach, we know what a football is.” In the second half, they acted like it and came back to win the game.
Sometimes even for those that are experienced, like the legendary Packers, the only way forward is backward. At least, it feels backward.
There are times when we catch ourselves going through the motions. We all need reminders.
When a college basketball player that could shoot the lights out in high school cannot get the shot off in college, what can he do to fix the problem? The answer is often fundamental mechanical changes – how the player shoots. The only way forward is often going over the basics again. The results can be, in a word, profound.
On the other hand, maybe you are new to Agile and need a primer. All of this is new to you, and you need Cliff’s Notes version to help you wrap your head around it all. Trust me, I have been there.
Why is this such a big deal?
It still boggles the mind that a statement that can fit on a napkin, The Agile Manifesto, has been expanded into endless 3 inches thick volumes by multiple authors. So, what is my answer to that? Well, I guess writing about it too, adding to the digital pages on the subject. However, I promise to get to the point in this series rather quickly. At least before page 500.
Origins
Instead of going into the history of Agile, I will talk about the motivations that brought it. Motives usually have more to do with origination anyway. Or putting it more familiarly, “Necessity is the mother of invention.” Perhaps that is why Simon Sinek’s message on “Find your why” resonates so well. So, why did Agile come to be?
In previous decades, the de facto standard for software development, Waterfall, was based on a project model primarily used for engineering projects. However, that model did not perform well for software development. The problem?
Change.
Unlike buildings or cars, external and internal environmental factors caused the requirements for software to change faster than the software requirements could go through the processes of planning to development. Waterfall proponents thought that planning heavily before a project began would lower the number of problems. There is a logic to that, but the logic did not match the anticipated results. Planning too far in advance, without the flexibility to adapt, caused more problems than it solved because the environment changed before the product delivery. The gap between need and met need never closed. Actually, it widened.
A new methodology was needed in which change is embraced as part of the process, and that allowed changes to requirements to be performed as late as possible before it was developed. Several methodologies arose to fill that gap, including Scrum, XP, Rational, and others.
The thought-leaders of those methodologies came together a couple of times to discuss how best to proceed. Eventually, they agreed on a simple statement that highlighted what was in common. That statement is called The Agile Manifesto.
The Agile Manifesto
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.
There have been several different attempts to expand this manifesto into principles by organizations such as The Agile Alliance, PMI, IIBA, and others. Eventually, I will go into those proposed by the International Institute for Business Analysis (IIBA), since I am a Business Analyst. For now, I will offer my own take. This will be more exposition than a list of principles since I like to take things apart when writing about them.
First, the opening phrase hints at experimentation and empirical analysis. “We are uncovering better ways…” Agile is not a prescription, but a series of hypotheses. The intention is to find what works and do that. Whether you communicate this way or that, deploy in 2 weeks or 6 months, document through napkins or repositories – the Agile approach is to do what works for this endeavor. Those decisions might bomb on another project – even one involving the same people. However, Agile would observe and refine until it works.
“…by doing it and helping others do it.” Perform the experiment, observe the results, and share the findings with others. Feedback is built into any Agile environment from Strategy to Initiative to Delivery. Additionally, feedback is built into collaborative structures, research activities, and decision processes.
Then there are four value statements. These do not mean to focus on one to the exclusion of the other. Instead, the balance simply leans toward the left side instead of the right. The idea is to keep the focus on what is more important without neglecting those items that support the goal.
Individuals and interactions over processes and tools
The first value statement shows that it is more important to have the right people working collaboratively than have the right tools and processes. Give a team the authority to self-govern, and they will figure out what works. Expensive tools may not be necessary and can even distract.
The most efficient project I have worked on used the simplest of tools to manage the project. It was a travel and expense reporting project for an international consulting company built on a SAP HANA database to provide high performance. Team members were located in Florida, California, Kentucky, and Ukraine. This project managed quite well with the requirements captured in a spreadsheet. Each row was the equivalent of a User Story, with additional requirements that were recorded in a parallel spreadsheet for each story. There was no project management or requirements management tool. Nor was there a Kanban board to track story progress. All statuses were maintained on the appropriate row in that shared spreadsheet. Daily stand-ups were guided by a filtered list of active status rows. They splurged on getting the best development and database environment instead of high-cost project management tools that impose time and cost overhead.
As efficient as that was, it helped that the entire development team were very experienced developers, each having a master’s degree in computer science. Other teams might not have pulled it off.
Working software over comprehensive documentation
Next, the main thing is to have software that works. If it does not work, then the documentation does not matter. Keep focused on the desired result. One of the misconceptions is that Agile de-emphasizes documentation. Instead, it values timeliness of documentation that is verified by the customer just ahead of development. That means the product is based on the latest information possible. Even then, the point is not to have the newest documentation, but to have working software. Each iteration is a commitment to producing something that works.
Customer collaboration over contract negotiation
Customer collaboration is more important than contract negotiation because customer satisfaction is not measured by a contract or statement of work. Agile understands the protective importance of a contract. They are defensive documents to describe the minimal working expectations. However, contracts are not intended as guides to product delivery. To know what is expected, you have to talk with the customer, not the lawyer. If you want repeat business, begin on friendly terms by collaborating, referring to the contract as an arbiter if the relationship is dysfunctional. Focus on building functional relationships, and you will not have to worry about dysfunction.
Responding to change over following a plan
Responding to change versus following a plan because the plan is not flexible enough to adjust to the current organizational needs.
Originally, Waterfall methods were intended to be iterative and allow change. In practice, gaining approval for change requests was difficult, and changes were viewed with much disfavor. Changes to the original plan were strongly discouraged. This effectively killed the change request processes. Opportunities to utilize the latest and best information were ignored so that the original plan would remain intact. There was a need for something different, both in the methodology and in the project output. Waterfall prevented both.
Change is built into any Agile environment. That does not mean there is no change request. After all, you do need to control cost, and CRs are how those costs are approved. In Agile, change requests may alter timelines and priorities, but they are included without sinking the project. The reason Agile approaches were envisioned was to handle change better.
The Agile Mindset
Looking at the implications of The Agile Manifesto, the importance of those four value statements is as profound as Lombardi’s football. They are a call to keep the focus on the basics of customer value, collaboration, feedback, and delivery of working results based on the most current information available. The Agile Manifesto codified a different way of thinking about initiatives and the relationships required to do the work.
Next, I will begin discussing Seven Principles of Agile Business Analysis, based on IIBA’s Agile Extension to the BABOK® Guide, which bring even more guidance to how Business Analysis works in an Agile framework.
You must log in to post a comment.