Archive

Monthly Archives: May 2013

The Same Old Way

May 30, 2013
Agile, Product development, Software development
15 Comments

The Same Old Way

“They came on in the same old way – and we defeated them in the same old way.”

~ Arthur Wellesley, First Duke of Wellington

As someone who develops or tests software, how well do written requirements – a.k.a. “specification documents” – meet your needs?

Have you, in fact, ever thought about the ways in which you come to understand what needs to be implemented?

Or do you just take for granted that there will be business analysts cranking out specifications in the same old way, and you’ll be poring over them in the same old way, ad nauseam?

Who Serves Who?

Do you see your business analysts as the experts on the expression of requirements, and defer to them in such matters? Or do you have a more of dialogue about your needs as implementors, and about how they (the business analysts) might best serve you and your needs?

The Agile Thorn

In Agile development, of course, three of the four core values in the Agile Manifesto are:

  • “Working software over comprehensive documentation”
  • “Individuals and Interactions” over processes and tools”
  • “Responding to change over following a plan”

I have long chosen to interpret this as meaning that developers and the people with the detailed vision of the product – if not one and the same – get together as interacting individuals and explore, exchange and refine their common understanding of the emerging “requirements” by building working software – and not by cranking out and then working from comprehensively documented requirements specifications (in effect, a plan a.k.a blueprint).

Aside: My thanks to @michaelbolton for providing the related insight that the content of requirements specifications (documents) are much too often mistaken for and confused with the “real requirements” i.e. what the users, etc. of the software, product or service might actually want.

Who Leads Who?

As a business analyst, have you explored the needs of the implementors, with them? Inspected together how you and they come to understand what needs to be implemented, and adapted to best – or at least, better – meet those needs?

Who is better placed to initiate or lead this kind of dialogue? Does this fall under the general heading of “Business Analyst expertise” or are the implementors best placed to initiate and/or lead the conversation?

Scrum

Lest we forget, or overlook the Scrum perspective on this subject, in Scrum there are only three roles: “The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master”. Also note: “Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.”

Effective?

So, the core question remains: In highly-effective development work, are there alternate, more effective means for deciding what gets implemented (and incidentally, when) – or is everyone just stumbling along “in the same old way”?

– Bob

Slow Change

May 3, 2013
Organisational Therapy, Psychology, Rightshifting
5 Comments

Slow Change

Progress in learning organisations comes in its own time, at its own pace. Some folks might wish to see that pace accelerated.

“Be careful what you wish for, you may receive it”

~ from The Tale of the Monkey’s Paw

I share the belief of the folks in the Slow Movement, that care, concern for others, the building of meaningful connections and relationships – the bedrock of the learning organisation – is best tackled unforced and unhastily.

“The only thing for certain is that everything changes. The rate of change increases. If you want to hang on you better speed up. That is the message of today. It could however be useful to remind everyone that our basic needs never change. The need to be seen and appreciated! It is the need to belong. The need for nearness and care, and for a little love! This is given only through slowness in human relations. In order to master changes, we have to recover slowness, reflection and togetherness. There we will find real renewal.”

~ Professor Guttorm Fløistad

Where does that leave the frantic clamour for change in most organisations today? For the large part, I’d say it leaves it screaming into the wind. Forcing change faster than its natural pace makes no sense to me, bringing as it does a whole host of inevitable dysfunctions, such as stress, disassociation, and disaffection.

Better, I think, to take things as they come, to take careful steps, with maybe a tad of due consideration for progressing in the right direction.

And to take time to see each other as human beings, to encourage a sense of community, of a journey made together, not for the sake of arriving, but for the joy of the journey.

So, when considering the pace of change, would you be willing to fret a little less about seeing things happen faster, and become a little more comfortable with the natural rhythms and pace of events?

– Bob

Learning to Let Go

May 1, 2013
Coaching, Dialogue, Organisational effectiveness, Organisational Therapy, Product development, Rightshifting, Software development
6 Comments

Learning to Let Go

I’ve just come back from six weeks in Delhi, working there with around eighty people engaged in software development – mainly coding and testing – as members of a number of different product teams located in various other geographies around the world.

This post is by way of thanks to the Delhi folks for their hospitality, generous spirit, and humanity – and for helping me (re)learn a valuable lesson.

The Lesson Relearnt

The lesson in question is: people do not learn from hearing things.

I see my present role – of which my time in Delhi was but one example – as fundamentally about inviting folks’ curiosity and interest. No more, no less. In essence I am asking the question:

“Would you be willing to examine with me – or amongst yourselves – your current views and assumptions regarding the field of software and product development?”

Whether they choose to accede to the request or not matters to me – not because I have any agenda for them, but because my needs include making meaningful connections with people, and helping folks’ life become more wonderful. Given the amount of time folks spend at work, I can think of few better opportunities to pursue my needs. If people choose not to engage with my request, I respect that choice, even though I personally see it as a lost opportunity for all concerned.

Letting Go

So, of what am I “letting go”? I’m letting go of the need to be an expert. Of the need to have answers to their problems (I don’t even know their problems, really). And of the need to tell them all about how highly-effective software and product development works. As someone who has been examining my own views and assumptions of software and product development for the best part of forty years, I’m letting go of the idea that I can help people learn and grow by simply telling them things from my own experiences. Unless they ask. And they may not know that asking me is an option.

“We cannot teach people anything; we can only help them discover it within themselves.”

~ Galileo Galilei

Some years ago, recognising the dysfunctions inherent in telling folks things, I used to withhold information unilaterally – until I thought folks were ‘ready’ to hear it, piece by piece. Having learned from e.g. Argyris, Noonan, Kline and Rosenberg, nowadays I try to make it clear that, to the extent that I have any knowledge or information that might be useful to someone, the timing and manner of its sharing can be something on which we can decide together.

I suspect this notion of self-paced ‘pulling’ of information or knowhow is pretty novel to many people. And so I suspect that many may not connect with the notion straight away. At least, not in a way that they might immediately benefit from.

Summary

In summary then, in attempting to help folks have a more wonderful life at work, I believe that if I have any part to play it’s in simply being there, with them, giving of my full attention:

“The quality of our attention determines the quality of other people’s thinking. Attention, driven by deep respect and genuine interest, and without interruption, is the key to a Thinking Environment.”

~ Nancy Kline, More Time To Think

– Bob