Munish Malik - In the overwhelming times of frameworks & certifications, would going back to basics of agile improve the software delivery outcomes?

What is the background situation/context for your probe?

In my interactions with several agile coaches and practitioners across many organisations, not many are talking about the core values and principles of agile, or how those basic foundations are being interpreted in individual environments to help the overall software development processes and outcomes. Rather the conversations have circulated more to see how certain framework and processes are being followed. I’m sharing a few of those excerpts. Following is a satirical attempt to those conversations:

Mr. Agile Coach (AC): Oh and you haven’t tried BDD!

Me: Yea, I am still learning. But I do know GDD (winking)

AC: And what is that? Never mind, are you SAFe certified?

Me: Umm, I thought it is fine to be unsafe... You know, running experiments, validating hypotheses, failing fast. All that kind of stuff.

AC: No I meant, are you Scaled Agile Framework certified? I am especially interested in v4.6.

Me: (coughing) No sir, I like being unsafe. Just kidding! I attended a couple of talks around SAFe, and I couldn't relate to it. So I left it at that.

AC: Do you know extreme programming?

Me: What about XP?”

AC: Can you tell me the 4 XP values, its 5 principles and 4 core activities?

Me: No

AC: I saw some stuff you’ve done around User Story mapping and Impact mapping.

Me: Yes, I find those techniques quite useful in ironing out a product roadmap and doing prioritisation.

AC: Those techniques are flawed. Have you tried feature injection?

Me: I’ve read some blog posts around it, but I haven’t really tried it yet. Happy to learn.

AC: In your paper, you say you’d do less when you have more time. Don’t you know the business would give you more work when you have more time. Scope will increase when you have more time.

Me: What I meant was, sometimes you can achieve better outcome and impact sometimes by doing less. And finding things to remove in a product than to add. I put a popular quote in my paper in that context “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away”. I also shared some examples of the products that are doing that, so I meant it in that context. 

AC: You have mentioned a technique of using business sliders.

Me: Yes. I use that to find the glass balls of my project that I need to take care of.

AC: I haven’t read any ‘Agile’ book that talks about such sliders. Also, the budget is always negotiable so I can’t really understand the usefulness of using sliders.

What is (or has been) your hypothesis?

My hypothesis is that we need to go back to focusing on strengthening the foundations of agile rather than getting drowned in specific implementations of Agile. The foundations that have been written very simply in the agile manifesto.

I liked to relate my hypothesis to the following quote: “In times of life crisis, whether wildfires or smoldering stress, the first thing I do is go back to basics... am I eating right, am I getting enough sleep, am I getting some physical and mental exercise everyday.” - Edward Albert

In the context of agile software development, paid certifications and dogmatism to fit software delivery in certain agile frameworks is what I would call crisis and wildfires. And the basics of the agile manifesto is what I would choose to be referred more often so that we can interpret them to understand what they would mean in our individual environments or for the outcomes that we ought to achieve.

What is the experiment you would like to run (or you have run) and how can this experiment validate or invalidate your hypothesis?

Can we go back to the agile manifesto, look at the principles and evaluate our work in those aspects rather than trying to fit our processes to certain implementations of agile methodologies. For instance this 'may' mean emerging with something like OKRs that can be attempted to apply to that particular software delivery organisation. Or going a step further is there a way that those OKRs can be attempted to apply to most software delivery organisations? As an example, if our objective is to value working software over comprehensive documentation, then what would that mean in our individual environment? Is there a way that we can interpret and apply this to most software delivery organisations, irrespective of the specific flavour of agile that they adopt?

For instance, I find the work done by Jez Humble and Nicole Forsgren very inspiring, to measure software delivery performance of organisations through four key metrics as specified in the book ‘Accelerate’. Can we do something similar when it comes to the process aspect? Can we find ways in which we can simplify the implementation of agile through measurements that can make sense to most software delivery organisations?

Another way to experiment this could be through real stories. How some companies across the world could be implementing agile in a simple and pragmatic form, focussing on the basic values and principles without getting too prescriptive about it and without getting themselves attached to doing things in a framework oriented manner.

These could be a couple of experiments to look into.

Is there a specific skill/technique you would like to learn/explore at this coach camp?

I am keen on learning how the community has been introducing change in big organisations that are operating like startups. Organisations that are still pathological and bureaucratic in their culture, yet are fast moving in their business goals and have a tendency to disrupt the market. 

Call for Papers CLOSED
Ended on Jan 25 '20 05:29 AM IST

Interested in attending the Agile Coach Camp on Oct 11th in Bengaluru? Read on...

It's been 12 Years and almost 110 viral Agile Coach Camps since our very first coach camp experiment. This year, Coach Camp co-creator Naresh Jain along with Jutta Eckstein and John Buck will lead participants in this Coach Camp in Bangalore, organized as part of the Agile India 2020 Conference.

Coach Camp Theme

As a coach, you're often the one who needs to drive and sustain change. Yet, how do you do this? What has helped and hindered you doing so and how can you best pass your experience on to other coaches or how can you best learn from other coaches?

This is the theme for this year's coach camp. To tackle this challenge, we invite you to try something new:

  • Currently, we face the following situation: Constantly driving change is getting more and more important for companies to survive in this VUCA world. At the same time, it is (or should be) the core skill of every coach – no matter if you coach individuals, teams, or organisations. However, sometimes it seems every coach has to come up with her own experience on how to drive change successfully.
  • Our hypothesis is that for driving change, every coach uses so-called probes, that are defined by small, safe-to-fail experiments based on hypotheses derived from reflection on the current situation as well as on theory. So, probing allows discovering (based on the hypothesis) what's working and what is not through one or several experiments. This allows to make sense of both the current situation but even more important of the situation we are aiming for. And if we create a knowledge base of our collective wisdom on probes we used (or intend to use) we can learn from each other.
  • Therefore, as an experiment we want to invite this year's coach camp participants to jointly discover, share, create, improve, and finally publish probes that help(ed) driving and sustaining change. As in a typical coach camp, we will use the Open Space format to explore different topics for driving change and we invite you to use probes to focus the discussions on these different topics. We anticipate as a result that the discovered and created probes will provide a foundation for such a knowledge base.

Registering for the Coach Camp

The coach camp is free of charge (financially) yet, for registration we ask you for the following:

  • Please click on the Add Paper button and submit your position paper. In your position paper, you will be asked to share an idea for a probe, consisting of a background situation (context), a hypothesis, and an experiment. This can be a probe you've implemented before, one you've discovered/heard of others implementing it, or you intend to implement. The probe should focus on the coach camp's theme: Driving Change.
  • The discussed probes provide a basis for a free and publicly accessible knowledge base.

Final Note

Please note, we want to invite you to use probes for the discussion and recording of the Open Space sessions. This is by no means an enforcement. We are well aware that there might be situations where probes are not the right means for discussing or/and recording a particular topic - and that is of course fine. After all, using probes for this coach camp is a probe in itself (and we are open to possibly invalidate our hypothesis.)