Reflections on Tech-Ed 2007 - Part 3

In the previous post I listed what I found to be highlights out of the sessions I attended. This post continues the discussion of these session highlights.

DEV309 – Best Practices for Team-based Development

This session, presented by Lukas Svoboda, reminded me of Steve McConnell’s “Rapid Development” in its presentation of ‘classic mistakes’ that jeopardise the success of a team or project, as well as the signs that point toward success. Many of these may seem obvious, at least subconsciously, but there was value in seeing these items formalised and in reconfirming what may have been said / experienced before.

These items can be used to form a checklist that would be used to assess how well a project is going:

• Is there adequate direction? Is the vision of this project well-defined?
• Are deadlines and estimates fair and realistic?
• Are the defined requirements clear and logical?
• Are the defined requirements correct according to the vision of the project?
• Is there adequate customer involvement and feedback?
• Does every team member understand the value of each task?
• Does the quality of the deliverables meet or exceed expectations?
• Are team members able to carry out their work at a comfortable pace without being unnecessarily slowed down?
• Are risks mitigated effectively?
• Are problems dealt with effectively and efficiently?
• Do team members feel a sense of responsibility and pride for their work?
• Are team members comfortable working with each other, and free from personality conflicts?

As an aside, it’s good to know that even though “Rapid Development” is 11 years old, it is still relevant today. The obvious advancements not mentioned in 1996 include Continuous Integration (as opposed to daily / weekly builds) and Test-Driven Development.

In this session there was also quite a discussion of related concepts that extended beyond “Rapid Development”. A major theme was organisation of information – and how the lack of it can lead to ‘collaboration chaos’ where information is scattered across e-mail, instant messaging, meetings, phone calls, scrap paper and web pages (e.g. wikis). Lukas illustrated how the degree to which information is organised and processes are standardised influences the level of maturity of the team. It became clear that the lack of such organisation leads to a high degree of risk and waste, and can lead to miscommunication.

Lukas also presented a good analogy to help explain why it can be so difficult to deliver the right product on time – as formulating a recipe. Just like in cooking, successful projects have a recipe for achieving the set goals. The thing is that this recipe has to be continually tested and evolved in order to improve the outcome. On new projects, there is also skill required in selecting the right ‘ingredients’ as appropriate for the team and project. One size does not fit all. The ingredients used to make a steamed pudding aren't the same ingredients used for nachos.

Apart from picking methodologies as ingredients, much difficulty in delivering the right product on time can also arise from human factors. There is often inertia to change, possibly out of fear for the unknown. However the degree of this inertia can be significantly reduced if the changes are small and made often – just like in agile (as opposed to ‘big-bang’) development.

The recommendation from the Interface Design Patterns session of being multi-disciplinary also applies in the day-to-day running of a project. It was good to see the points of view of the different roles (developers, testers, analysts, etc.) in a software project summarised as points on a slide, relating to their respective areas of concern and responsibilities within a project. It is important to have this understanding of how the others think, so that team members can make each other's jobs easier. Just because one member is a developer, for instance, doesn't mean that this person is stuck doing only development tasks and therefore can't assist with or give value-added input for analysis, testing or design.