Uncategorized

Lean Product Development references

After yesterdays blog posting I had a comment from ‘Brave Heart’ asking for some references on Lean Product Development. I’m more than happy to help and normally I’d reply direct to Brave Heart. But… I can’t find your e-mail address on your posting or blog. So that means everyone is going to see my recommendations…

The only book I’ve read which is dedicated to Lean Product Development is Michael Kennedy’s Product Development for the Lean Enterprise. There is some additional information in Machine that Changes the World (little bit dated now), Lean Solutions and Thinking Beyond Lean (also getting a bit old) but not a lot. I believe there are a couple of other books dedicated to the Toyota Product Development System but I haven’t read them.

I think you would benefit from looking at some of the literature from the software community. In particular Mary and Tom Poppendieck’s books Lean Software Development and Implementing Lean Software Development.

From there you have to decide if you want to look at Agile software development. I think of Agile as an application of Lean, which I talk about in my own book, Changing Software Development. If you do then SCRUM is going to be of more interest than XP or some of the others.

This is because SCRUM has its roots in the knowledge management – specifically the theories of Nonaka – and these link up with the knowledge thinking behind Lean Product Development. Which brings us full circle back to Kennedy. As Kennedy points out, Lean Product Development might be better described as Knowledge Based Product Development.

As for research, you might want to go and watch some Agile or Lean teams in action. Its probably easier to find teams which consider themselves Agile than Lean. You’ll want to look at how their activities differ from ‘traditional’ product development.

I hope that helps.

Brave Heart, please drop me e-mail (with your address) if I can be of any more help.

Lean Product Development references Read More »

Developers are not the only fruit

 

My younger self would be horrified to hear me say this but, when you develop software you need people who are not software engineers.

Don’t get me wrong, coders/engineers/programmers are the most important people because these are the people who actually produce the thing. As such they are central to any development effort, you can’t write software with a collection of managers, analysts and testers any more than you can build a ship without shipwrights.

Coding is where the metal is bent, shaped and welded. When coding there is no room for ambiguity or fudge, the code doesn’t lie and it doesn’t take to ambiguity. Thus there is a lot of details in coding which aren’t obvious before you start. So your developers need to be able to call on Product Managers for more detail and, if you have any architects, you need them at the code face coding with your developers.

See Jim Coplien and Neil Harrison’s patterns Work Flows Inward and Architect Also Implements for more discussion of this topic.

One of the worst projects I ever worked on was completely top heavy with managers (programme, project, customer, delivery, team – you name it we had a manager for it), testers, analysis, admin staff – yes you needed a lot of admin staff when the project was over 120 people. But only about 12 actual coders. Crazy. The overhead was there because… well, the ISO-9000 procedures needed a lot of managers, and it gave the consultancy implementing the project a lot of bodies to bill for, and it gave the Government (the people who were ultimately paying for it all) a lot of reassurance that it would be done one time, to budget and spec. Except, it was late, the spec trimmed left, right and centre, and if there ever was a budget we blew it.

So you see I’m no fan of carry extra weight on a project.

But, you need people who don’t code.

I’ve written before about the role of the Product Manager and why product management is important, and why you need them. So lets say we accept that Product Manager are needed.

In an idea world we wouldn’t need software testers either. And I expect one day to work somewhere where there are no testers. I don’t believe this is an impossible dream. But with the current state of play we need software testers in most organizations.

One role I don’t think we need is Software Architect. On the whole I think most architects are mislabelled. They should be Product Managers, Business Analysts, Senior Software Designers/Engineers or even Project Managers. Sometimes this is because the organization misuses the title, sometimes its because they don’t understand it (after all, what is software architecture?) but most of the time its because of title inflation. You couldn’t give someone a pay rise so you gave them a nice title.

Although I don’t read Joel Spolsky very often I do agree with him about Astronaut Architects. The moment your architects stops coding its time to fire them. Once they stop coding they are a burden not an asset.

Project Managers are another group I don’t think we need. I accept teams need some leadership but Project Managers are completely the wrong people to. Project Managers are trained to analyse, dissect, use whips (badly) and emit hot air. Their are not leaders by nature or training.

The Agile world is re-inventing project management as coaching but unfortunately the Agile world is pretty messed up about coaching. Coaches are useful when you they get it right and they are genuinely improving the team rather than acting as Project Managers with a different title.

But, and this is where my younger self will have a fit: you do need someone to oversee and manage the whole development process. The big problem is very very few people can do this job right.

By way of explanation to my younger self: done badly this role is worse than useless, done right it can really improve things. Unfortunately most people do it badly.

Its done badly for several reasons.

Firstly, most Software Managers have never been trained in the role – or management at all. They ‘make it up as they go along.’

Second, some of these managers don’t understand software development, they come from outside the domain. Such people try and make software development fit their existing model of management but it never will. Therefore they are constantly trying to make a square fit in a round hole.

Third, many of the managers who come from inside the domain, and know how to develop software can’t give up coding software. To be a good software manager you have to stop being a coder. You have to learn to look at the world differently, you have to realise you can’t intervene to fix problems, you can only arrange things so other people can fix them.

When I was younger I once worked for a bank. The code I was working on was terrible and I had no support from the organization. I really really wanted my manager, and his manager, to come and code with me. I thought their big mistake was to stop coding. I was wrong.

Their biggest mistake was not to stop coding but to stop communicating with those who did code. The big mistake was to put too much space between themselves and the building process. Had they involved themselves more they would have better understood the problems and would have been able to arrange things so I could fix them.

If you are managing a software team you should be talking to them every day. You should be improving their working conditions every day. You should be allowing work to flow to them.

When you move from coding to management you have to give up part of yourself, you have to trust the people you manage. It is their code now, not yours.

So, in conclusion: it is wrong to think you only need developers to create software. It is also wrong to think you can code and do other things – you need the separation. But it is also wrong to have too big a separation.

Make any of those mistakes and you just moved one more duck out of line.

 

Developers are not the only fruit Read More »

IT: Better to be effective or aligned?

In my last blog entry promised to discuss a second piece from the MIT Sloan Review. In many ways I find Avoiding the IT Alignment piece more interesting than the Rettig piece I discussed last time. The Rettig piece was a good argument but it wasn’t clear what you did next, it was insightful without being immediately useful. The second is piece is insightful and has some immediate application – the authors suggest some but I’ll add some of my own below.

Perhaps one reason why this piece is more immediately useful is that the authors (David Shpilberg, Steve Berez, Rudy Puryear and Sachin Shah) are all consultants with Bain therefore they have something to sell, consultancy. Rush out now and hire your Bain consultant! Sorry, I shouldn’t be so negative. Let me give yo a run down of the article and then draw some conclusions of my own.

The article is based on the authors’ experience and a large(ish) survey. You can argue with the underpinnings of the article but I’m quite happy to give it credibility. Like the Rettig piece they are concerned with internal IT projects rather than products for sale (my main area of interest and experience.)

From this survey they are able to divide companies into four categories – a nice 2×2 matrix based on whether a company has effective (or ineffective) IT and whether the IT is aligned with business strategy (or pursuing its own.) These four categories are:

IT Enabled Growth: These companies have highly effective IT groups who are closely aligned to the business. This is what we all want. These guys are doing it. Unfortunately only 7% of companies fall into this category. The benefit to these companies is 35% sales growth over 3 years. Pretty impressive. Perhaps surprisingly these companies spend 6% less on IT than average. So, going it right also means doing it more cheaply.

Maintenance zone: These the basket cases, IT is not aligned with the business and it is not effective. Unfortunately this accounts for 74% of all companies, really depressing. Because this is the bulk of all companies it is perhaps unsurprising that the IT spend in these companies is the average, and their 3 year sales is just slightly below average at -2%.

They are the two opposite, and perhaps we expect that. A few companies maximise value from IT but most don’t. The next two are more interesting:

Alignment trap: this is the combination the authors find most interesting. This occurs when IT operations are aligned to the business (i.e. they are doing what the business wants) but they are not effective. Only 11% of companies fall into this zone – together with the first category this means only 18% of companies actually have IT and the business aligned, quite shocking. These companies spend 13% more than average on IT but the annual growth in sales is 14% below average, a pretty poor showing really.

Such companies are doing the right thing but they are doing it badly. From the figures given this seems to be the worst category to be in, highest costs and lowest sales growth compared to average. Think about that for a minute. These companies have it half right, IT is aligned with the business but they are not effective. These companies would be return better results if they gave up on business alignment and joined the 74% in the maintenance zone.

I would suspect these companies actually make it difficult for IT people to do the right thing. They probably have plenty of processes in place to make sure they don’t do the wrong thing but doing stop people from doing very much at all. My guess is that managers in these companies don’t understand IT and are trying to run IT the same way they would run any other department. Consequently the IT people can’t do their job.

Finally we come to Well Oiled IT: this is the category I find most interesting. These companies are doing IT well, they spend 15% less than average on IT but see 11% higher sales. Only 8% of all companies fall into this group, if we add that to the 7% of companies in the IT enabled growth category we see that only 15% of companies, less than 1 in 7 actually have effective IT.

Statistically, well oiled IT companies are similar to the growth companies but less so, they have significantly lower sales growth but spend even less on IT. Possibly these companies are focusing too much on cost – my bet is they don’t have effective business analysts and product managers in place.

Now for the authors’ advice: they tell companies to focus first on operations not alignment. If companies (and remember most start in the basket case maintenance zone) focus first on alignment they are likely to end up in the alignment trap, where things are worse. Therefore, seek first to make your IT effective then to make it aligned.

I like this advice, but like so man things in the IT world the devil is in the detail. So what do the writers recommend?

Keep it simple – we all agree in principle but we all get caught out; trouble is IT tends to get more and more complicated, battling complexity is a constant fight
‘Right size’ – which is a bit vague but basically they say outsource somethings, keep some things in house but do it consciously and intelligently
End-to-end accountability – IT managers need the resources to do the job but they have to keep talking to the business, and the business needs to talk to IT

All this advice is sound and it makes for a good starting point.

So now some thoughts of my own.

First this survey supports what I’ve found in practice: most IT operations are basket cases. Few companies can do IT well. In product companies there is natural selection by market forces. If the company is too bad they will (eventually) fail and go out of business. Where IT is a service to the business failure can continue almost indefinitely. Unfortunately this means that at least 85% of people in corporate IT departments will work in failing teams.

Second I now understand why Agile development works so well in many organizations even though it is not aligned with the business. Simply it doesn’t have too. If adopting Agile development moves an organization from maintenance zone a little toward well oiled then it doesn’t matter that it is not aligned with the business. Just improving effectiveness will deliver benefits.

Third, business must take more of an interest in IT. IT can make itself more effective but to become aligned the business needs to understand and get involved with IT – back to the point I was making about the Rettig article and last year about companies that understand IT.

On the whole I find this article good news, it helps me chart a cause for improvement. I see a three stage plan for any failing IT department:
1. Apply well known techniques from the Agile toolkit: this will boost your effectiveness immediately
2. Learn what is special about your environment so you can tailor the Agile techniques and find some of your own. This will further enhance your effectiveness.
3. Continue you learning to bring about business alignment. Often this is going to be a case of removing the old perceptions about how IT departments operate (e.g. Requirements: a dialogue not a document). It also means educating managers and IT staff, and it means creating the roles of product manager and business analyst to facilitate it all.

With 93% of companies failing one way or another there is plenty of work to do.

Now if we loop back to the Rettig article on ERP. Is it any surprise that ERP deployment fails? Only 15% of companies are capable of implementing it effectively, and of these less than half will align it to the business. Of all ERP deployments we can only expect 7% to come close to fulfilling their promises.

An often heard dictum in management concerns the difference between ‘doing the right thing’ and ‘doing it right’. If this article is right, when it comes to IT then it is better to ‘do it right’ than ‘do the right thing.’ Only if you can ‘do it right’ should you even start to think about ‘doing the right thing.’ Operations over strategy. Implementation over design.

 

IT: Better to be effective or aligned? Read More »

Blue White Red – a simple Agile process

My article from last months ACCU Overload is now on my website. This piece describes a simple Agile process which I have used successfully. I don’t claim it introduces anything new or radical. I don’t even claim originality, it derives from SCRUM and XP. All I claim is it worked for me, my teams and has been used in multiple organizations.

What I think is important about Blue White Red is that is shows how you can start to roll-your-own Agile-like process. Start simple with what works for you.

Read the full piece here.

Blue White Red – a simple Agile process Read More »

On project management

I finished my last entry by taking a swipe at project management and even project managers. That was probably unfair but the fact is I am not a fan of project management

It could be a career limiting move to speak against project management but I feel I should say something to explain my sideswipe, I should explain my thoughts.

Of course I’m not naive enough heretical think projects “just happen” – there needs be some kind of project management but it is the form project management usually takes that I have a problem with. I am not alone in my views, but they are somewhat heretical.

In their book “Lean Software Development” Mary and Tom Poppendieck explain why much project management practice is contrary to the principles of lean. Henry Mintzberg wrote an entire book in criticism of strategic planning – although “The Rise and Fall of Strategic Planning” (1994, 2000) is largely concerned with the differences between strategy and strategic planning much of what he says can be applied equally to project management.

More specifically the authors Lauri Koskela and Greg Howell have written papers claiming the whole theory of project management is obsolete, e.g. “The theory of project management is obsolete” (2002) and the “Theory of project management explanation of novel methods” (2002). (Actually, one of their criticism is that project management lacks a theory and academic underpinning.)

I’ve even discussed this subject myself before – see “An alternative view of planning”. Of course my view of planning it comes from the software/IT perspective and it may be dangerous to extrapolate to all project management, but this is the feel I know.

So, as I see it, the problems with current project management on multiple:

  • Planners are divorced from those doing the work
  • Planning is not used as a learning tool, it is used as a control tool, this can lead to planning being used to apportion blame
  • Responsibility is removed from those doing work, after all the plan says can be done so is merely an exercise in executing against the plan
  • Accuracy: planning is based on estimates which definition in wrong
  • Extrapolation from the past: planners so often assume that the future will be like the past
  • Planning limits our expectation, because extrapolate from the past, and because the use estimates, and because they ignore the learning we are limited to what we expect to happen
  • Plans become defensive barrier behind which people hide: manages no longer talk to those doing the work they talked of project manager, who in turn talks the people doing the work, nobody has to answer for this, we just compare ourselves to the plan – which of course nobody really believes

Finally planning is demoralising, what we have a plan or users execute. A good project manager execute the plan – the workers are minor fact, and all too often they know this.

So that, in a nutshell is why not fan of project management and planning.

Yes it sounds like I have moved from talking about project management to talking about planning – and I know they are different but is the emphasis put on plans is what I don’t like about project management. (Some of the points made above (e.g. responsibility, learning, accuracy) still hold even if you don’t have a plan, you just have a project manager who create a barrier.) The subsequent “execution against plan” and “exception tracking” are all part of what we define as “project management” today.

So, what I put in its place?

The answer is quite long. I give you some ideas in the last, and earlier, blog entries. In a sense, the “alternative” is what this blog is all about. Or, put it another way: the alternative is a work in progress.

Stay tuned.

On project management Read More »

Verified by MonsterInsights