Day Camp 4 Developers: Project Management

Just over three of weeks ago I attended the third online Day Camp 4 Developers event, which this time focused on the subject of project management. The DC4D events are aimed at filling the "soft skills" gap that software developers can suffer from, and rather than being a "how-to" on project management (arguably there are already plenty of other places you can learn the basics) the six speakers covered a range of topics around the subject - some of which I wouldn't initially have thought of in this context (for example, dealing with difficult people). However as one of the speakers noted, fundamentally project management is as much about people as it is about process, and all of them delivered some interesting insights.

The first talk (which unfortunately I missed the start of through my own disorganisation) by Brian Prince about "Hands-on Agile Practices" covered the practical implementation of Agile process in a lot of detail. I've never worked with Agile myself, but I have read a bit about it in the past and Brian's presentation reminded me of a few Agile concepts that sound like they could be usefully adopted elsewhere. For example: using "yesterday's weather" (i.e. statistically the weather tomorrow is likely to be the same as today's) as a way to plan ahead by considering recent performance; and the guidelines for keeping stand-up meetings concise could also be applied to any sort status meeting (each person covers the three points "what I did yesterday", "what I'm doing today and when it will be done", and "what issues I have"). The idea of focusing on "not enough time" rather than "too much to do" also appealed to me.

The next presentation "Dealing with Difficult People" by Elizabeth Naramore turned out to be an expected delight. Starting by asking what makes people you know "difficult" to interact with, she identified four broad types of behaviour:

• "Get it done"-types are focused on getting information and acting on it quickly, so their style is terse and to-the-point,
• "Get it right"-types are focused on detail, so their style is precise, slow and deliberate,
• "Get along"-types are focused on making sure others are happy, so their style is touchy-feely and often sugar-coated, and
  
• "Get a pat on the back"-types are focused on getting their efforts recognised by others, so their style is more "person-oriented".

The labels are instantly memorable and straight away I'm sure we can all think of people that we know who fit these categories (as well as ourselves of course). Elizabeth was at pains to point out that most people are a mixture of two or more, and that none of them are bad (except when someone is operating at an extreme all of the time). The important point is that they affect how people communicate, so if you can recognise and adapt to other people's styles, and learn to listen to them, then you'll stand a better chance of reducing your difficult interactions.

Rob Allen was next up with "Getting A Website Out Of The Door" (subtitled "Managing a website project"), and covered the process used at Big Room Internet for spec'ing, developing and delivering website projects for external clients. Rob included a lot of detail on each part of the process, what can go wrong, and how they aim to manage and reduce the risks of that happening. One specific aspect that I found interesting was the change control procedure, which is used for all change requests from their clients regardless of the size of the change, essentially:

• Write down the request
• Understand the impact
• Decide whether to do it
• Do the work!

I think that the second point here is key: you need to understand what the impact will be, and how much work it's really going to be (I'm sure we've all agreed at one or another to make "trivial" changes to code which have turned out in practice to be far more work than anyone first imagined). A more general point that Rob made was the importance of clear communication, particularly in emails (which should have a subject line, summary, action and deadline).

Rob was followed by Keith Casey talking about how "Project Management is More Than Todo Lists". One of the interesting aspects of Keith's talk was that he brought an open source perspective to the subject. In open source projects the contributors are unpaid and so understanding how their motivations differ from doing work paid work is important for the projects to successful: as Keith said early on in his talk, in this case "it's about people".

He argued that people managing open source projects should pay attention to the uppermost levels of Maslow's Hierarchy of Needs (where the individual focuses on "esteem" and "self-actualisation"), but there was also a lot of practical advice: for example, having regular and predictable releases; ensuring that bugs and feature requests are prioritised regularly, and that developements should be driven input and involvement by the community. I particularly liked the practical suggestion that frequently asked questions can be used to identify areas of friction that need to be simplified or clarified. He also recommended Karl Fogel's book "Producing Open Source Software", which looks like it would be a good read.

Thursday Bram's presentation "Project Management for Freelancers" was another change of direction (and certainly the subtitle "How Freelancers Can Use Project Management to Make Clients Happier than They've Ever Been Before" didn't lack ambition). She suggested that for freelancers, project management is at least in part about helping clients to recognise quality work - after all they're not experts in coding (that's why they hired you), so inevitably they have an issue with knowing "what does quality look like?". (If you've ever paid for a service such as car servicing or plumbing then I'm sure you can relate to this.) So arguably one function of project management is to provide a way to communicate the quality of your work. The key message that I took away from Thursday's talk was that "what makes people happy is 'seeing progress' on their projects". Again I felt this was an idea that I could use in my (non-freelancer) work environment.

The last session of the day was Paul M. Jones talking about "Estimating and Expectations". Essentially we (i.e. everyone) are terrible at making estimates, as illustrated by his "laws of scheduling and estimates":

• Jones' Law: "if you plan for the worst, then all surprises are good surprises"
• Hofstadter's Law: "it always takes longer than you expect - even when you take Hofstadter's Law into account"
• Brooks' Law: "adding more people to a late software project will make it even later"
  

However there are various strategies and methods we can use to try and make our estimates better: for example, using historical data and doing some design work up front can both provide valuable knowledge for improved estimates. In this context Paul also had my favourite quote of the day: "It's not enough to be smart; you actually have to know things" (something that I think a lot of genuinely clever people can often forget, especially when they move into a domain that's new to them).

It felt like Paul packed an immense amount of material into this talk, covering a wide range of different areas and offering a lot of practical advice drawn from various sources (Steve McConnell's Code Complete, Fred Brooks' The Mythical Man Month and Tom DeMarco and Timothy Lister's Peopleware: Productive Projects & Teams were all mentioned) both for estimation techniques and for expectation management - where ultimately communication and trust are key (a message that seemed to be repeated throughout the day).

In spite of a few minor technical issues (the organisers had opted to use a new service called Fuzemeeting, which I guess was still ironing out some wrinkles), overall everything ran smoothly, and at the end I felt I'd got some useful ideas that I feel I can apply in my own working life - in the end surely that's the whole idea. It was definitely worth a few hours of my weekend, and I'm looking forward to being able to see some of the talks again when the videocasts become available. In the meantime if any of this sounds interesting to you then I'd recommend checking out the DC4D website and watching out for the next event!

Day Camp 4 Developers: Telecommuting

About two weeks ago I took part in the second online Day Camp 4 Developers, on the topic of telecommuting. The idea behind the Day Camp events is to provide software developers with practical knowledge and advice in the area of "soft" skills, to complement their expertise with "hard" skills (i.e. actual coding). In this case five speakers gave consistently excellent web presentations (slides and audio) with different perspectives on remote working, while an IRC chatroom gave all participants a forum to discuss the issues behind the scenes.

Lorna Jane Mitchell started off by asking "Could You Telecommute?". As a teleworker herself, Lorna Jane looked at the environmental, organisational and personal factors that influence the happiness and productivity of the remote worker: for example, ensuring you have a good home working space, and set clear boundaries between work and personal life (both for yourself and for others). In particular you have to be aware of the tendency for other people to think that working from home is easy, and that your time is infinitely flexible. She also noted that there are some big differences between being part of a distributed team and being a telecommuting member of a co-located team (where you risk feeling isolated), and further differences between employees and freelancers. Particularly for lone telecommuters, it's important to build professional and social support networks that might otherwise be taken for granted in more conventional work settings.

Next self-described "entreprenerd" Ivo Jansch talked about "The Business Case For Telecommuting". Ivo's company Egeniq is built around a distributed team (essentially using remote working as an organisational model) - so in addition to benefiting individual workers, he suggested ways that telecommuting could positively impact the company's bottom line, for example enabling access to an bigger talent pool and increasing its geographical reach (if providing consultancy services). He acknowledged that this distributed model won't suit every company or industry however, and success requires (amongst other things) a results-driven culture where individuals are trusted to self-manage and have a sense of shared responsibility. Ultimately good communication between team members is paramount.

After the lunch break, Jack G. Ford gave a manager's perspective on setting up a telecommuting programme in his presentation "Can I Work From Home Tomorrow?". Jack introduced himself as an ex-coder who is now the manager for 17 developers in a more conventional environment than Ivo's, but in spite of that his key points seemed remarkably similar: beyond asking whether the company infrastructure can support remote working, the main issues are trust (both with the manager and with the team) and good communication between the manager and the individual. Jack emphasised that as a manager, when you telecommute, "I can't see you," so the telecommuter must stay connected, keep the manager informed, and must not only act professionally but be seen to do so. Although it might seem obvious, this was a fascinating insight into telecommuting from the other side of the management chain.

Ligaya Turmelle's presentation on "Managing the Work/Life Balance" emphasised the challenges of balancing work and home life, with her lists of "the good, the bad and the ugly" of remote working from a teleworker perspective. Ligaya focused especially on balancing family commitments with work commitments, and among some interesting observations (for example, no longer doing the daily commute means you lose some "me time" to yourself), I was most struck by the admission that if you love your work then it can mean sometimes that you want to go on working, and are in danger of not respecting your own ground rules. While noting that situations can differ both for individuals and companies, her advice was: clarify everyone's expectations (e.g. policies for "on-call" hours, weekends, and holidays); set up ground rules and limits (and be disciplined in adhering to them); and try to be flexible and imaginative in how you approach your work.

The final presentation was Avdi Grimm talking about "The Well-Equipped Remote Worker". Avdi is a freelance software developer who is also a "dispersed teams facilitator" and runs the Wide Teams blog. As might be expected from the title, some of the focus was on the hardware and software tools that can help with remote working, but there was just as much information on practices that can support distributed teams. Once again promoting communication is key, and using tools and practices that help team members create good working relationships (for example, utilising social media like Twitter and Facebook, and holding regular face-to-face meetings) can really contribute to this.

Looking back over all the talks, a few common themes had emerged for me:

• Good communication (both with managers and with other team members) to build trust, keep people informed and avoid misunderstandings;
• Clarify expectations on all sides, and establishing well-defined boundaries between work and personal life. Set ground rules to ensure that those boundaries are respected by others (your boss, your family and friends) and have the discipline to also respect them yourself;
• Build and maintain your social and professional support networks for when there are problem times;
• Provide yourself with a good working environment and (software and hardware) tools.
  

I was also able to relate some points to my own experiences: when I worked briefly as a remote member of a co-located team, I did feel a real sense of isolation; another time as a home teleworker I got the impression from some people that they assumed (not maliciously) that I only did a few hours work a day; and previous experience as part of a large organisation makes me feel that there was some truth in Ivo's comment that "co-location is over-rated", in that it doesn't automatically lead to great communication between individuals or groups.

Overall it was an excellent event and a good use of 8 hours of my Saturday - although the time difference (coincidentally another telecommuting issue) meant that it didn't finish until 10pm UK time I surprised myself by staying with it to the end. Hats off to Cal and Kathy Evans for organising the day and to the speakers for their excellent presentations. Here's waiting for the next Day Camp 4 Developers!