Turns out books about Product Management are a little likes buses: None then 3 turn up at once!
I’ve been looking for a good book on Product Management for a while so I was interested to see Tuned In by Craig Stull, Phil Myers and David Meerman Scott published. I’ve not had a chance to read it yet (so don’t take this as a recommendation) but I intend to.
Then, at Oredev I met Luke Holmann and had the pleasure to hear him speak. Turns out Luke has a book in the product management space too, its been out for a couple of years but somehow I’ve missed it. Again I’ve not had the chance to read it yet but I intend to, it is Beyond Software Architecture.
Finally, one of the Product Managers I’m working with just now leant me a copy of another book, Expert Product Management by Brian Lawley. This is small book and as such doesn’t cover the role of the Product Manager in full. It simply covers several aspects of product: Road mapping, Beta programmes, Reviews and Product Launch. There is good information here and as its small you can read it quickly. Still, I’m hoping on of the other books will turn out to be the Product Management book I’ve been looking for.
Wednesday, December 03, 2008
Saturday, November 29, 2008
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.
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.
Friday, November 28, 2008
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 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.
Thursday, November 27, 2008
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....
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....
Sunday, November 16, 2008
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.
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.
Monday, November 03, 2008
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).
Sunday, November 02, 2008
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.
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.
Wednesday, October 29, 2008
Requirements, Agile and Scrum
Ryan Shriver - aka The Agile Engineer - has some interesting comments on the requirements in Scrum projects - and Agile more generally. I tend agree with Ryan’s comments for a couple of reasons. Firstly I don’t think Scrum (or other Agile methods) really understand them. Secondly there is a lot more to requirements than is commonly realised.
Because Agile largely comes from the developer view we tend to neglect the bit that comes before but actually that is even more important in the long run. In the short run it is not important, in the long run it is vital. Agile methods have too simplistic a view of requirements, its all “user stories”. As Ryan says, there is more to it than that.
Because Agile largely comes from the developer view we tend to neglect the bit that comes before but actually that is even more important in the long run. In the short run it is not important, in the long run it is vital. Agile methods have too simplistic a view of requirements, its all “user stories”. As Ryan says, there is more to it than that.
Monday, October 27, 2008
Learning and Distributed teams
Andrés Taylor has some nice things to say about my book on his blog this week. Most of his blog is expressing concern about distributed teams and the discussion that follows is quite interesting too - Keith Briathwaite has continued on his blog. In my view distributed teams are generally a sub-optimal way of arranging your development process. However you may choose to organise in this way for several reasons. The main ones are:
1. You have no choice, for example: you need an expert in, say, database transaction processing on embedded systems and there are three guys in the world none of whom want to move to you Halifax Nova Scotia office.
2. You need your development team close to your customers and your customers are in different places.
3. Somebody somewhere has done a calculation that says the lost productivity is acceptable because the savings elsewhere. For example: having two developers in London and two in Bangalore is so much cheaper than having four in London that the 10% productivity loss is acceptable.
A few years ago we ran a focus group at EuroPLoP on Conways Law (What do we think of Conways Law now?) One of the insights I got from the focus group was:
• When ever you remove an informal communication channel create a formal one.
So.... Whatever the reason the important thing is to compensate for the distance. If you are saving so much money by spreading people out spend some of the money on flying people around to meet one another. Spend some of it on teleconferencing and video conference kit. Open the firewall to IM and Skype traffic.
Consequently companies that decide to spread their developers around should not then complain about travel budgets. If you are saving with the left hand you need to spend with the right so budget for it.
1. You have no choice, for example: you need an expert in, say, database transaction processing on embedded systems and there are three guys in the world none of whom want to move to you Halifax Nova Scotia office.
2. You need your development team close to your customers and your customers are in different places.
3. Somebody somewhere has done a calculation that says the lost productivity is acceptable because the savings elsewhere. For example: having two developers in London and two in Bangalore is so much cheaper than having four in London that the 10% productivity loss is acceptable.
A few years ago we ran a focus group at EuroPLoP on Conways Law (What do we think of Conways Law now?) One of the insights I got from the focus group was:
• When ever you remove an informal communication channel create a formal one.
So.... Whatever the reason the important thing is to compensate for the distance. If you are saving so much money by spreading people out spend some of the money on flying people around to meet one another. Spend some of it on teleconferencing and video conference kit. Open the firewall to IM and Skype traffic.
Consequently companies that decide to spread their developers around should not then complain about travel budgets. If you are saving with the left hand you need to spend with the right so budget for it.
Friday, October 24, 2008
Learning to be Agile
Andrés Taylor comments remind me to confess to something. The title of the book is wrong.
The book, as published by Wiley is entitled: Changing Software Development: Learning to become Agile.
The title I thought agreed to was: Changing Software Development: Learning to be Agile. I’m not upset with Wiley or my editor, I only noticed this myself a few weeks ago (about a year too late). I’m sure if you look back through my blog entries you’ll see the mistake for yourself. I assume the small change was to improve the grammar (not my strong point.)
But, for me it changes the title quite significantly. Learning to Become Agile implies you learn then you are Agile. End of story. Learning to Be Agile - in my mind at least - can be read two ways. The first is as I just said, you learn then you are Agile.
The second is more subtle, and I’m not sure if I can express it. This is the “to be, or not to be” version. The implication goes both ways: true Agile implies you learn, learning implies you are Agile, think of it as “I learn therefore I am Agile” - in order to be Agile you must learn.
Maybe this second version is a bit of a stretch - does anyone else get it? - but for me its actually more important than the other reading and in many ways this is the true title of the work. Shame I never noticed the subtle change.
The book, as published by Wiley is entitled: Changing Software Development: Learning to become Agile.
The title I thought agreed to was: Changing Software Development: Learning to be Agile. I’m not upset with Wiley or my editor, I only noticed this myself a few weeks ago (about a year too late). I’m sure if you look back through my blog entries you’ll see the mistake for yourself. I assume the small change was to improve the grammar (not my strong point.)
But, for me it changes the title quite significantly. Learning to Become Agile implies you learn then you are Agile. End of story. Learning to Be Agile - in my mind at least - can be read two ways. The first is as I just said, you learn then you are Agile.
The second is more subtle, and I’m not sure if I can express it. This is the “to be, or not to be” version. The implication goes both ways: true Agile implies you learn, learning implies you are Agile, think of it as “I learn therefore I am Agile” - in order to be Agile you must learn.
Maybe this second version is a bit of a stretch - does anyone else get it? - but for me its actually more important than the other reading and in many ways this is the true title of the work. Shame I never noticed the subtle change.
Subscribe to:
Posts (Atom)