Part 4: Constant evaluation and improvement: Finding sources for feedback. #
In recent years demand for shorter feedback cycles especially in software development has increased. Agile development,
lean management and even Scrum are all for short feedback cycles: Coming from the dark ages when software projects
would last for months or even years before any results could be delivered to customers we are transforming development
into a process that integrates the customer in the design and evolution of his own product. Developers have learned
that planning ahead for years does not work: It’s not only customers changing their mind so fast, it’s requirements
changing quickly. The only achievement from months-long cycles is getting input on your work later, being able to hide
deficiencies longer.
However not only for planning and management does it make sense to install fast feedback
loops. A few days ago I finished reading the book “Apprenticeship
patterns”. A book that gives an overview of various patterns that help improve software development
skills.
One major theme was about getting fast feedback constantly. On the (agile) development side, automated
tests (unit and integration) and continuous integration systems are technical aids that can help. Pair programming and
code review take the idea of fast feedback one step further by having humans give you feedback on what cannot possibly
be evaluated automatically.
There is just one minor glitch: With really short feedback loops any mistake you
make gets revealed instantly. This is not particularly special to agile development. Another area with these kinds of
fast feedback loops are projects developing free software - see also the last paragraph in Bertrand’s blog on This is how we work at
Apache.
There are developers who have a hard time living with exposing their work to a wider audience
quickly. However it has the huge benefit of revealing any errors as early as possible - ideally at a point in time
where fixing them is still cheap. Examples for options spotting mistakes early in various environments are listed
below:
- Open source development: Mistakes are revealed during code review of patches (or
checkins).
- Scrum: Speeding up error spotting can be implemented by closely integrating the product owner during
each sprint. As soon as a feature is done - according to the developer team - it gets reviewed by the product owner
this way reducing risk of features getting rejected during the sprint review.
- In the team: Get each change set
either mailed to all developers allowing for fast review of incoming code.
These are all good ways for feedback, however what about non-coding areas? Are there ways to build fast feedback into tasks that do not involve coding? I’ll pick just one example to highlight some ways that facilitate fast feedback in a non-coding environment.
From time to time even hard-core coders have to meet face-to-face to discuss new designs, learn more about customers’ requirements. This may involve going to conferences, giving talks, organising internal workshops, public meetups or even conferences.
Usually people doing the organisation are too busy to “watch what happens”: They already drown in tasks to do and have no time (and are in no good position) to objectively evaluate the conference’s quality.
Still there are ways to build feedback loops even into this kind of setup. Most of them have to do with communication:
- Ask people to give you feedback in an official feedback form: Don’t
expect more than a fraction of the actual attendees to answer that form. Still it can be a source for honest feedback
when done correctly. Include a few open questions, don’t ask people to rate each and every task - they’ll never find
the time to do that anyway. Read the free-form comments - usually they provide way more insight than any rating
question anyway.
- Talk to people, ask for proposals on what you should do differently next time.
- Watch
what people are telling on the net - however keep in mind that those statements usually are a bit biased showing only
the extreme ends of the spectrum.
The same applies to people giving presentations: Talk to people from the audience after your presentation is over. If your talk was video-taped, you are in a really great situation, as now you can judge for yourself what should be improved and where there are glitches in your arguments.
According to my experience people very rarely give explicit feedback - except when being really disappointed or extremely positively surprised. However when asked for precise feedback on specific aspects people are usually more than willing to share their experience, tell you where to improve and what to change. Usually it turns out to be a good idea to actively seek out people for evaluation of your projects to get better at what you do, to encourage peers to tell you what you do wrong or even where you could get slightly better.