The new year is just here! And can I suggest a new year’s resolution?
Normally I bite my tongue and don’t mention this. I’ve not blogged about it before because what ever client(s) I’m working with at the time I blog about it will automatically assume I’m talking about them. (Yes, I know people at client sites find and read my blog so I try to self-censor.)
But, I’ve just finished up a major engagement (coaching 4 development teams in the same company) and new stuff kicks off in the new year, so I can say this for once.
Please, don’t take your laptops to meetings. And if you do leave them powered down.
If you go to a meeting it deserves your full attention. If you don’t want to give it, or can’t give it, than make your apologies and say: Sorry I can’t make it, go on without me.
If you do go then give the meeting your attention. OK, occasionally we all need to take a phone call but it is far less often than we think. I remember breaking my own rule a few years ago to take a phone call, but then I was waiting for my farther to die.
Phone calls are different to laptops. A phone call is an interrupt. It says “Someone wants you.” By definition if someone has sent an e-mail it is less important, or at least less urgent. So as much as I dislike meeting interrupted by phone calls I can accept them - personally, I switch my phone to silent and reject calls that come during meetings.
If you are so important you carry a Blackberry (or similar) and urgent (meeting interrupting work) arrives via e-mail it may be a sign that your organization can’t prioritise. But at least a Blackberry is small.
The problem with a laptop in a meeting is it creates a barrier between the user and the other people in the meeting. Every time someone lifts their screen I see a sign that they don’t want to be here, don’t want to hear what is said, and don’t want to be part of the team.
That screen is big. Its a big barrier. Its a sign. It says “I don’t need to interact with you people.”
And what do people do with these laptops?
I tell myself they are answering e-mail, important requests that cannot wait. But... well... I heard about a case recently where the senior manager in the meeting was booker herself a flight on EasyJet. I once went to a meeting which was so packed I had to stand at the back, from where I could see a manager (director level) surfing Amazon.
And people who are typing? Are they really replying to an urgent e-mail or having an Instant Messenger conversation with their significant other?
I once took an IM from a colleague in the New York office. Later in the day I saw him in the London office. He’d landed that morning and spent the first few hours in the London office in meetings. So when I IM’ed with him he was in a meeting on a totally different subject and he could have asked me face-to-face an hour later.
Please, stop taking your laptops to meetings. I’d rather you make your apologies and not turn up at all.
Wednesday, December 31, 2008
Friday, December 19, 2008
A future for software development in the west?
To read the papers one would sometimes wonder if there is a future for software development, indeed IT in general, in Western Europe and North America. Sometimes it seems there is an continual flow of work to India, China and other low cost centres. Personally I think there is a future but only if development groups fix themselves.
First lets be clear: I’m talking about corporate IT here, not independent software developers or other companies who develop software to sell. That is another story, another arguement, lets still to corporates today. Corporate IT departments support business operations by providing them with custom software.
Second there is another force at work: the commoditisation of business processes and the IT that support them. Lets leave that to one side for the moment.
So, I’m specifically talking about IT groups within businesses that need custom software to support some business activity.
Unfortunately such corporate IT departments do not have a good track record. Something like 87% of all such departments are ineffective and do not give the business what they need. (I’ve taken the figure from The Alignment Trap reports which I’ve blogged about before.) In such circumstances IT represents a cost not a benefit. Such companies might be better off not doing IT at all.
If you are doing it, and you are not seeing the benefit, and you are paying the cost then its sensible to look at reducing that cost. Outsourcing and/or offshoring is a valid option.
It might not be nice to hear but if you work in such a group it makes sense to send the work elsewhere. Sending it elsewhere might not fix the original problem but at least it will be cheaper.
So what’s the solution? How do you save your job?
Instead of looking at the cost look at the benefits. Some IT groups have forgotten how to do this simply because their delivery record is so bad. When you only consider the cost side western corporate IT cannot compete, give up now. In order to compete you have to look at the benefit side to.
When things are going well, when an IT group can deliver and can deliver benefits then it is less likely that management will want to change things. When things work, and work well, then any change is a risk. When things don’t work the risk is lower.
Next you need to maximise the benefits. That means looking at how you can add more benefit. And specifically add benefit in ways that offshore low cost centres can’t: quicker turn around, reduced documentation, more interaction with the business.
There is a price to pay in moving work to a low cost centre. Such centres have disadvantages: language differences, cultural differences, distance, time zones, lack of domain knowledge. Sure they can offset these differences but that involves costs. Plus they are getting more expensive (particularly as the pound and dollar fall).
Corporate IT departments can demonstrate their value by responding to business needs more quickly, and by reducing the cost of servicing those needs. When work goes offshore the turn around rate slows because work must be communicated. That means it needs to be more closely defined - this is especially true if the work goes to a third party. Opportunities to change’s ones mind are reduced and the potential for differences increased.
Yes offshore centres can offset these differences but at a cost. Each time the cost goes up the advantage is reduced.
So if you fear your work may go offshore heres what to do:
• Demonstrate the benefit of your work - move the conversations from costs to benefits
• Concentrate on co-operating with your business customers
• Turn work around more quickly
• Reduce the cost of requests and changes of mind - reduce the paperwork
• Work more flexibly
• Understand the business and find ways to innovate
First lets be clear: I’m talking about corporate IT here, not independent software developers or other companies who develop software to sell. That is another story, another arguement, lets still to corporates today. Corporate IT departments support business operations by providing them with custom software.
Second there is another force at work: the commoditisation of business processes and the IT that support them. Lets leave that to one side for the moment.
So, I’m specifically talking about IT groups within businesses that need custom software to support some business activity.
Unfortunately such corporate IT departments do not have a good track record. Something like 87% of all such departments are ineffective and do not give the business what they need. (I’ve taken the figure from The Alignment Trap reports which I’ve blogged about before.) In such circumstances IT represents a cost not a benefit. Such companies might be better off not doing IT at all.
If you are doing it, and you are not seeing the benefit, and you are paying the cost then its sensible to look at reducing that cost. Outsourcing and/or offshoring is a valid option.
It might not be nice to hear but if you work in such a group it makes sense to send the work elsewhere. Sending it elsewhere might not fix the original problem but at least it will be cheaper.
So what’s the solution? How do you save your job?
Instead of looking at the cost look at the benefits. Some IT groups have forgotten how to do this simply because their delivery record is so bad. When you only consider the cost side western corporate IT cannot compete, give up now. In order to compete you have to look at the benefit side to.
When things are going well, when an IT group can deliver and can deliver benefits then it is less likely that management will want to change things. When things work, and work well, then any change is a risk. When things don’t work the risk is lower.
Next you need to maximise the benefits. That means looking at how you can add more benefit. And specifically add benefit in ways that offshore low cost centres can’t: quicker turn around, reduced documentation, more interaction with the business.
There is a price to pay in moving work to a low cost centre. Such centres have disadvantages: language differences, cultural differences, distance, time zones, lack of domain knowledge. Sure they can offset these differences but that involves costs. Plus they are getting more expensive (particularly as the pound and dollar fall).
Corporate IT departments can demonstrate their value by responding to business needs more quickly, and by reducing the cost of servicing those needs. When work goes offshore the turn around rate slows because work must be communicated. That means it needs to be more closely defined - this is especially true if the work goes to a third party. Opportunities to change’s ones mind are reduced and the potential for differences increased.
Yes offshore centres can offset these differences but at a cost. Each time the cost goes up the advantage is reduced.
So if you fear your work may go offshore heres what to do:
• Demonstrate the benefit of your work - move the conversations from costs to benefits
• Concentrate on co-operating with your business customers
• Turn work around more quickly
• Reduce the cost of requests and changes of mind - reduce the paperwork
• Work more flexibly
• Understand the business and find ways to innovate
Sunday, December 14, 2008
XP Day 2008
I spent Thursday and Friday last week at XP Day 2008. The conference changed its format from last year. Rather than being a conference aimed at people wanting to do Agile Development it focused on people who do Agile development. This meant the sessions changed rather than being introductory or “how to” material they became Open Space discussions. Instead of being lecturers session leaders were facilitators.
Very few sessions were arranged in advance but one that was was Designing the Agile Company led by Giovanni Asproni and myself. This session used a dialogue sheet technique to promote discussion.
XP Day also had space for Lightening Talks. These were unscheduled talks lasting no more than 5 minutes - so very focused. I briefly outlined the Requirements Trap - or rather the Alignment Trap which I blogged about last year. This short talk got a lot of interest and a lot of people asked for the references so here they are:
• Original Alignment Trap article in the MIT Sloan Management Review
• An abridged version from the Bain Consulting website
• My blog entry on the Alignment Trap and Agile software development
I enjoyed XP Day a lot and learned a bunch of stuff - mainly by having to think about it. Yet I found the conference lacking because I found myself speaking to the same people; I already known most of these people, I read their blogs, I talk to them at XTC and a bump into them at other conferences. One of the nice things about Oredev last month was new faces. I guess you can’t have everything.
Very few sessions were arranged in advance but one that was was Designing the Agile Company led by Giovanni Asproni and myself. This session used a dialogue sheet technique to promote discussion.
XP Day also had space for Lightening Talks. These were unscheduled talks lasting no more than 5 minutes - so very focused. I briefly outlined the Requirements Trap - or rather the Alignment Trap which I blogged about last year. This short talk got a lot of interest and a lot of people asked for the references so here they are:
• Original Alignment Trap article in the MIT Sloan Management Review
• An abridged version from the Bain Consulting website
• My blog entry on the Alignment Trap and Agile software development
I enjoyed XP Day a lot and learned a bunch of stuff - mainly by having to think about it. Yet I found the conference lacking because I found myself speaking to the same people; I already known most of these people, I read their blogs, I talk to them at XTC and a bump into them at other conferences. One of the nice things about Oredev last month was new faces. I guess you can’t have everything.
Saturday, December 13, 2008
Oredev
I have been at the XP Day conference for the last two days but before I blog anything about that conference I want to record a few notes about Oredev last month.
The first thing to note about Oredev is that it is big. About 900 people. While the topics cover, and type of attendee make it look a bit like ACCU Conference but it is more than twice the size of ACCU (usually about 300-350) and it felt it. While quantity has a quality all of its own I missed the intimacy of ACCU.
My own session was well received. Hard to tell how many people attended the session, I would guess 50 to 100, but in a room that could hold 1,000 it felt empty.
Still I met a bunch of nice people and heard some good talks. Bob Martin was on form, his keynote talk took more prisoners - “Professionalism is spelt TDD” and programmers should me more like the Boy Scouts of America. The Boy Scout have a rule: When you camp somewhere, always leave the campsite tidier than when you arrive. Bob suggests programmers should apply this rule to working on code.
While I enjoyed several of the other talks (Gabrielle Benefield, Diana Larsen, Dag Krogdahl stick in my mind) it was Luke Hohmann’s that explained something to me. Luke’s talk was about product management - and regular readers know this is one of my hobby horses - but in passing it answered a question I’ve had for years.
What is Enterprise Software? - or more to the point What is Not Enterprise Software? Luke gave 4 attributes of enterprise software:
1. Enterprise software is expensive: you don’t buy it for the home, only corporations buy it
2. Enterprise software is tended by people: system administrators, etc.
3. The software is critical to some aspect of the companies business
4. Enterprise software is more valuable when it is integrated with other enterprise software
The first thing to note about Oredev is that it is big. About 900 people. While the topics cover, and type of attendee make it look a bit like ACCU Conference but it is more than twice the size of ACCU (usually about 300-350) and it felt it. While quantity has a quality all of its own I missed the intimacy of ACCU.
My own session was well received. Hard to tell how many people attended the session, I would guess 50 to 100, but in a room that could hold 1,000 it felt empty.
Still I met a bunch of nice people and heard some good talks. Bob Martin was on form, his keynote talk took more prisoners - “Professionalism is spelt TDD” and programmers should me more like the Boy Scouts of America. The Boy Scout have a rule: When you camp somewhere, always leave the campsite tidier than when you arrive. Bob suggests programmers should apply this rule to working on code.
While I enjoyed several of the other talks (Gabrielle Benefield, Diana Larsen, Dag Krogdahl stick in my mind) it was Luke Hohmann’s that explained something to me. Luke’s talk was about product management - and regular readers know this is one of my hobby horses - but in passing it answered a question I’ve had for years.
What is Enterprise Software? - or more to the point What is Not Enterprise Software? Luke gave 4 attributes of enterprise software:
1. Enterprise software is expensive: you don’t buy it for the home, only corporations buy it
2. Enterprise software is tended by people: system administrators, etc.
3. The software is critical to some aspect of the companies business
4. Enterprise software is more valuable when it is integrated with other enterprise software
Monday, December 08, 2008
Gemba - Lean tour
Jason Yip works for ThoughtWorks in Australia. He is currently (or maybe was) on a Lean study tour in Japan - I’m jealous, where do I book mine? - and he’s blogging about his findings. Well worth reading, so far several points have stood out for me:
• Andon cords are being pulled all the time: a Toyota factory isn’t the perfect place some of us (myself included) imagine sometimes. Faults happen, things need to be fixed and improvements made - all the time.
• Toyota do pay bonuses: for ideas that lead to process improvement
• Hansei is the Japanese word for serious reflection. In the Agile world Retrospectives are Hansei. As regular readers know I always suggest keeping your own personal journal for reflection, more Hansei.
• Pika Pika is a Japanese term translating to “spic and span”: workers keep their work area clean and tidy. Obvious really, how else can you see the problems? (I’m always shy of people taking cards of the board and putting them on their desks after one engineer I knew lost several this way. We tidied his desk and found work.)
• “The Toyota Production System (TPS) is not a system; it's a religion” - to all those who have critised Lean and Agile for being too religious, you were right.
If that isn’t enough, Jason also has a nice set of hand drawn sketches to illustrate Agile and Lean!
• Andon cords are being pulled all the time: a Toyota factory isn’t the perfect place some of us (myself included) imagine sometimes. Faults happen, things need to be fixed and improvements made - all the time.
• Toyota do pay bonuses: for ideas that lead to process improvement
• Hansei is the Japanese word for serious reflection. In the Agile world Retrospectives are Hansei. As regular readers know I always suggest keeping your own personal journal for reflection, more Hansei.
• Pika Pika is a Japanese term translating to “spic and span”: workers keep their work area clean and tidy. Obvious really, how else can you see the problems? (I’m always shy of people taking cards of the board and putting them on their desks after one engineer I knew lost several this way. We tidied his desk and found work.)
• “The Toyota Production System (TPS) is not a system; it's a religion” - to all those who have critised Lean and Agile for being too religious, you were right.
If that isn’t enough, Jason also has a nice set of hand drawn sketches to illustrate Agile and Lean!
Wednesday, December 03, 2008
Books for Product Managers
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.
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.
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.
Subscribe to:
Posts (Atom)