Fighting the good fight (A personal parole)

Recently, Bob Marshall (@flowchainsensei) has raised his lashing of agile and all its manifestations to a frenzy. His language has become ever more dramatic and sensationalist, culminating in a post entitled 'Agile Coaching is Evil'. To understand what the point of all this might be it is essential to read another post of his; 'On the Morality of Dissent'.

If you can peel back the layers of irony and provocation - all this talk of morals and ethics and Good and Evil – then there is certainly value to be discovered in what is being said. I continue however to disagree fundamentally with much of the detail of what Marshall is promulgating, even as I find his stated goals honourable and worthwhile. Yes, I am an agile coach.

I view the three main points of Marshall's argument in 'Agile Coaching is Evil', points that he makes repeatedly over many channels, as:

1. Tackling partial problems leads only to more problems – systems must be addressed holistically otherwise any change will eventually be swallowed up by the system.
2. Effectiveness being a function of mindset implies that significant change can only be realised once a radical and wholesale philosophical shift has been effected
3. Anyone purporting to help an organisation improve its effectiveness by way of local optimisations is at best naïve, probably disingenuous and possibly plain corrupt

Let's start with the holistic systems-thinking argument. It is in fact, easily dismissed:

There is no point in addressing problems in your software development organisation because the organisation around it has not yet changed its mindset (had its mindset changed? brainwashing, hypnosis, how does this happen?), therefore any optimisation achieved within your sw development organisation will eventually be nullified or even reversed by the immovable object of the mindset of the departments adjacent to it in the value chain. Okay. Say we effect mindset shifts in product management, sw development and operations? Not enough - finance, sales, customer service etc, still have not moved so eventually the local optimisation will be swamped by the inertia of the rest of the organisation. And so on until the company has somehow instantaneously leaped the mindset chasm as a single organism. But wait. Then there is the system that is the markets in which the company operates. If said markets haven't changed their mindsets in the meantime the company we have been talking about is doomed, after all, it will eventually succumb to the mindset of the greater system in which it, sub-system, is embedded. Etc., ad infinitum.

There is much of use in systems-thinking, and its focus on people and their empowerment can be found in agile, lean and the Cynefin model (complexity). In all these other cases however there is either the implicit or explicit recognition that everything progresses in small steps. In the case of Cynefin, which specifically addresses complexity and our inability to use reductionism to solve certain problems (initially), it's interesting to note that a heuristic like 'fine-grained objects' is prevalent. Wicked problems are untangled strand by strand. Possibly also interesting to note at this juncture is the fact that much of what one might do in the complex domain in the Cynefin model is aimed at moving problems into the complicated domain. Black-box observation with the specific aim of making reductionist analysis possible!

Regarding mindset shifts as a pre-requisite for increased effectiveness:

I think that Marshall has this exactly wrong. Strangely enough this would seem to be a position he has arrived at since he first published his Marshall Model, sub-titled as it is “Dreyfus for the organisation”. The Dreyfus model of skill acquisition, as with other learning models, implies that insight (mindset) follows practice and not the other way round. In other words, Marshall's insistence that effectiveness follows mindset is in my opinion, the misattribution of cause and effect to an observable correlation. I would posit that mindset is an emergent property of practice. More correctly, practice informs mindset which in turn informs practice – a positive (meaning re-enforcing) feedback loop. There is no conflict here with the observed mindset leaps at the boundaries of the organisation types in Marshall's model. Punctuated equilibrium is not an alternative to gradual change, it is its manifestation in the real world; phase shifts are the result of cumulative change in combination with tipping points.

If Effectiveness = f(Mindeset)
         and Mindest = f(practice)
then Effectiveness = f(practice)

Rightshifting phases - copyright 2010 FallingBlossoms.com

On local optimisations and the nefariousness of their champions:

It is possible to learn without a teacher, in some ways it might even be better (conjecture; one might continue to nourish a beginner's mind more easily), but it is almost certainly the slowest way to learn and autodidacts are often hampered by strategic weak spots in their conceptual armoury. There are of course always bad teachers, in every domain.

In my role as coach, I pursue small modifications in local practice and understanding, while keeping an eye on the bigger picture. Does this make me naïve, disingenuous or corrupt? I can't be accused of naivete precisely because I realise that change, if achieved at all, happens in small steps. Because I communicate exactly this to (prospective) clients, and always start any discussion with an enquiry as to why agile, I am not disingenuous. If my only motivation were my pay cheque I would be corrupt. I am however motivated primarily by the conviction that work for most people is unnecessarily miserable, a drudgery to be survived rather than a fulfilling and rewarding part of life. I feel that the agile manifesto can help and that it is as relevant today as it was ten years ago. The only thing required to make it universally applicable is to replace 'working software' with 'concrete product' (or some such).

I shall continue to try and execute workplace coaching transparently, on the basis of high bandwidth communication, and regularly vetted by concrete results, as a force for good in the world.

Introduction to scrum (A retrospective)

A few weeks ago I wrote about how our first workshop came about and what we had learned from it. As luck would have it, the same day that we ran that first workshop, I received a message from an ex-colleague of mine, Leonie, who was working as a business analyst at Second Floor. This small company is dealing with the difficulties of success – growth is so strong that their existing processes, which have worked well up to now, are beginning to hinder progress. One of the things they were considering in an effort to manage their success, was a transition to scrum (which some teams had already partially implemented) and they were looking for project managers versed in same.

Although I had to disappoint Leonie in as much as I am not for hire as a project manager we quickly agreed that there was potential for mutual benefit in our respective situations; Qualogy could assist Second Floor in a transition to scrum, while Second Floor could help Qualogy through structured feedback on our expanding workshop portfolio.

A meeting was arranged to discuss possibilities. We agreed, with the delivery manager and technical lead at Second Floor, to kick-start possible further cooperation with an afternoon workshop as a general introduction to scrum. If that delivered enough learning and was generally well received we would talk about collaborating for the entire transition. At that point we had already agreed in broad terms on what a transition would look like; it would progress team per team (teams already comprised all the skills required to deliver working software) and would comprise a series of workshops and some targeted coaching.

First things first though; we needed to create a “Scrum basics” workshop that would leave a bunch of very smart, semi-initiated (in terms of scrum and agile) and fully dedicated professionals with an appetite for more. From our previous experience we were very aware of the need to run any workshop as a series of broadcast-interaction cycles, but we only had a half a day for the session and we wanted to ensure that the basics were thoroughly covered. The urge to take the easy way out and create a presentation (broadcast) with a high wow-factor (assuming we could do such a thing) was strong!

Our discussion with the delivery manager and the technical lead at Second Floor had indicated that there were some obvious (and relatively inexpensive) opportunities for process improvement, quick wins if you like. We were considering the possibility of creating hooks in our presentation-to-be for these basic improvement experiments (e.g. keeping sprint length stable) when Wouter made the inspired suggestion of setting the workshop up along the lines of a retrospective. The fact remained that it would not be trivial to involve our audience actively enough while ensuring that we covered the basics, but a retrospective framework (we used Derby & Larsen's Set the Scene-Data Gathering-Generating Insights-Decide What to Do-Wrap) provided an excellent starting point for attempting just that.

We set the scene in a half an hour by introducing ourselves, relating how the workshop had come about and how things might develop thereafter. We explained how the agenda had been set up, how we intended to make the material covered as relevant as possible to Second Floor, and how we wanted to garner feedback throughout the afternoon. This was followed by a short broadcast including definitions and an extremely brief history of both scrum and agile.

To gather data, we used a (familiar) brainstorm; we asked everybody to think about the process at Second Floor and to organise their thoughts by writing down (on sticky notes) what they felt was good about their process, what was bad and what could be improved. Notes were added to a prepared flip chart in the relevant category. We then asked the group to collate and de-duplicate the notes in the various sections. Using dot voting we generated a shared view of what was most important to keep doing, and what needed changing most urgently.

Then followed three Generating Insights/Decide What To Do cycles. Each cycle was built around one of the scrum roles whereby a short broadcast was followed by some Q&A and finally an explicit effort to connect some of the material just covered with specific points raised via the brainstorm. Envisioning how exactly we would make that explicit connection beforehand was difficult; we obviously we did not know what would come out of the brainstorm. On the other hand we knew that there were some quick wins to be had. At the same time, we wanted to avoid obviously guiding people to pre-defined conclusions using leading questions.

Eventually we decided to formulate a list of quick wins per role/section as a list of Try.../Avoid... pairs (à la Larman & Vodde) and play it by ear. If during discussion following a given broadcast, an obvious opportunity to make a link to the Try.../Avoid... pairs presented itself we would capitalise on it. Also, and alternatively, if discussion stalled we would introduce the appropriate Try.../Avoid... pairs as a catalyst for conversation. Organising the information according to the scrum roles worked well; it provided a natural framework for covering required ground on artefacts, ceremonies and rules while simultaneously detailing varying perspectives. However, in spite of (or maybe precisely because of) energetic discussion with the group, we struggled to connect to the results of the brainstorm in the fashion that we had hoped.

We wound the workshop up with a retrospective. We had chosen a combination of the Happiness Metric and the Perfection Game as feedback mechanisms. Feedback from the Perfection Game was again very useful, if challenging. Positive feedback regarding the brainstorm and the general structure of the workshop was tempered by the fact that we had struggled to explicitly incorporate the results of the brainstorm into further proceedings. This was not lost on our audience who complained via the Perfection Game of occasionally missing the relevance to their own situation.

Another interesting aspect of the feedback from this session was that it seemed to contradict itself at times. While some participants felt that we had spent too much time on certain basics, others complained that we had raced through concepts that were not yet familiar. The Dreyfus Model (a modern variant of Shu Ha Ri if you will) provides insight here, although not necessarily a neatly packaged solution! The Dreyfus Model works on the premise that a person's level of training or expertise on a given subject will dictate the best way for them to gain further proficiency in that field. In the extreme that means that the kind of instruction best suited to beginners (context-free instruction to be followed to the letter) is useless, even potentially damaging, to experts honing their intuition. And vice versa. As yet, we are not decided on how to deal with this insight.

This workshop was important for us on several levels. Particularly satisfying is that fact that we have added another increment (Scrum Basics workshop) to our product (Agile Coaching service) while refining (that is; iteratively improving on) already existing elements of same on the basis of (potential) customer feedback. We are hoping that our extremely collaborative approach will serve the double function of setting us apart in an increasingly competitive market while also ensuring that our customers get what they want, much as that may change along the way.