Tag Archives: agile

Agile: I Prefer Hype to Ignorance

Posted on by

The good news is that Agile has crossed the chasm (Moore, 1991). On the down side there has been, and is, a lot of hype and hyperbole around Agile, Lean, Scrum, XP and Kanban, etc, etc. In particular, and despite the Agile Manifesto, the meaning of the term "Agile" has become very diffuse. So much so that there are many people, like a colleague of mine and one time Agile fan, who now says "I don’t talk about ‘Agile’ any more; it doesn’t mean anything".

I find the hype annoying, and Agile’s loss of meaning exasperating, but I also think it an inevitable part of progress.
Continue reading →

Side Bets and Sweeties in Organisational Change

Posted on by

People don’t resist organizational change! – People resist being changed!

The Communication Toolbox

My current programme is using new, bespoke software to drive organisational change. So I need people to change what they’re doing. A lot of people. As a first step I need them to adopt our new software. So I am always looking for ways to push the software roll out. In an earlier post I described one approach we use for encouraging adoption: Foot in the Door Technique. In this post I look at two other methods – which we call "Side bets" and "Sweeties".
Continue reading →

Reinforcing Success in Products and Projects

Posted on by

A fundamental military axiom is to reinforce success.

Reinforcing success is a strategic concept used in many areas of decision making and management. Originally a military doctrine, the term is also used in theories related to parenting, business and other fields. It is essentially a selection criterion, or a prioritizing principle. A course of action is selected from various options on the basis of previous results of similar actions. The basic idea is: if it works, keep doing it; if it doesn’t, don’t invest more in something that’s failing.

Wikipedia: Reinforcing Success

I believe businesses should apply this principle to projects, products and product features. So not surprisingly I apply this as a guiding principle in my own work as an agile programme manager.
Continue reading →

Case Study: Motivating a team using Agile practices

Posted on by

A while ago I did some consultancy with an Israeli company that was kicking off a large, complicated and challenging project. They wanted advice on how to motivate the team so I looked in my toolkit – both Agile and general management – and suggested a few things.

It is worth emphasising that the company’s sole concern in this case, and the reason for my engagement, was "motivation" and not Agile per se.
Continue reading →

Managers v Leaders: Are Managers Plodders and Leaders Cool?

Posted on by

I consider myself a good manager and a passable leader. This should be okay but there is a certain anti-manager trend in the business world that is particularly prevalent in the Agile community. For example it has been common for Agilists to say "We don’t need no stinking managers " (Esther Derby: Rethinking Managers Relationship with Agile Teams).

It seems that leaders are somehow more cool than managers. Conventional wisdom says "Managers do things right; Leaders do the right things" (Buckingham & Coffman, 2001). And Jim Highsmith (2009), one of the Agile gurus, makes it clear that Leader = Agile and Manager = Non-Agile. Ouch.

Agile leaders lead teams, non-agile ones manage tasks.

Highsmith (2009) cited by Scrum Expert

All of which makes self-labelling as a "manager", particularly an "Agile manager", rather risky. But before I go off to find a job as a leader, for which I’m possibly under qualified, I thought I’d take a look at the differences between leaders and managers and assess whether common wisdom is, after all, very wise at all. To do that I’ll outline what a couple of other people say about managers and leaders and how that marries up with my own view.
Continue reading →

Declaration of Interdependence

Posted on by

In 2004 some people met to define what agile project management should mean. In February 2005 they published a statement called the “Declaration of Interdependence” (DOI). According to David Anderson (Kanban and the DOI), one of the signatories, the intent was to:

  • define a value system by which modern 21st Century project managers should live and
  • galvanise a community around general application of agile project management

Continue reading →

Change is Good for Agile Projects

Posted on by

Kelley Hunsberger interviewed me for her article “Change is Good: For agile projects, redefining scope isn’t such a creepy thing”. It is great to see agile thinking in a mainstream project management magazine such as PM Network. And the article was a very nice little summary of why it is good to embrace change.

I took the opportunity to reiterate some of the points I’ve already made on Agile Project Scope and Agile Change Management, namely that all projects experience changing requirements and it is better to embrace this than fight it. For example legitimate sources of change include:

  • The customer learns as they see working functionality emerging of the development effort.
  • The technical team is also learning as they discover what works.
  • The environmental context might also dictate changes, such as changes in the market or legislation.

Ignoring any of these sources of “scope creep” would be foolish.
Continue reading →

Build it in a Week

Posted on by

I ran a massed prototyping exercise with my current team. The whole team: development, user experience and design, testing, product management, business analysis, programme/project management and the programme director. It was a concerted effort to get a solution covering everything. The idea was to build wide not deep. The requirements for the end to end workflow was a generic operating model we’d developed previously. Microsoft Sharepoint was the underlying platform so this exercise concentrated on “out-of-the-box” solutions based on Sharepoint.

Expected Benefits

I allocated a week for this so the cost was quite high. On the other hand I expected considerable benefits. I expected “Build it in a Week” to enable us to:

  • understand the requirements more
  • validate the generic operating model
  • validate the emerging information architecture
  • identify technical challenges and identify if “tricky” things were in fact simple
  • demo an end to end solution (even if clunky and with caveats)
  • understand Sharepoint 2010 more, specifically understand what “out-of-the-box” means in 2010
  • identify what we can’t do “out-of-the-box” right now
  • understand each other more

As programme manager I thought it worth the cost.
Continue reading →

Using a Product Led Matrix in Lean-Agile

Posted on by

I’ve worked in a variety of organisational settings including matrixed and non-matrixed. Based on this experience I thought I’d write up a few observations about organisational structures.

Traditionally companies have been organised into functional teams. More recently, partly as a result of Scrum and Lean for Software Engineering, companies are moving to departments containing cross functional product teams. Some organisations have a mix, for example, design might be a functional department but other departments might contain product teams. Other companies try to combine function and product into a explicit matrix structure. This ensures both product and function are represented on the management team.
Continue reading →