Agile - 2/13 - Agile Doctor

16 August, 201619 August, 2016

Agile Principles: Work Together Daily or Fail

“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

16 August, 201619 August, 2016

Agile Principles: Frequent & Working Software

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+

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

16 August, 201619 August, 2016

Agile Principles: Welcoming Change

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

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

16 August, 201618 August, 2016

Agile Values: Responding to Change Over Following a Plan

“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!

The Importance of Individuality
Working Software Over Documentation
Why Contracts and Software Development Don’t Mix

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

16 August, 201618 August, 2016

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

“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

16 August, 201618 August, 2016

Agile Values: Working Software Over Documentation

“Working software over comprehensive documentation”

Of the four agile values, this is probably the least understood and most often misinterpreted. It certainly does not say that there should be no documentation as some (the less ambitious developers and teams) propose. It says that there is more value to actual software than comprehensive documentation.

While I have a great deal of affection for the Agile Manifesto (I believe that dedicating an entire series of blogs to just this particular topic demonstrates this abundantly), I think that the original writers could have been more specific to remove some of the confusion and misinformation that has sprung up around this value. It might have been more appropriate if the original writers would have said, ”Working software over comprehensive requirements and design documentation,” because I think this is more what they meant.

This level of specificity would keep teams from using the excuse that there should be no documentation at all. We have to remember that the writers of the manifesto were doing so as a reaction to what they perceived to be short comings in the prevalent way software was delivered. In that phase—gated approach, copious documentation of requirements and design were produced before any substantive software was developed. Prior to the manifesto, comprehensive documentation could be delivered but working software was either not delivered or poorly delivered because so much emphasis was placed on requirements and design documentation.

In other words, documentation is important but it should be less important than actually building the software. What is the use of great documentation of a system that is poorly or not fully built? Also, documentation tends to be easily outdated so I suspect that the writers of the manifesto were also alluding to this fact. Why create copious amounts of documentation that does not match the final product? Or why spend all our time updating copious documentation as the product changes?

There are usually two types of documentation — internally facing documentation, like design and requirements documents, and externally facing, like user manuals. So far my argument has been for these internally facing documents. Agile addresses these with user stories and acceptance criteria. I like to attack internal documentation using Behavior Driven Development (BDD) since then the code always matches the internal system documentation (see Specification by Example).

What about external documentation? It might be that they would argue that good design would preclude the need for end-user documentation. I suspect the writers of the manifesto would agree since they are user-focused and that they would be more supportive of more of this type of documentation versus internal documentation.