I went to the 59 Minute Scrum  session last October which sounded interesting - from the blurb:

"This session will give attendees a unique opportunity to experience agile practices first hand in a non-technical environment."

I had good expectations but was left a little under-whelmed at the actual event. Now I have to admit that I arrived late and missed the intro so maybe it's all my fault and the intro answered everything! (Discussion over a beer afterwards showed I wasn't totally alone though).

The format was to split up into teams and discuss various scenarios. These were implementation projects including marketing, programmes and anything else we fancied on topics such as: a theme park around "spam", a health club for pets and a space tourism project.

The event was fairly tightly timetabled so we had a slot to discuss our backlog, then split up further in our teams to actually come up with ideas on particular areas. Then round 2 for more implementation. Finally, all the teams (8 if I remember correctly - typically 2 per idea) presented their solutions to the whole group and touched briefly on how well they had addressed the backlog/made progress etc.

There was then an all-too-brief Q&A session at the end.

For me the format didn't really work. I was left with too many questions and faffing about in the exercise had very limited benefit. I would much rather have had a well though through presentation on Scrum with lots of time for questions. At most half an hour of some exercises and then a presentation and lessons learnt would have worked much better for me.

Maybe I am just becoming a stick-in-the-mud?! I am likely to stear clear of such sessions in the future though unless there is time for a solid hour or more afterwards to get into details and ask questions.

I was at an event fairly recently where I did a short presentation on Agile SCM. During the presentation, I surveyed the audience about their awareness of agile development methods and practices and was rather surprised at the result. There were about 50 people, most of whom were very experienced developers who tended to be working on contract and were well up-to-date on Microsoft tools etc.

Remarkably few had even heard of things like XP (eXtreme Programming), FDD (Feature Driven Development), SCRUM and DSDM (for example 3 people said they were doing agile development and another 3 or so said they knew of it). That said, when I went in to some agile practices such as continuous integration another half a dozen put their hands up.

There are a couple of responses to this:

• There is a marketing problem for Agile Methodologies
• Developers are not keeping up to date with the industry

Regarding the first response, I think that this is progressively being addressed through internet articles, books, seminars etc.

The second perhaps shouldn't have surprised me so much, although it did. It would appear that there are a large number of developers and others involved in software development who just treat it as a job - go to work, do it, go home. They seem to keep their heads down, not read magazines, articles and related things, and basically not stay abreast of developments in their industry. These are bright and clued up people technically! But think of a dentist who didn't keep up-to-date - how long would he or she keep their patients? My dentist has his certificates of "continuing professional development" up on his wall - it gives me a good feeling when I'm lying in the chair!

I think that professional development is a pre-requisite for anyone in any field. And excellent treatise for software development is Dave Thomas's "How to Keep Your Job"; and a couple of useful points at Coding Horror: Be Good at your Job. An interesting take is How to Prevent Offshoring Taking Your Job

Perhaps on a related note I can singe the praises of the geographical and specialist groups - the people that I see attending these meetings are the ones who will do well. The BCS provides some excellent professional development support to individuals and to companies.

I'd also like to put a plug in for Toastmasters International - a global organisation for improving your public speaking skills. I have found it very useful myself (and can recommend London Corinthians for those who can get to Victoria!).

Having been on a few volunteer committees, my rules of thumb are:

Commitment Breeds Rewards

Putting your hand up to be involved and active on a committee is a great way to get started, and truly magnifies what you get back.

There's nothing like a few committee meetings to start to get know people. That then leads to all sorts of links, tie ins etc. Even a brief spell on a committee can reap you benefits for years afterwards. Read Alan Weiss ("Million Dollar Consulting" and similar books) for some ideas on this.

Only a few people actually do the work

There are always a few key people who actually do the work. Find out who they are and work with them. The old saw about getting something done by giving it to a busy person, is oh so valid.

Ideas vs. Actions

A corollary to the above - lots of people have great ideas for this, that and the other. When it comes to implementing the ideas, the idea generators are not to be seen. If I am organising something then I always treat ideas as "nice to have" until someone signs up to take responsibility.

Pretty much any implementation, however bad, beats any number of virtual ideas.

Sustainability

Groups wax and wane according to the needs and energies of the committee and the members of the group. Decisions that are taken need to have at least half an eye on the future, and in particular how sustainable something is. Activities such as maintaining a web site need to be done with technology such that some else can take it over in the future. Using a specific tool just because it is convenient for you or you have access to it at work, leads to you not being able to hand it over.

Which Groups Should I Belong To?

There comes a time when a group becomes much less useful to you, and it is time to move on. Re-evaluate groups and commitments regularly (perhaps a couple of times a year), and change when appropriate. This is an idea I got from life coaching - evaluate activities and work out if they are energy boosters or energy drains for you. Remove the drains!

One of the key XP (Extreme Programming) Practices is that of Pair Programming – two programmers working side-by-side at one computer collaborating on the same design, algorithm, code or test. The XP advocates state that higher quality products are produced faster, inspite of what appears at first sight to be an overtly redundant, wasteful use of programming resources.

The interesting thing that I have found is that when I teach SCM training courses with hands-on exercises (where people work through exercises against a pre-prepared repository), I usually get much better feedback and results if those present do the exercises in pairs.

Benefits

The advantages that I see are:

• a higher level of "hubbub" in the room - an indication of information exchange and reinforcement, resulting from more discussions both within and between pairs
• greater willingness to ask questions of the trainer
• faster progress through the exercises

My feeling is that pairing gets over a variety of inhibitors. It is quite easy when doing exercises to get stuck thinking you ought to know the answer (usually in the materials presented in the last session), and people work away for quite long periods without progressing. More importantly from a trainer's point of view, people are often somewhat reluctant to ask questions and thus show that they have a problem (this tendency can vary significantly between different nationalities).

There are other factors at work:

• if there is an active internet connection available on the machines then individuals are more likely to surf the net or check their emails than a pair
• a pairing of more/less experience people brings greater knowledge transfer

Disadvantages

Some people find it inhibiting to work in a pair. They have a certain learning style and this doesn't mesh well with their potential partner. Also, levels of experience can vary quite widely, leading to boredom and less learning for the more advanced person (though usually with benefits for the less advanced).

Some people prefer to be able to take detours and investigate functionality on their own, and are inhibited from doing this in a pair (which is a shame).

Applicability

Pair exercises work extremely well for in-house courses where all those present work for the same company. They usually know each other and are able to pair up easily and quickly.

Not surprisingly, I do not find it so applicable with public courses where only 1 or 2 people per company are present, and the level of preparation and relevant prior knowledge and experience can vary significantly among those attending.

The other keynote at the  XPDay conference last December was Mary Poppendieck on the theme of her book Lean Software Development.

"Make More Money"

The title certainly grabbed people's attention. The key point being that you make more money by increasing your ratio of outputs to inputs.

Productivity in software has had its peaks and troughs in recent years, whereas in manufacturing, productivity is continuing to rise (there was a plateau around 2000/01 but not it's heading up again). Companies who do well look at their core business processes which are what drives productivity. They then chose where to match industry norms and where to lead (and they pick a few areas to excel at). They focus on end to end improvement. You lead in a decade not in a year so it's not a short term thing. She referred to the book by James Collins, Good to Great.

Looking at the productivity levers for software:

• What are the processes involved in turning an idea into a product?
• How do you translate customer needs into software? (This isn't what they ask for it's what they need!)
• You need to manage your development portfolio (resources and capacity)
• Deploy complete solutions - are you fully invested in the success of your customers?
• Managed the full lifecyle - design for maintainability.

Another large lever is marketing but that wasn't the subject of the talk.

A key way to improve your productivity is: Do Less Work

Reduce Direct Costs

Reduce the direct cost by providing only what the customer will pay for. A quote from Jim Johnson of the Standish Group: users typically use only 25% of the system - 65% of features are rarely or never used (see Martin Fowler's writeup of XP2002).

Where do all these extra features come from?

• we ask the customer what they want
• we reward them for thinking of everything ("scope")
• we penalise them for adding features later ("scope creep")

She referred to the following book which talks about MMF - Minimum Marketable Feature Set (Mark Denne & Jane Cleland-Huang, Software by Numbers; Low-Risk, High Return Development, Prentice Hall, 2004). This assumes you are deploying early and often.

Reduce Indirect Costs

Streamline your processes to eliminate waste.

Streamline the core processes to provide rapid delivery of value (cost reductions that reduce customer value do not increase productivity - beware of mindless cost cutting!).

The measure of an organisation's maturity is the speed it can reliably and repeatedly execute key processes. For software this is the speed that customer needs get turned into deployed code.

She referred to the Value Stream Mapping process in her book (see link above), and how to change your processes to remove delays.

Get support people involved in the development and design of a product to ensure that it can be deployed appropriately.

Increase Output (Value)

Do this by shortening the customer feedback loop.

Improve customer productivity - when they win you win. A case study - Dell realised after some customer visits that there was a whole new business in delivering preconfigured PCs. This increased both revenue and customer loyalty.

How can you help your customer?

• Map their value stream
• Extend the value that you offer

Conclusion

Another interesting keynote. Covered a fair amount of stuff from her book, but with some interesting twists that made it very relevant. I also attended her workshop, and some key points from that:

• to get predictable outcomes don't predict - make decisions based on facts not forecasts
• if you can't deliver fast, you can't delay commitment
• speed of software development can have a bad name but is a fundamental competitve advantage
• improve depolyment by testing earlier and making rapid small releases
• to move fast you can't tell people what to do - they have to know for themselves ("information radiator")