Posted on

Agile Values: Responding to Change Over Following a Plan

larry apke agile doctor

responding to change agile

“Responding to change over following a plan”

Of the four agile values this seems to be, at least in my opinion, the least controversial and most self-explanatory. I can only imagine how frustrating it must have been to rational humans to even have to call out such a thing when they were designing the Agile Manifesto, but here we are. This means that this value, although self-explanatory to many, is still very important to include. It serves as a reminder as something that we should never forget, even if we think it’s common sense. When contemplating this value, my mind always gravitates to Chevy Chase and the movie National Lampoon’s Vacation. I can imagine project managers as so many Clark Griswolds rushing headlong towards the world’s largest ball of mud, also known as code.

The interesting thing about big upfront design is the gall it takes to even begin to believe that all can be known at the beginning of a complex endeavor. This harkens back to some of my earlier posts, including Software Development is Communication, where I argue that those in charge of software development decisions (like team size, composition, physical location, etc.) have no clue about software development.  Software development is most often a complex undertaking. Complexity theory tells us that complex problems are solved by feedback and that small changes can lead to large consequences.  To me this argues less for upfront design and more for something called emergent design. This can only be accomplished when our development techniques allow for emergent design – hence my nearly fanatical support for BDD (Behavior Driven Development) and CD (Continuous Delivery) as I present in The Two Things You Must Have for Lasting Agility.

The world is ever changing and complex. Software development relies heavily on creativity and communication.  These things are only possible when we leave the illusionary safety of upfront design and embrace the uncertainty as well as expect and respond to change and create a development environment  (both tactical and cultural) where this can occur.

– Larry Apke

Be sure to check out the rest of my Agile Values series!

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

Posted on

Agile Values: Why Contracts And Software Development Don’t Mix

larry apke agile doctor

customer collaboration

“Customer collaboration over contract negotiation”

We all have customers. If we didn’t there would be no reason to do what we do. If we didn’t their would be no one to pay our invoices. And when someone agrees to pay you for work, they generally want to have some kind of agreement on the nature of the work for the money that is being paid. This agreement is usually put in writing and voila, we have a contract. This is an important part of the process and as everyone knows, contracts are valuable documents for both the customer and yourself. But as the Manifesto states, it’s important to not get caught up in negotiation fever.

While it is a good thing to have an agreement before work begins, there are a number of unfortunate aspects to even having such an agreement.

The main problem is complexity.

Software development, by its very nature, is a complex endeavor, dependent on communication and creativity to succeed. While it would be wonderful if all our customers were omniscient, they are often far from it. If we are building a house, we could easily choose things like materials and the architecture of the project and expect that the final building will resemble what was originally agreed upon. Such a thing is rarely true in something as complex as software development, but it hasn’t stopped people from trying (even today).

There is a field of study called complexity theory that applies well to software development in my opinion. In his article, ”On Understanding Software Agility—A Social Complexity Point Of View”, Joseph Pelrine writes:

Many people still regard building software as a complicated undertaking, but in fact it is a defining example of a complex or a ‘wicked’ problem. The concept of wicked problems was originally proposed by Horst Rittel and Marcus Webber. Wicked problems have incomplete, contradictory, and changing requirements; and solutions to them are often difficult to recognize as such, because of complex interdependencies. Rittel and Webber stated that while attempting to solve a wicked problem, the solution of one of its aspects may reveal or create other, even more complex problems. Rittel expounded on the nature of ill—defined design and planning problems, which he termed ‘wicked’ (that is, messy, circular, aggressive) to contrast against the relatively ‘tame’ problems of mathematics, chess, or puzzle solving.

If the nature of software development is indeed ”wicked” then trying to agree on all the requirements at the outset in contractual form is not only wasteful but counterproductive. A much better way is to form an understanding with broad brush strokes and work together to attack the problems, hence the need for collaboration over contract negotiation.

The same is true when the customer is internal. This is why Scrum has someone called the product owner who is available daily to the team to work on the software. Instead of assuming we know everything at the beginning and then have mind—numbing change reviews and contract addenda, is it not better to forge a lasting partnership? Or as Deming calls it, “a long-term relationship of loyalty and trust”.

– Larry Apke

Be sure to follow me on Twitter and Quora! 

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

Posted on

Understanding The Agile Manifesto: A Brief & Bold Guide to Agile – Podcast Now Available

Understanding The Agile Manifesto: A Brief & Bold Guide to Agile by [Apke, Larry]Those of you who may follow this blog may have noticed it has been some time since the last post. It was an eventful summer and it was good to spend some time to catch my breath. Now that the kids are heading back to school, it is time for me to renew my posting. In addition to posting the podcasts, please check back for new Agile posts.

I am pleased to announce that my first book, Understanding the Agile Manifesto: A Brief & Bold Guide to Agile is now available as a podcast. Over the next few days / weeks I will be releasing the book, chapter by chapter, on this website and through the iTunes store under my “Agile Doctor” podcast. Since the book was a series of blogs, the podcasts will also be made available under the original posts.

This project is very dear to my heart as the podcasts were recorded by my son, Vadim Kim, who assisted me over the summer as my intern. I think he did a fantastic job of recording my “little” Agile book and I am sure you will enjoy.

The most recent version of the book includes an Introduction which was never part of any individual post. I have included the podcast of the Introduction below.

 

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

Posted on

The 3Ps of Agile Software Development

einstein

I am often faced with explaining the various aspects of Agile to people new to Agile and I have come up with a very simple way to remember (and explain) Agile. I present to you now the “3Ps of Agile Software Development” with the hope you find this useful to your own understanding and an aid in your ability to explain Agile to others.

Philosophy

“The world as we have created it is a process of our thinking. It cannot be changed without changing our thinking.” – Albert Einstein

einsteinAt the core of Agile is the Manifesto. A few years back, I even took the time to create business cards that contained the four values and twelve principles. When I heard people say that this is or is not Agile, I could hand them a card and say, “This is Agile.” This is where I start in explaining (and training) Agile because without the philosophical underpinnings one is most certainly lost. I couldn’t give an exact number, but I do know that a high percentage of companies trying to move to Agile are unable to fully embrace and promote the philosophy behind Agile. I wrote my first book, Understanding The Agile Manifesto: A Brief & Bold Guide to Agile, because I have witnessed firsthand the struggle companies are having with adopting the Agile Manifesto. I have seen companies rewrite the Manifesto to omit or change things that they find too difficult to embody and watched good people punished for having the temerity to post the Manifesto at their workplace. The philosophy is the base upon which the other two Ps rest.

Process

“This strange dichotomy, this agonising gulf between the ought and the is, represents the tragic theme of man’s earthly pilgrimage.” – Martin Luther King

martin luther king jr.It is not enough to have the basic philosophical understanding of Agile, we must find ways to embody the principles. There have been a number of ways to embody this philosophy over the years. Take for example, Scrum. Technically it is a framework, but it contains ceremonies (actions) that allow us to realize the Agile philosophy. Why do we do retrospectives? Because the last of the Agile principles state, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” While Scrum has claimed a high level of mindshare, there are numerous other processes and frameworks that also help organizations embody the philosophy of Agile (Kanban, DSDM, Crystal, etc.). In fact, Agile’s history is one of empiricism with people “uncovering better ways of developing software by doing it.” This means it was actually Process (and the 3rd P) which came first. It is Agile Processes that help us to realize the philosophy of Agile.

Practices

“Practice does not make perfect. Only perfect practice makes perfect.” – Vince Lombardi

lombardiSometimes when we classify things, people can certainly disagree with our classifications, but when I explain the term “Practices” I am referring specifically to software development practices that are done within the processes and frameworks. It is into this category that I would put things like Extreme Programming (XP) practices as well as something like BDD. What separates these things (which could be argued to be processes) is there more technical nature and the needed expertise of software development professionals (developers and QA) to implement. Processes are things that embody the Agile philosophy which any intelligent individual could understand and facilitate. For example, though it might be optimal for a scrum master to have a development background, one could be successful as a scrum master without it. On the other hand, one could not be successful in performing code review or test driven design (TDD) without knowledge of coding. Why do agilests do BDD? Because through BDD we can realize (among others) the principle that states, “Business people and developers must work together daily throughout the project”. It is Agile software development practices which also help us to realize the underlying Agile philosophy.

While any system of classification subject to interpretation, I have found that speaking to the 3Ps of Agile Software Development has provided a simple and understandable way to introduce people to Agile. If you get a chance to present this, please let me know if it helps you as well.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

Posted on

Deming, Agile and SAFe

W._Edwards_Deming
W Edwards Deming

This week was a big week in my quest for lifelong learning – one in which the learning should prove beneficial to my furtherance of agile values and principles; a week that I think I will think of a the week of Deming since I completed my reading of two of Deming’s books – Out of the Crisis and The Essential Deming – and I also completed my Scaling Agile Framework (SAFe) training in which I saw Deming’s face and quotes about a half a dozen times. SAFe itself can be thought of more of a homage to Deming’s work with systems than a software development framework or, perhaps more accurately, Deming’s systems thinking as it applies to software development.

While I will shortly take the SAFe examination test, I am certain that my recent completion of two of Deming’s books will serve me well when I take the exam. In fact, I am inclined to wonder if a healthy knowledge of Deming and deep knowledge of Agile and Scrum may be, while not enough to pass with flying colors, at least enough to merit a passing score. If for nothing else, there is a big value to SAFe training in that it will expose a huge number of people to Deming than might otherwise not find him, though in all candor I cannot imagine that anyone truly interested in creating high quality software would not find Deming on their on quest for knowledge and improvement. I find it somewhat sad the number of people in management who I have personally had to introduce Deming to over the years. Then again, if the folks I help become agile had prior knowledge of Deming would they have a need for me?