Category Archives: management

Organizational Change

Posted on by
Reply

It was a bit of quiet meeting – just me and Tom turned out for this one. This discussions were around the book Fearless Change by Mary Lynn Manns and Linda Rising.

Tom began by saying that he was a little impatient reading the book. He wasn’t sure if this was because the book wasn’t getting to the point quickly enough, or if he was just short of time to read it. I pointed out that there is an Appendix that sums up the patterns and shows where they fit together. I think it would have been even better if there had been a map to show the connections between the patterns and the order in which they are applied.

I mentioned some of the patterns I found to be most interesting. In particular, Ask for Help, Group Identity, Piggyback and Just Do It. Once you read them, they seem obvious, but perhaps when you actually need to apply them it might not be so clear.

Ask for Help is just that and is a call to go against the grain and actually seek out others to help your cause rather than assuming that you need to do it all personally.

Group Identity is about forming a team or a movement around a name. I mentioned IBM’s Black Team, which I believe is mentioned in Peopleware. I’m not sure what Tom made of this, especially the idea that they would start wearing black to form an identity. But it seems like they were effective.

Piggyback is where you use pre-existing meetings and other structures to help move your idea forward. There was a story about starting a fringe conference just after another one to improve the chances of it getting attendees.

Finally, Just Do It is a call to get on and make changes. This seems to fit in with the maxim that it is “Easier to ask forgiveness than permission”.

Tom wondered if the book needed to be quite so big. I thought that a few patterns seemed to be very similar, such as Corridor Politics and Whisper in the General’s Ear. Both of these are about influencing key decision-makers in an informal situation. I might have preferred it if the initial twelve chapters which introduce the patterns in their settings had been supplemented by brief descriptions of the patterns. I’m not sure that having an alphabetic list is that helpful.

It sounds from the above that I didn’t like the book. But I did. For more, take a look at the interview with Linda Rising at InfoQ.

Finally, Tom had a flash of inspiration that this book fits into a tradition of management patterns books started by Machaevelli and The Art of War. I think that was the most profound comment of the evening.

Meeting 24 – Principles of Software Engineering Management

Posted on by
1

There were just four of us at the Lamb and Flag to discuss Tom Gilb’s book Principles of Software Engineering Management. Steven and I were joined by John and Ursula. John said that he had read the book in question some years ago. He said that lots of people didn’t really get it when it came out and he included himself in that category. One of the themes of the book is the idea of inspections, but John suggested that Tom Gilb had been frustrated that no-one really picked up on that. So he ended up writing another book Software Inspection to try to hammer the point home. Apparently people still didn’t really get it. John said he realised this when he read James Womack’s book Lean Thinking where there was a discussion of how western companies could never truly understand the ideas of Lean. I admitted that I didn’t feel that I’d really got what Gilb was driving at with inspections.

Something I did like about the book was the discussion of what requirements are and how they differ from solutions. No-one else discusses this – in other development methods it is always assumed that the customer takes care of that part and has at least some idea of what they want. Chapter 4 of the book did a very good job of exploring what parts of ‘requirements’ are actually just solutions. I loved the story of the California teacher system. The customer specified that they wanted a computerised system and that’s just what they got. Unfortunately it cost 7 times as much to use the new system as the old paper-based one. What they really wanted was a cheaper and more efficient system. But they expressed this by giving a solution, not the actual requirement. As Steven pointed out, this mindset is much like the thinking in agile and lean methods, where you focus on the end goals and delivery of value at all times.

While the mindset concentrating on the delivery of value was very much like lean, I found the idea of have one hundred attributes to measure the success of a project rather different. It seemed to me that this was almost like not concentrating on your base goal. Would the project be a success if all those attributes went in the right direction but the company became less profitable and less popular with its customers?

Going back to inspection, I said that the very use of that word is almost an anathema to those who practice lean. The mantra is that you should try to ensure that there are no defects, not look for them later. Ursula thought I had the wrong end of the stick and that there would always be defects in a software product and that Gilb’s inspection is more like the lean idea of “Stopping the Line” when there is a problem.

Steven said that he thought the key message of the book was that evolutionary delivery is key to success. John agreed that you need to give the users something as early as possible. This idea is now widely accepted, even if other parts of this book are not.

Ursula talked about the idea of constantly recording task estimates as a way of improving the quality of them. She also talked about confidence measuring. This was a way to see if people on the team had doubts which they didn’t want to bring up. It would be easier for them to say they were not confident about hitting a deadline perhaps than bring up the reasons why. I said that I thought that the idea of project velocity was a good one as you don’t need to keep re-estimating all the time.

Finally, I asked if anyone understood what Tom Gilb meant by an Open-ended Architecture. Steven suggested that it meant that the design was not constrained unnecessarily. I’m afraid this is something else that I didn’t really get. Someone may have tried to explain it to me, but I’m afraid it was too late in the evening for my brain to take it in by this stage.

Meeting 18 – Peopleware

Posted on by
5

A quiet meeting this time, with just me, Miquel and newcomer Brett showing up to discuss Peopleware by De Marco and Lister (Looks like you didn’t choose the right one to come along to – usually we have more people and so the discussions flow a bit more).

Miquel started off the discussion by saying that he liked the book. He found it full of common sense ideas that companies generally ignore (or even do the opposite!). I liked the idea that most problems on software projects are sociological rather than technical.

Brett said that he had seen teams really coming together usually when there was a tight deadline to meet. But this didn’t usually last long. We then talked about overtime, which the authors are very much against. As a short term tactic to get a release ready it is fine, but once you start doing it for more than a few days then the downsides outweigh any advantages.

Miquel asked if the extra chapters in the 2nd edition had added much. There was a general consensus that the original book had covered most of the territory, so the extra chapters didn’t add a great deal.

Brett then said that although he had been an agile/XP enthusiast for some time, he hadn’t been able to apply these ideas because his work had always been quite isolating. Also, no-one he worked with was interested in trying any of these ideas out. I described how I use ideas such as the daily stand up meeting to help communication within the team.

Miquel pointed out that a literal reading of the book might suggest that stand up meetings are a waste of time and that everyone should be shut up in their own little office. This goes against a lot of agile thinking. But we agreed that if you look at what De Marco and Lister say closely they are against pointless status meetings and huge open plan spaces. Proponents of agile would tend to agree that stand up meetings should be short (that’s the reason you stand up) and that the best development environment is the war room. So there isn’t really much disagreement there.

I have read the book before, so there were less ‘a-ha!’ moments for me than the first time around. One thing I didn’t remember was the idea of a quota for errors, whereby a manager asks the members of his team what dead ends they have been down recently. The answer should not be ‘none’, because you would like people to experiment, which means sometimes failing.

Miquel liked the part at the beginning about the ‘High-Tech Illusion’ which makes managers think that they should spend their time thinking about technical issues rather than people issues. Not only are techie types better at solving those kind of problems, there is also this illusion that we ‘work in computers’. In fact, unless you are developing chips or writing operating systems you are just applying technology to solve real problems.

We moved on to talk about the idea of moving your development team away from the corporate building to actually get your project done. This sounded pretty radical and I was worried that it could hamper communication with other teams and with internal customers. I wonder if people really do this? I preferred the idea of getting your people to stay on extra days after a conference hotel to get some uninterrupted work time.

Finally we discussed the Black Team, which was an elite team of testers in IBM. The book holds them up as the best sort of jelled team, with their own in-jokes and even their own dress code (Black obviously). I was slightly concerned that their approach would alienate the people whose code they were testing. Lean teaches us that we should optimize the whole. If the feared Black Team don’t work well with their peers, will the whole development organisation work well?