Monthly Archives: December 2010

To Deliver the Project at Hand, or Improved Project-delivering Capability for the Future?

[From the Archive: Originally posted at Amplify.com Dec 30, 2010]

Dadi Ingolfsson (@blubberplinth) asks me to “please open” the “tricksy can of worms” (my comment) which his tweet (see below) raises.

Note: His tweet, amplified here, was in response to my own tweet:

“Should e.g. Scrum Masters, Agile coaches be more vested in success of “the project“, or in #agile adoption in the organisation?”

So, the core question – in my mind at least – is “Should folks focus on delivering the project at hand, or on delivering improved project-delivering capability for the organisation, for the future?”.

I can’t deny that to be an effective coach or Scrum Master within a specific project team, the coach must have the trust and confidence of that team. Such trust and confidence is rarely won easily, and this challenge is compounded when the coach has a different agenda (goals) from the team (irrespective of whether the team knows this explicitly).

Let’s remember that not every team is itself focussed on delivering the project as their highest priority. Setting aside the pathological cases – such as where the “team” is not actually a team (and therefore has no shared goal(s) as such), or where the team’s aspirations lie elsewhere than delivering the project (i.e. in CV enhancement, or in finding a new gig for the team) – the team may actually have valid priorities other than the delivery of the project itself. In particular, the team, directed by e.g. senior management, may already be working on improving their own – and the organisation’s – capabilities in the longer-term (i.e. post-project).

And of course, this is most often not an either/or situation (although rarely does capability improvement make it into the explicit objectives – a.k.a. requirements – of a project).

Capability improvement – i.e. getting better at delivering projects over the longer term – is central to some (but not many) agile adoptions. And most often in these cases, it’s the Agile coach or Scrum Master that is expected (e.g. by senior management) to be the locus of effort to this end. And they will be held accountable in such circumstances for any perceived shortfall in such improvement – whether agreed and articulated, or not.

Typically, then, when capability improvement in on the client’s agenda, the coach has little option but to include this within his or her remit. (Aside: I would suggest that it’s in everyone’s interest to make this agenda clear, unambiguous and explicit, with quantified (capability improvement) objectives as part of the project’s collection of non-functional requirements. Your project does have a set of actively-managed NFRs, doesn’t it?).

Asking a project team – who are likely already fully-committed to just delivering the project – to also deliver useful capability improvements back into the organisation (as an ‘extra’ or side-effect) is a recipe for grumbling and dissent, at best. Put another way, expecting a team to contribute capability improvements without allowing for the additional time and effort required is likely to cause friction, and if the coach or Scrum Master is seen as the person who is pushing the extra workload onto the team, all the worse. And we’ve all seen what happens to “lessons learned” exercises at the end of most projects, especially when the team is then disbanded (don’t get me started on those particular dysfunctions!).

My apologies if this post rambles rather more that usual, but I did start out by saying the subject was a “tricksy can of worms” :}

In summary, I agree that if a Scrum Master/Coach is to be a real, accepted, trusted member of a team, he/she needs to commit to that team more than to an agile adoption (a.k.a. improving capability). But actually, reality says that a delicate balancing act is the order of the day, because there are a number of stakeholding parties and constituencies involved, each possibly wearing several hats and having several (possibly conflicting) needs from the project, the team and the coach.

Amplify’d from twitter.com

blubberplinth @flowchainsensei I say, if a Scrum Master/Coach is part of a team he needs to commit to that team more than to an agile adoption
Read more at twitter.com

– Bob

Postscript

This situation (i.e. the existence of implicit and/or explicit requirements for improvements to organisational capability) is (yet) another reason why agile adoption is more tricky than it may superficially appear. And another reason why good/great coaches / Scrum Masters who understand this stuff can really earn their coin.

Agile/Lean Principles Simply Will Not Scale

December 29, 2010

Agile, Archive, Ex-Amplify.com, Organisational effectiveness, Snippet

Agile/Lean Principles Simply Will Not Scale

[From the Archive: Originally posted at Amplify.com Dec 29, 2010]

A somewhat contentious title in this clipped post (intentionally on the part of the author) but a post congruent, in general terms, with my recent “State of Agile” piece.

Amplify ’d from www.linkedin.com:

Agile and Politics Like Oil and Water
Agile/Lean principles will simply not scale. Ah good now I have your attention. The truth is that Agile development can scale in small, medium, and large companies, but they typically won’t. Now I am not saying this to upset Agile and Scrum purists. I have had the opportunity to work in small development companies (i.e. iLinc Inc.), medium size companies (i.e. Syntellect, Inc.), and larger companies (i.e. US Airways, GoDaddy.com), and I can tell you that Agile, for the most part, is not working there. It has been over 9 years since Agile was first introduced as a development methodology. Agile was developed during a ‘pow wow’ in Utah in February 2001. For more details on this please check Wikipedia (http://en.wikipedia.org/wiki/Agile_software_development) or the Agile Alliance website (http://www.agilemanifesto.org). Today there are more and more software development companies adopting Agile, Lean, and more iterative development practices and methods. The idea being that they can increase the quality (or at least not lose any) while simultaneously speeding up the “Time to Live”. This is a great thing; however here is the problem.
Now how does this relate back to Agile? Well if Agile will expose waste, and your job is pointless, then guess what? You are out of a job.
Therefore when Agile is introduced into a large company with a lot of these unnecessary positions, those people are in big trouble. Of course, if these people can get management to somehow not by into the Lean/Agile approach to doing business, then they may keep their positions.
In an attempt to shed a little light on this topic I would like to offer an approach to this issue where those who are “hiding in the details” to find a place in the new methodology.
First: Be the scrum Master. Now this topic could be its own article and I may actually write one on it one day, but lucky for you today is not the day. Just know this a Scrum Master is the person with the least amount of control or influence. A big problem is that development managers freak out and jump on this role because they think it is the one with the most control over the team. Sadly it is not. The scrum master is more like a waiter in a big restaurant. They are the servers to the team. The reason
development managers take on the role of a scrum master is because they hear that the team is “self-organized” and therefore they are no longer needed. Again this is not the case. A Scrum Master, is the process cop. The scrum master is the organizer and assistant to the team. This would be a great role for someone that can make the move to learning how Scrum or XP SDLC should be done, and not have a vested interest in the success or failure of the project.
Second: Be a SME (Subject Matter Expert). As you have been in your role for a long time you surely have picked up a few details and tribal knowledge that needs to be shared. Take that information and offer it up as part of the team. Help with the requirements gathering and defining of acceptance criteria. This will be very important as the team needs to capture this information as early as possible in the process.
Read more at www.linkedin.com

– Bob

#lru2010 Conference Report

December 18, 2010

Archive, Ex-Amplify.com, Rightshifting

#lru2010 Conference Report

[From the Archive: Originally posted at Amplify.com Dec 18, 2010]

The first London Rightshifting Unconference took place Friday December

17th from 12 Noon through to circa 6 PM, at London City University, EC1. This is my report of the event.

Sessions

As this was an unconference, our first order of business was to find
a structure for the day that suited all attendees. After a short
discussion, we settled on a kanban-like backlog of session headings, each of nominally twenty minutes (and open to revision throughout the day). At the end of each twenty-minute session “slot” we then chose the next most interesting / important item, by consensus, for the next session (given a ten-minute break). This seemed to work well (although time did not allow us to address every item in the backlog).

Backlog

30-Minute Run-through Of Rightshifting Basics
Experience Reports (from the Field)
Barriers to Introducting Rightshifting e.g. Fear, Uncertainty and Doub
Alternative Views
Introductions
Desired Outcomes for the Day / Next Steps 7. Overcoming “Well-known” Myths
Measurement
Dreyfus Model

Sessions as they Happened

1) 30-Minute Run-through of Core Rightshifting Ideas

By popular demand, I myself (@flowchainsensei) hosted this first session, with the aim of refreshing folks’ acquaintance with the concepts of the Rightshifting idea, including the Marshall Model. Given the degree of conversation that ensured, the group decided to continue for more than the allotted thirty minutes. The session centred around a slide deck I had presented to the London Limited WIP Society earlier in the year (see: The Bigger Picture)

Key points emerging from this conversation

Rightshifting is an awareness campaign, founded on Sir John Whitmore’s ARC principle.

Not only do most executives not realise the massive scope for improved effectiveness within their organisations, but most people working in those (relatively ineffective) organisations will never have experienced life in more-effective organisations, nor even realise that these exist. Absent this fundamental awareness, Rightshifting suggests that few people will see any need to take responsibility for doing something about the relative ineffectiveness of their own organisations, let alone commit themselves to taking any action(s).
Rightshifting is not another method, or solution. It does not tell organisations WHAT to do to become more effective, only that significant gains are there for the taking. In my travels, seeing hundreds of tech businesses, the common theme has been the lack of engagement with the desire to do anything about the status quo (almost universally, a significant, unappreciated level of ineffectiveness as an tech organisation or tech business).
With the Marshall Model, Rightshifting describes the challenges facing tech organisations contemplating a journey towards significantly improving their effectiveness, and how that journey will be a series of punctuated equilibria.

2) Experience Reports

Some folks have already been using Rightshifting ideas and the Marshall Model in conversations with clients and customers. This session invited folks to share such experiences.

First up: Ant Clay (@soulsailor) of 21Apps related his very recent experience (this week!) of presenting the Rightshifting curve and the four mindsets to one of his current clients. I personally found it both interesting and gratifying to hear the extent to which his clients (senior managers) quickly embraced the Rightshifting idea, and in particular used the vocabulary themselves to better articulate and discuss their business strategy and aspirations for the business (along with the role of technology therein).

Ant also took this opportunity to address (in part) the backlog item “Alternative Views”. Given his company’s focus on Sharepoint as an Enterprise solution, he explained his view of how Rightshifting helped 21Apps articulate their USP (Unique Selling Proposition) and Positioning to their clients.

Following on from Ant was Grant Rule (@pg_rule) of SMS Exemplar, who related the tale of his company’s two-year association with a major European technology manufacturer in trying to help them get a major organisation-wide improvement programme off the ground. This engagement has been using Rightshifting throughout (and latterly the Marshall Model too) as the glue with which to build a consensus on change amongst all the many and varied stakeholding groups involved.

3) Introductions

In this session, the ten attendees took turns to introduce
themselves, explain their interest in, and use for, the Rightshifting concepts, and talk about what they’d like to take away from the event. In summary, most folks attending are “tech” people, including a couple of CTOs, some consultants, some coaches, and others, all with a common interest in understanding what makes for an effective technology business and a desire to help such organisations also understand the massive latent opportunities for improving effectiveness.

4) The Dreyfus Model of Skills Acquisition

Liz Keogh (@lunivore) presented this excellent session, relating her experiences of applying the Dreyfus Model with some number of her clients, most notably, at Screwfix Direct Ltd. After a short summary of the purpose and levels of the Dreyfus Model, Liz provided us all with some very useful hints and tips on applying the Dreyfus Model in the real world. Given that the Marshall Model is subtitled “Dreyfus for the Organisation”, the latter was of particular interest and value to me personally.

Note: The Dreyfus Model generally has five levels, whereas the Marshall Model has seven. This difference is intentional – can you think why this may be so?

5) Wrap-up

In the wrap-up session, we had a wide-ranging discussion wih the general aim of ensuring that everyone attending had got as much out of the day as possible, filling-in any remaining gaps or omissions.

This wrap-up session included a brief conversation around next steps for the Rightshifting movement, not least regarding the future of #rshiftchat, our regular weekly Thursday evening tweetchat (presently suspended until the New Year). NB If you have any ideas or preferences for building the Rightshifting community, and movement, including the future of #rshiftchat, please get in touch, or preferably, comment on this thread.

We also discussed the possibility of another unconference in London next Spring, as well as similar events in other geographies soon.

My thanks go to all who braved the nasty weather to attend and contribute, and my special thanks to Dr Andrew Tuson, David Chan, and City University for providing such a fine venue, and support.

As ever, I am happy to provide more information, explanation, etc, as well as welcoming your input and comments.

– Bob

References

This is just a short list of the references I heard mentioned during the event. If you’d like to understand why they were mentioned (e.g. context), please get in touch.

Note: there are many more (book) references on my website. (Attendees – please help me out by adding further references via comments on this thread).

“Dirty Little Secrets” ~ Sharon Drew Morgan
“Coaching for Performance” ~ Sir John Whitmore
“The Marshall Model of Organisational Evolution” ~ Bob Marshall
“Managing Transitions” ~ William Bridges
“The Satir Change Model” ~ Virginia Satir
“The Unfreeze/Change/Refreeze Model” ~ Kurt Lewin
“Great Boss, Dead Boss” ~ Ray Immelman

Would You Rather Not Know?

December 5, 2010

Archive, Ex-Amplify.com, Organisational effectiveness

Would You Rather Not Know?

[From the Archive: Originally posted at Amplify.com Dec 5, 2010]

Would You Rather NOT Know About What Makes Organisations More or Less Effective?

I’ve had some folks ask me recently as to the point of knowing this information, given that many developers, staff in general and even middle-managers feel that they have little influence over wider business issues and how the work works, end-to-end, within their organisations.

Correlation or Causation?

Is there a correlation between organisational mindset (how the people within an organisation perceive the world of work) and the effectiveness of that organisation? If so, is it a simple correlation or is mindset in fact a causation of (high, or low) effectiveness?

The Marshall Model

The Marshall Model proposes that this is a causative relationship. That is to say, that the prevailing mindset in an organisation directly dictates the effectiveness of that organisation. And moreover, to realise any significant improvement in effectiveness requires that the organisation changes the way it looks at the world of work (its prevailing mindset).

So, maybe learning what makes organisations effective only leads to distraction, frustration, unhappiness and a kind of learned helplessness?

I suggest this proposition is flawed. And only serves to disempower people and perpetuate organisational homeostasis (aka the status quo).

Further, I believe that developers – and others – that come to understand the cause of organisational effectiveness can do much to help break the log-jam of organisational homeostasis and contribute to “Rightshifting” their organisations.

The “collective mindset” of an organisation may seem like an abstract, nebulous and difficult-to-wrangle animal, but in fact, organisational mindset is little more than an amalgam of the mindsets of the individuals within the organisation, underscored by implicit and explicit policies, with a modicum of history thrown-in.

Collective Mindset is Key

So it seems to me that, with knowledge of the key role that mindset plays in organisational effectiveness – and assuming some degree of positive motivation to change things for the better – everyone within an organisation can help effect positive change. At its simplest, folks can simply begin talking about the subject, with their friends, colleagues, fellow team-members, peers and management.

The Japanese concept of ‘ba’ may have relevance here. Nonaka et al suggest that we take ‘ba’ to mean ‘place’. It is a here-and-now coming together of physical, virtual and mental spaces, which together constitute a shared “context in motion” for tacit knowledge to become explicit. In other words, a concept of a place ‘where shared meaning can emerge’.

This requires little in the way of sanction, support or coordination from the top. A crucible or place (“ba”) for regular dialogue can help, certainly – in due course.

Granted, active support and coordination from the CEO or MD is vital in transforming a vertically-organised, siloed organisation into one where horizontal value-streams are the preferred mode of operation.

But CEOs, MDs and such are more likely to act if they feel that people within their organisations already have a basic grasp of the issues, and a relatively positive disposition towards, and a sense of ownership in, potential changes.

– Bob

—Think Different

Making Lives More Wonderful

Archive

Monthly Archives: December 2010

To Deliver the Project at Hand, or Improved Project-delivering Capability for the Future?