General Agile - 6/10 - Agile Doctor

20 May, 201516 September, 2015

No More Agile Checklists – Can We Concentrate on Outcomes?

As an agile coach and change agent I am always asked how maturity can be measured at the team and organizational level. What I have found over the years is that there is no lack of different checklists that can be used to give us these “metrics”. In fact, a recent Google search gave me a page that contains links to literally 41 checklists. In addition to these I have personally worked on many different custom checklists myself as if the 41 currently available do not adequately address the needs of teams transitioning to agile! Why is it that these already existing measures are not enough?

Here’s my theory. Most agile transformations are accomplished by outside consultants (like myself) and these outside consultants know that beginners are looking for checklists. A great way to make money and to fulfill the client’s desire is to create a custom checklist or impress the client with a proprietary checklist – one assured to work where none of the hundreds of others can’t.

There is a problem with this checklist approach – it doesn’t really work all that well. The problem is that checklists tend to measure input and are very reminiscent of the failed waterfall view software development. It is, in effect, a CYA type of activity. In other words, you cannot blame project failure on me because I checked all the checkboxes. If checklist software development worked then waterfall would have a respectable success rate and folks wouldn’t be flocking to agile alternatives. No sense trying to fix the problem with the failed approaches of the past.
Another problem is that Agile works because of self-organization of teams and checklist tend to be very prescriptive and top down. A great number of these checklists have so many very specific factors that are measured that they provide little room for experimentation for the team to discover the best way for them. A checklist assumes that they way measured is THE way. If this is truly the case then what about the manifesto which States that we are “uncovering new ways ” not that we have found a way and we have a checklist to show you the way.

My inclination is to reduce our focus on the inputs of Agile and spend more time focusing on outputs. Instead of measuring whether a stand up lasts 15 minutes or less, I think it best to focus on what value did the team deliver during the previous iteration. In fact, I have only two primary measures for when it is time for me to stop coaching – does the team exhibit predictability by completing 90% or more of the work planned each sprint and is the Product Owner happy with the amount of work taken and quality of work delivered. Give me these two things and I don’t give a damn how you did it! However, if you are not giving me these things then you have opened the door to coaching on the inputs. Interestingly enough in order to achieve these pared down metrics most teams figure out what the proper inputs are without a top down mandate.

You can spend a great deal of time, money and effort checking endless inputs or just measure a few highly critical outputs. The choice to me is clear. Stop concentrating on inputs as primary measure and concentrate on the few critical outputs.

4 May, 20154 May, 2015

We Must Inject (not just inspect) Quality

Not sure where I first heard the phrase “you can’t inspect quality into a product” but I have certainly used the phrase myself all too often in my consulting gigs. After a quick Google search, I found the originator of the quote was Harold Dodge and it was first used in a manufacturing context. While I generally eschew appropriating manufacturing analogies for comparison to software development, in this case, it is certainly apt.

In many of the companies I consult with, the prevalent view of “quality” is nothing more than inspection after the fact, a misplaced notion that quality can be insured by finding all of the defects built into the software. The great majority of these inspections are conducted by a separate team, a half a world away by manually banging on keyboards and mice. If one were to write an article on how NOT to ensure software quality it would look frighteningly similar to this (which is what I experience all too frequently when I work with companies).

I find that often this goes hand in hand with the mistaken notion that we are performing projects as opposed to creating long term stable quality products. In some cases our quality leaders are merely naive or simply unquestioningly following the misguided policies and practices of those who came before. For those who truly wish to understand true software quality, who desire to build quality into a product instead of merely trying to inspect it out, what practices should we use?

The first thing is to recognize that building quality into our software code must begin with those who are building the software, the developers. We might have some nice motivational posters that state quality is everyone’s business, but until we tear down the arbitrary and dangerous walls we have erected (incorrectly taking waterfall to its bizarre conclusion) between development and “testers” we will certainly fail to put quality into the code. Development can ensure the quality comes first by writing tests first and performing true TDD (test driven development).

Sometimes, as Dan North found, developers may be convinced that TDD is a great idea yet find it difficult to implement. This is a great opportunity to inject BDD (behavior driven development) as a means of helping developers with TDD. In fact, I often recommend that BDD style scenarios can be used to express acceptance criteria even if developers are not yet ready for TDD. The tremendous increase in understanding and early inclusion of test cases as expressed through scenarios is the biggest benefit of BDD and goes a long way to injecting quality into our code.

Another technique for injecting quality is the concept of code review. There is nothing like another set of eyes to make sure that our code is high quality before we push it out of the development environment. You may want to go one better and get a more immediate feedback through pair programming. Like many things in software development pair programming is counter intuitive but the quality of code produced by judicious use of pairing far outweighs the perceived “double” expense.

Akin to code reviews conducted by humans is the ability of code to be “reviewed” by software through static code analysis tools. This software can “read” code and determine “quality” through a set of programmed rules. It will, for example, let you know which classes are too long or complex. These rules become instant feedback for code in progress and help us to easily avoid technical debt. For existing code these tools can help us to understand existing code quality and provide us with candidates for refactoring.

Whatever the technique you choose, the key is to understand that quality is something that is built into the code not something that we can inspect out.

30 March, 201523 April, 2015

The Theory of Change & Why I Get In Trouble

organizational antibodies, agile, stock photo

As an agile coach that has been fortunate to work at a good number of clients over the years, you get an opportunity to experience some interesting similarities among clients. Some are tragic, some are funny and some are just downright intriguing. I recently spoke with another agile coach and I discovered one particular pattern that I have decided to refer to as organizational antibodies.

The talk in question was about the on boarding of coaches and things a coach tends to experience in the first few days on the ion. As we talked together and related our war stories I noticed that both of us had a something happen to both of us early in our engagements with companies. That common denominator was that both of us found ourselves in trouble with management in the new company within the first week or two of our gigs with our coaching ability or competence questioned or tested.

To hear that others shared my knack for getting into hot water early on was a relief to me. Of course, all of these early issues were resolved in short order, but it brought up a very interesting question of why this happened so frequently. As I look back on my personal experiences and after hearing the same from my colleague, a theory began to form in my mind. The end result is my Organizational Antibody Theory of Change.

The theory is this – there are many in any company who benefit from the status quo. Agile is about organizational change and those who prefer the status quo will find the agent of change as a threat to the corpus organizationus and will do their best to protect their system by attacking the agent of change. In other words, there are people in your company that perform the same role that antibodies provide in the human body.

At this point in my career I fully expect to have at least one of these reactions in every gig I start within the first couple of weeks. In the past it was quite disconcerting for me but now that I have experienced it and expect it, I worry less. The problem is always a tempest in a teapot, a minor annoyance that will fade away as my role is better understood and people realize that I am not a threat. Have you ever experienced organizational antibodies before?

3 March, 20153 March, 2015

The Gang of Four – How Optimization Perseveres

It must be the new year that has me waxing nostalgic again. My last post was of rockstars past and while I was working on that on that one I was also reminded of some others I had a great affection for, a group that I was a part of we called the “Gang of Four”. This was a tongue in cheek nod to the Gang of Four who were authors of a book on design patterns.

The impetus for the Gang of Four was the desire of four agilists to try to do the right things with regards to implementing agile and scrum – to do things that were generally acknowledged as good agile practices but things that were not necessarily politically palatable. In other words, we were something of a clandestine organization. In fact, our meetings, while not in a secret location, were held in a location well off the beaten path – so much so that some of us had to literally walk 15 minutes to get to our meeting room. Over time we added another like-minded individual but kept the original name. Hell, we even had a ironic salute we would give to each other when we would pass in the hall. It was in the company of these wonderfully dedicated people that I spent the most enjoyable time I had on this gig.

What is important and pertinent to this blog is not the nostalgia or shout out to my compadres (though it pleases me to think they might read this and reflect with happiness), but that regardless of your office politics, your cronyism, your brown-nosing, your ladder climbing or your sheer incompetence and general ineptness, there will always (or rather you should hope there to always) be those who will have the uncompromising desire to succeed in spite of your inanity.

Like a tree whose roots will break rocks in order to drink of the water that sustains it, there will be individuals and teams in your company that will persevere against the all odds to do what is right, to do what is best for the company. Seek these out and when you find them give them the environment that they need because if they survive on rocky soil just imagine what they can do on a proper plot of earth.

Long live the Gang of Four.

3 February, 20158 February, 2015

Timely Feedback – Why Agile Works

Most folks who know me well know I like to talk.

I especially like the times when I get to speak in front of groups, whether a face-to-face presentation, a small user’s group or 160 on a conference call all over the world (If you have a group and want a passionate speaker – feel free to call on me).

Sometimes my passion provokes long stories, explanations or asides. Lately though when I speak to others about why agile works, I eschew my sometimes verbose ways and reply with two words – “timely feedback”.

These two words refer back to my argument that software development is, as described by Snowden in his Cynefin Model, complex as opposed to complicated. And complexity begs for timely feedback.

Take a look at the most popular Agile processes and practices and you can see why they are effective. They all are merely ways to produce timely feedback.

Daily standup = daily feedback.

Review, retrospective, grooming, planning – all are timely feedback.

What is automated testing on code check in or continuous integration and deployment? Feedback. Pair programming is nothing more than continuous immediate feedback.

Conversely, what is waterfall than a dearth of feedback? Compared to the continuous timely feedback of agile, waterfall is a vast wasteland of opacity.

So next time you are asked why agile works, or why a shorter iteration is better, or why we should do pair programming, or why continuous integration, take the quick route and prove that brevity is indeed the soul of wit and simply say, “Timely feedback”.

– Larry Apke

1 December, 20141 December, 2014

Deming, Agile and SAFe

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?