Agile Principles: Face to Face Conversations


The most efficient and effective method of conveying information to and with a development team is face to face conversation.

Since there are so many misconceptions about miscommunication around agile, I created my business cards to contain the entire Agile Manifesto so that when people confuse scrum framework with agile philosophy or say, “This is agile blah, blah, blah,” I can hand them my card and say, “This is agile.”

Then I let them know that agile is nothing more than a philosophy, a series of values and principles.

In my mind, a principle is something that could be debated. When it comes to methods of communication, it would be very difficult to debate that something other than face-to-face conversation is best so this reads more like a fact than a principle.

 A quick google search on the topic produces a lot of results in confirmation that face-to-face communication is “the gold standard of communication” and an impressive body of research  demonstrates that face-to-face is the most information-rich medium.

The question is why this would need to be called out in the Agile principles? I think the reason is that all too often software development companies forget this important fact.

I point out in my presentation about complexity and Cynefin that most software development is complex. As such it requires a great deal of communication and collaboration. It is not something that we can just gather requirements and parse these out to large and disparate teams across the globe (unless, of course, your project is truly complicated and not complex).

Working in an Agile way requires that we come to a good understanding of what is desired through frequent, high-quality communication. The fourth principle addresses the frequency while this principle attends to the richness and quality of the conversation. I always tell my teams that they need to make sure to keep some whitespace free on their whiteboards since the most effective communication is face-to face at a whiteboard so that ideas can be discussed in all the richness of our senses and where examples can be used to quickly iterate through ideas.

In the end, all the agile principles and values must be viewed through the lens of being a reaction to the mistakes that were perpetrated before. It is readily apparent that this principle was added to the other eleven to be a constant reminder that documentation and CYA only allow us to avoid failure, but real face-to-face conversations lead to a much deeper understanding that will (hopefully) lead us to success.

Larry Apke
Follow me on Twitter, LinkedIn and Quora

larry apke understanding the agile manifesto

Agile Principles: Motivation is the Key to Quality

larry apke agile doctor principles

larry apke agile doctor principles

Principle #5: Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.

If I had to take exception to any value or principle this would have to be the one.

While I have the utmost of respect for the original Agile signatories, they made a slight mistake because this principle refers to only projects. I have ranted often enough about the distinction between project and product management (See this post for more), but it is important to understand that Agile works best when we build a product (not a project) mindset. By having a principle that mentions projects might hinder folks from transforming their thinking to product-centric thinking.

That slight semantic problem aside, this principle highlights the need for motivated individuals in order to complete quality work. Prior to agile (and even today) people were assigned to death march projects, treated like widgets as to their work and children as to their maturity, needing to be supervised at every step of the way lest they make a mistake.

This is Taylorism and has been proven to work well with rote and manual tasks but has been shown scientifically to not work with knowledge work and workers. I have written previously about this in reference to the book Drive which has wonderful information about motivation and the science behind it.

Another aspect of this principle is trust. The very fact that we do not trust our people leads to a whole host of detrimental behavior and waste whether it manifests as command and control management, approval bottlenecks, ridiculous amounts of upfront requirements and so on. I encourage people to read Patrick Leoncini’s Five Dysfunctions of a Team where you would notice that other dysfunctions cannot be overcome until we overcome the primary issue of trust.

This principle also refers to environment and support. In my coaching engagements (and throughout my career) I am constantly amazed by the sheer number of managers who fail to realize that their primary role is to support those folks assigned to their care. Managers must be true servant leaders (and the scrum framework calls this out in the position of scrum master as servant leader) for their people.

The front line workers are not there to serve their managers. Furthermore, it is up to management to create an environment (including physical environment, development environment, necessary software and tools) that allows workers to do their work.

Larry Apke

Download my new ebook, Understanding the Agile Manifesto, for more Agile help

Agile Principles: Work Together Daily or Fail

larry apke agile doctor

larry apke agile doctor

“Business people and developers must work together daily throughout the project.”

I quote this principle verbatim to all the teams I coach constantly because it is the only completely prescriptive principle. While other principles use more vague words like “early”, “late” or “shorter”, “daily” is not open to negotiation or interpretation. The word “must” is also unequivocal as are the roles described.

That prompts the following question – why were the founders of Agile so strident with this principle while allowing for broader interpretation with all other values and principles?

To me the answer is simple – in order to avoid even the smallest chance of misinterpretation it is crucial for everyone to understand the criticality of daily communication between business and development. It also gives us a clue as to what the most important aspect found lacking (at least at the time of the writing of the Manifesto) in failing projects is.

In other words, unless you have business needs properly communicated to development, through daily interaction, chances are good that your project will fail.

This simple reality – the inability for business and development to communicate – underlines all of the failed projects I have witnessed in my many years of experience.

Interestingly, this principle also is a good measure of a company’s ability to successfully transform to agile successfully. A great number of companies that experience agile failure do so as a direct result of their inability to live the agile principles, especially in relation to the fourth agile principle.

If you want your team or organization to be agile but you have not ensured an environment where business and development can work together daily, your chances of actual success is slim to none, so please do not claim that agile has failed you when, in reality (and in nearly every case of “failed” agile I have witnessed) you have failed agile.

Larry Apke

Check out my Slideshare for more Agile presentations & follow me on Quora

Agile Principles: Frequent & Working Software

larry apke agile doctor

larry apke agile doctor

Principle #3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

While there are many people who believe that the key reason to adopt agile frameworks and methods is for increased productivity, I tend to find this to be more a healthy byproduct of a team working together over time (and thus could be found in other methodologies).

The real benefits of agile lies in greater transparency, predictability and faster time to market.

The third agile principle speaks directly to these, especially quicker time to market.

When organizations I have coached are having issues with agile adoption, I have come to expect that they will have difficulty upholding this principle because it requires the most organizational change. It is no coincidence that there is a greater desire for “dev-ops” as agile transformation is attempted by more, especially large, organizations. In one of my regular presentations I argue that there are two things necessary for agile success over the long term: One of these is Continuous Delivery (or at least continuous integration; the other necessity is acceptance test driven development or ATDD, with my preference being BDD).

It is difficult to deliver working software often, but it is critical. In fact, even if a team is not good at delivering working software often, there is a tremendous amount of value to be obtained trying to deliver software often if only to find out the reasons why your team cannot.

In consulting with organizations I am often asked to merely optimize agile teams, but the real work of transforming to a complete agile system is not considered. These “Wagilefall” organizations are nothing more that Waterfall process with “agile” development (In a lot of cases even this “agile” development itself is not very agile).

I often ask organizations a simple question, “How long does it take you to deliver even a single line of code change into production?”

This is one simple question to gauge your agility. If the answer is more than a day or so then there is a lot of work that needs to be done for continuous integration or continuous delivery. I find it amusing to think that a “big bang” approach with months of code changes can be successfully delivered if it is so difficult to deliver only those few changes that are a result of a single iteration.

Larry Apke

Feel free to add me on Google+ 

Agile Principles: Welcoming Change

larry apke agile doctor

larry apke agile doctor

The world changes fast. The software development world changes faster.

Locking into a long term plan and remaining steadfast to that plan might bring comfort when the world around us is awash in change, but it doesn’t give the flexibility necessary to remain competitive.

If we can react to market changes faster than our competition, we can “harness change for our competitive advantage.” And we should not believe that market share or size can save us because Facebook barely existed only five years ago and I guarantee that the next Facebook is being made in a dorm room right now. Don’t believe it?

Typical waterfall projects are very plan driven and change is discouraged. They rely on things like a change review board to approve any changes to scope. In most places I have been the people executing projects would rather undergo a root canal than to present changes to the review board! On the other hand, Agile requires a more value-driven approach. Agile strives to make sure that value is relevant and can adjust with changes like environmental and competitive pressure, emerging opportunities, unseen potentiality and so on.

Nevertheless, never confuse welcoming changing requirements with chaos.

Using agile or scrum is not an excuse to be unorganized or lack vision. Chasing one BSO (Bright Shiny Object) after another is the surest way to create a disorganized mess of software which leads to a competitive disadvantage and a demoralized workforce.

I once worked with a company that allowed its product owner to change nearly all (about 90%) of a team’s stories the Friday before sprint planning. This led to the team not having the time to groom their stories effectively and resulted in very long sprint planning sessions with estimates of work that were wildly inaccurate. In the end, the quality of the software suffered, the team’s productivity was reduced, the team was rarely able to implement what the business desired and there was a growing animosity between development and business. It was a downward cycle that the company still suffers from today.

If chaos like the above can be avoided then Agile’s second principle proves to be extremely powerful in helping us continually concentrate on emerging value and giving our customers the competitive advantage that they all seek.

Larry Apke

larry apke understanding the agile manifesto




Agile Principles: Customer Satisfaction

larry apke agile doctor

early and continuous delivery - Larry Apke

As an Agile coach I am in the Agile transformation business. Coaches are rarely employed when an organization “gets” the philosophy and properly implements an Agile framework or methodology. In my experience those that are most challenged are those who seem to concentrate on the ceremonies while failing to focus on the bigger picture concerns – those more interested in “doing” rather than “being.”

The first Agile principle is that our highest priority is to satisfy the customer through early and continuous delivery of valuable software. This provides the grounding teams need as they pursue the Agile path. One things I find interesting about the principles is where the principles are vague and when they are specific or prescriptive (I will certainly touch on this more when writing about the fourth principle). In this case, “early and continuous” are vague, but “highest priority” is certainly not. While daily stand ups, planning, grooming and so on are important components, we should never forget to continually ask ourselves, are we satisfying our customers? Not because it is merely important but because it is the most important.

The phrase “early and continuous” is important because we can provide users with functionality in a more just-in-time manner and allow for more frequent feedback that is critically important when we are working on a complex endeavor like creating software. This also tangentially points to some of the best software development practices like continuous integration & delivery, Behavior Driven Development (BDD) and Test Driven Development (TDD).

The phrase “valuable software” reminds us to always be vigilant that we are actually concentrating our efforts on the most valuable stories, those that will give the most return on our investment. We should always keep in mind the Pareto principle – that we receive about 80% of our benefit from 20% of our stories and that means there is a huge value in the work not done.

As always, whenever I face a tough issue in Agile transformations, I regularly look back at the manifesto, its values and principles – especially the one that  reminds me what the highest priority of software development actually is.

Larry Apke