Tag: agile principles

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

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

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

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

“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

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS