Public training

Speaking of speaking - as I was in my last post... I regularly get e-mails from people asking when I’m running a public training course. Truth is, public training adds lots of additional hoops to jump through to be successful, e.g. getting a good venue. Consequently I usually confine myself to in-house training for organizations.

I’ve now teamed up with the folks at Skills Matter to offer public training, specifically Agile Project Management. These sessions are running throughout 2009 in London and Aarhus, Denmark. More details on the Skills Matter web site.

Software East in January

I’ve been invited to join a panel debate in Cambridge on Thursday 22 January. This is quite exciting because the topic is “Building a Software Business” - something close to my heart as anyone who has read my business strategy patterns will know.

The organisers are Software East, a new initiative from Mark Delgarno and others to help the Silicon Fen software business community. Also on the panel is one of Cambridge’s local hero’s Neil Davidson, a founder of Red Gate software and one of the people behind the Business of Software community.

This will be the fourth time in less than 18 months I’ve been up to Cambridge for one speaking event or another. While I’ve been to other places in the country to speak 4 in 18 months is quite a record and I think it just goes to show how vibrant the Cambridge technology scene is.

The FT and Me

Regular readers of this blog have probably twigged that I read The Financial Times. What isn’t so well known is that I am, very occasionally, in The Financial Times.

Citibank (current advertising slogan “The Citi that never sleeps”) inspired my entry to today’s letters page.

Deciding that this penmanship deserved a mention in this blog I went to the FT site and did a vanity search to find the link above. What I wasn’t expecting was to find myself in another article from a few months ago.

Back in June the FT IT editor wondered out loud if there was anything the IT department could do to save costs. I must have had too much time on my hands that day because I shot off a note saying: Agile development can help cut costs, and here's how.

I missed publication of that piece at that time so I’ll have to be more attentive in future.

Now if only I could get them to link to blog....

Limits of self organizing teams

I’ve been thinking a lot about Scrum in the last few weeks. Scrums done a fantastic marketing job for itself, so much so that Scrum is now the poster child for Agile.

However there are aspects of Scrum I find troubling. One of these is the self-organizing team. Its not that I have anything against a self-organizing teams, in fact I’m all for them. And although I don’t talk about them in Changing Software Development much of what is written there implicitly advocates teams taking on organization for themselves.

No, what troubles me is the system within which self-organizing teams are expected to exist.

My first worry is that such teams are culturally incompatible with many organizations. Many (perhaps most) organizations are set up as command-and-control structures. As much as I’d love to have a revolution and change the whole organization I do not expect this to happen overnight. Self-organizing teams will often need to exist within command-and-contol organizations.

Some organizations will be open the occasional self-organizing team and will tolerate them. The team itself needs to recognise the boundaries of its self-organization and while it might seek to spread the idea it shouldn’t expect the whole organization to understand, the team needs to learn to interface to a hierarchical structure.

And in other companies the organizational immune system will actively try to ejects the self-organization team as counter-cultural.

A while ago I heard about a French bank in London which tried Agile development - it may have been Scrum I don’t know. Things went well to start with then the Business Analysts in the organization rebelled. They didn’t like the way the team was working and told management so. The experiment was closed down.

My second worry is that we might be asking too much of self-organizing teams within a hierarchical environment. Specifically, teams can (and do) change what is within their control but they exist within a system and they have limited power to change the system.

As W Edward Deming would point out: we should not blame the worker, or look for the worker, to fix a problem which is actually part of the system. The system needs to create the environment in which workers can do their best work. When the system stops the best possible work then it is they system that is at fault.

This is the thinking behind Deming’s point 10:

“Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.”

So, if we place a self-organizing team (or even a semi-self-organizing team) in a system which creates problems we cannot expect the team to fix the problems. There are limits to what the team can do. It is management’s job to create the environment.

I have been a vocal advocate of people trying to fix these kind of problems in their organizations. Indeed I actively urge people to try and address these problems. Until you try and fix a problem you don’t know if you can fix it or not.

Those of us who help organizations improve the way they work - including the adoption of Agile methods - need to recognise when a team can change the way they work and when they system the team exists in needs to be changed. And when the system needs changing we need to decide how far we go in changing that system.

BCS SPA London - this Wednesday

Just time to book your self a place at BCS SPA London on Wednesday (5th) if you want to hear me talk about Reflections of an Agile Advocate - 6.30pm, Covent Garden. (Yes I’ve done a lot of talks this year but I do have a book to plug! - most un-English).

Managing requirements in Agile development

I make no apologies for blogging again about Product Management because it is important and because, on the whole. As I said in my previous entry, Agile methods have a very simplistic view of determining what needs doing.

In the short run the Alignment Trap tells us that it is better to focus on doing things right, but in the long run Lean thinking tells us we have to do the right thing - remember 80% of features aren’t used. So Product Management is a long run play.

That is one of two reasons why Agile methods tend to underplay requirements and “Product Ownership” - because you get a lot of benefits by ignoring them to start with. The other is that Agile methods largely originated with developers who generally tend to underplay the role of requirements. (The exception to the rule may be EVO which is quite keen to understand exactly what people want.)

The trouble with Product Management is that everyone has a view on what needs doing, thus, in the absence of a Product Manager (or BA if your that type of company) other people will fill the void -

• Developers sometimes try and fill the void but developers have empathy with the code and find it hard to untangle their feelings about the code from what the customer wants.
• Architects claim to fill the void because they have the “bigger view” but architects are - almost by definition - uber-developers so have the same problem as developers. But architects are also tasked with looking at technology therefore any requirements they come up with are likely to be technology not market based.
• Project Managers often try and fill the void but their training and inclination is very different. They have a tendency to view things through the prism of dates rather than business value.

In the UK confusion between Project and Product management is rampant. It is slowly getting better but many companies can’t tell the two apart. This is really sad but also really dangerous.

Project Management can always expand to fill more time: you can always redraw a PERT chart, or level it again, you can always add another risk to the risk log (“An asteroid may hit Earth and delay the project”) or you can always go and ask a developer “Are we there yet?”

Product Management on the other hand can always be shrunk to squeeze in. After all we all have views on what the product should do so stick a finger in the air and guess. (And the more senior the person doing the guessing the more likely their guess will be taken as truth.) It takes time to visit customers, talk about their needs, time to go to trade shows, investigate competitors, time to calculate ROI and so on. Far quicker to stick a finger in the air.

My personal rule is: one Product Manager to every three to seven developers. If your product is stable, changing little and in a quiet market then one Product Manager may be enough for seven developers. But if you product is developing, the technology is innovative and the market changing fast you need one Product Manager for every three developers.

Its a false economy to skimp on Product Managers, you may save money but you may well create the wrong thing. Far better to go a little slower and create the right thing.

Given how much work a Product Manager has to do its natural to look for ways to split the role up. The first split is to hive off outbound marketing to Product Marketing. In a small company or team a Product Manager may do both inbound and outbound marketing but once it grows you should split the two roles.

Another division is between Tactical and Strategic, and with this split the role fits well with the Agile/Scrum idea of Product Owner. The Tactical Product Manager takes on the Product Owner role.

I hadn’t thought much about this until a friend of mine brought some blogs from Eigen Partners to my attention. These guys explain it well themselves so I’ll leave you to read Agile/Scrum Software Development and Product Management part 1, part 2, part 3 and part 4.