Professional Management

This blog is moving to profmgmt.wordpress.com. The ecto client that I use to blog works so much better with wordpress that I'm moving to that. I am moving the old posts over slowly, but you can also see a flood of new posts too.

Our internal IT department has recently started splitting iterations of customer-valued work in boxes of a couple of weeks instead of using a full-blown waterfall methodology.

Under the old model, the customer received dates commitments and estimates of work. However, priorities changed quickly and the team needed to spend more time re-estimating and keeping the documentation uptodate than producing the software the customer actually valued. As a result, the development team was rarely able to deliver on useful software on time, and had to spend even more time communicating the delays. A vicious circle ensued. When software was eventually delivered, the business had moved on and the requirements were out of date (despite being signed off).

Now, the customer gets regular supplies of fresh software. The software is guaranteed fresh because requirements are only analysed in much detail at all for the next iteration. He knows that his latest priorities will be pretty quickly converted into working software every couple of weeks. He also sees something like a cumulative flow diagram showing a steady stream of working features being delivered to him. His need for time and date planning, for estimations and documentation goes down.

Have you ever been to a long drawn out status meeting where it seems the sole purpose is for the project manager to drag you through his MS Project Plan, line by excruciating line? This is how not to do a status meeting.

There are some simple guidelines for status meetings and they generally boil down to what you want to achieve. If the idea is to get a status update for each member of a project team, that can be better done one-on-one, although it will take more time from the PM. Instead, try to make effective use of the whole team being in one place to discuss constraints that affect them all.

My agenda for a useful meeting:
- What we have achieved (keep this brief)
- Our focus (again, keep this brief)
- What is stopping us -- where possible, invite comment to resolve constraints that affect the whole team or can only be resolved with a significant part of the team

If these meetings are held daily, standing meetings can be very effective in keeping people brief and to the point.

I was impressed again today by the simple idea of time boxing. This is a great first stage of iterative development. Instead of the classical waterfall approach, which overemphasises perfect requirements and detailed analysis, time boxing can allow a software development team a great 80-20 implementation. Most importantly, it focusses both the team and the customer on getting a good flow of valued software.

Our internal IT department, once the source of much scorn and complaint has moved from a very well documented (but rarely well executed) waterfall methodology to timeboxed bi-monthly iterations for one programme of work. Scope is agreed, but flexible. As the deadline of each iteration approaches, the development team is able and happy to push in some last-minute changes. However, the customer is happier to defer scope since he knows that there'll be another piping hot delivery of working software in just a couple of week's time.

I often use the analogy of baking when talking about software delivery. Eliciting requirements and then developing software is often like baking bread.

The customer and the development team have a good common understanding of the domain they are working in. White or brown, baguette or bloomer, both mean just about the same thing to the customer and to the bakers. The bread is baked that morning, and then it sits on the shelf. Once the bread is made, the clock is ticking. It needs to be eaten quickly. Once the requirements have been elicited, the software needs to be developed promptly. Otherwise, the business needs will change, or the technology landscape will change, or the user representatives or user base itself will change, or the competition will change. Whatever happens, change is the constant. Change in any of these and the piping fresh requirements will have gone cold and then stale.

That's one important reason agile development places such an emphasis on moving requirements through analysis (when this happens) to design to code to tested code, feature by feature as quickly as possible. The more this happens, the more time a software development team spends dedicating itself to adding value to a customer through working software and the less time it spends on wasteful activities.

I am having two weeks off and I am using the time to review and reflect on some TOC, agile management and project management theory, contrasting it with the experience and practice of the last few months. You'll see some of my ruminations appearing in the next few weeks.

Some of the TOC sites that I've been reading include:
http://www.goldrattcentre.com/
http://sales-system-management.ch
http://www.triz.org/triz.htm

Some of PM sites that I've been reading lately include:
http://www.pmi.org/
http://www.cheetahlearning.com/

Let's define effective feedback as information about a message that helps that the message produce the desired response.

People find it easiest to follow orders that tell them exactly what to do. Telling them what not to do leaves them with the burden of what to do. It's a little harder for you to think what they should do instead of what they should not, but it's dramatically more productive. Try it out: next time you are informing someone of what they you don't want them to do, give them one or more examples of what you would like to see instead. Notice that little extra work you need to do and the result of you what you say. Sometimes the reason that the recipient of the feedback has not done this is that it's a lot harder for them to think of alternatives that for you to. As you give successively more focussed feedback and they successively get closer to the desired response, it become easier for them to do so.

The response that a message produces can be partially correct. Great feedback pins down succinctly what worked so that it will continue to work next time. It also highlights what can be done in addition to get a response closer to that which is desired. These two elements can be combined a variety of ways:

• Plus /delta: the plus says what works and the delta says what to do differently
• 10/10: the first number says what works and how to get a 10 says what do differently
• Keep / try: the keep says what to keep and the try says to do differently

Keep / try is a way of giving feedback that Alistair Cockburn mentions in his "Crystal Clear, A Human-Powered Methodology for Small Teams". He uses it in his Reflection Workshops. These are short sessions held frequently to reinforce what works and to look at how to improve. In these workshops, he also recommends included a "problems" section allowing a least a little venting. Depending on who you have in your group this can be useful. It can also be very beneficial to get everyone to give feedback about what doesn't work in the form of how to change.

Note: what is important here is for the team to get fluent in using one of other of these techniques. In the early stages, some will 'get it' and others still be explaining how badly their team members screwed up. In later stages, sincerity becomes steadily more important: it becomes facile for some to simply say "You did great but this is how you can do better". The can open the door to a good deal of (justified) sarcasm. Instead, sincerity necessitates that team members really think through why they value the input from the rest of the team. A little goes a long way and leads to a virtuous circle: everyone leaning on everyone else.