Since feedback is a form of communication, excessive feedback will have the effect like an explosion in communication paths and will eventually produce more noise than signal.
Any feedback loop in the system must help facilitate the management of change and efficiently adapt requirements along the the way. If this is not the case for a feedbackloop, folks will try to avoid it.
As developers we also experience a decrease in quality and value of feedback if it is not immediate enough and/or requires too much effort from a team member to receive it. So most of the feedbackloops are built right into modern software development. Take a look at the following list of areas where a software development team or team member receives feedback in different forms:
- Your IDE checks syntax and indicates errors before you hit ‘save’.
- A release demo for your customer generates prose user feedback.
- Commit hooks refuse your changes.
- Deployment on development and staging systems works or doesn’t.
- The Compiler compiles or refuses to compile and returns errors.
- Daily standup meetings serve as publishing institution of individual statuses, schedules and problems. Team members get updated, help each other out or problems get escalated up the command chain.
- Pair programming for direct feedback from colleagues on development skills, technical decisions, used tools etc.
- Sprint reviews reflect development processes, collect team feedback and improve them.
- Test driven development repeatedly asserts requirements and APIs of existing and future components and their interdependencies.
- The continuous integration server runs all test suites, generates documentation, runs the build, code sniffer etc. and informs the whole development team if something goes wrong.
I hope this article serves you as a short reminder for where and how feedback can create value in your software projects. And remember: Software is written by humans and feedback is the opposite of thought-reading, which often leads to unnecessary friction and pain.
I have just received a new book: “Apprenticeship Patterns“: Skimming through the first pages I noticed the words in the 3rd column extending from the points in the 2nd column and thought, ‘Hmm, I have heard about these 2nd column points’…
The following table popped up in my mind, which I would like to share with you:
Software development practices:
|processes and tools
||Individuals and interactions
||but also a community of professionals
||but also well-crafted software
||but also productive partnerships
|following a plan
||Responding to change
||but also steadily adding value
Any ideas for a 4th column? Looking forward to actually reading the book…
I recently played the ballpoint game for the first time and was impressed…
- … how clearly it demonstrates the different phases of a team going through the ‘storming, norming and performing’-phases for everyone – even for management spectators.
- … how the iteration-rhythm helps to keep focus and increase the team performance to a very high and predictable level.
- … how easy it felt to deliver good results once the team started to perform after the 2nd and 3rd iteration.
- … how much fun it can be, to be part of and work in a cool software develoment team.
You can find various explanations on how the ballpoint game is organized and played.
Here is a nice video that illustrates what happens through the iterations: http://www.youtube.com/watch?v=d4-El7gJuZE
Thanks to Stefan and René for the inspiration!
Inspired by the Podcast ‘Tips and Advice – Manifesto for Agile Software Development‘ in which Bob Payne and George Dinwiddie discuss the points made in the Agile Manifesto and talk about agile environments and mechanics. If you would like to discover the power of agile teams you should definitely check this one out!
They also mention the term ‘Generalizing Specialist’. Scott W. Ambler wrote about this kind of developer in his essay ‘Generalizing Specialists: Improving Your IT Career Skills‘. This is a kind of developer who is constantly learning and playing with adjacent topics and thus widens his knowledge over the years of his worklife. The effects and advantages for the team, the project owner and the developer are depicted nicely in this essay.
Sometimes you come accross something and pause thinking ‘I have experienced exactly that’. So it happend when I read Scott Ambler’s post ‘Bureaucracy Isn’t Discipline’.
Here are the main points and in my view ammunition for philosophical discussions:
- Successful agile practices demand great discipline and require significant skill and experience to actually get stuff done.
- Just following repeatable processes rather than focusing on repeatable results are ‘process smells’ and seen as anti-pattern.
- Delivering repeatable results in agile environments is critical to success in IT projects.
- Mistaking bureaucracy for discipline is a reflection of cultural damage that has occurred over the years to large organizations.
- This bureaucracy is seen as inhibitor to software process improvement efforts and particularly to agile methodologies.
- A cultural shift towards agile will make many ‘bureaucrats’ uncomfortable.
I think, the approach to use a defined set of formal processes (bureaucracy) comes from the management people who hope to reduce risk and thus ensure repeatable production results. On the other side there are the natural constants of the IT environment with its complexity, constant evolution on all layers, life-cycles etc.
In my opinion, a possible solution could be found between these two extreme views if…
- hierarchies are kept flat or are at least perceived as being flat.
- communication-paths are reduced to the least required number and everybody knows what exactly his job is and what skillset this requires.
- an open, friendly, frictionless and goal-oriented culture gets established and maintained (preferably top-down).
- the system allows the players to focus on and finish their tasks and have a feeling of accomplishment.
VersionOne have published their 3rd Annual ‘State of Agile Development’ survey: Results are available on this page or as pdf.
Overview of topics covered:
- State of agile methods.
- Mix of participanting companies.
- Reasons for adopting agile methods.
- Concerns against it.
- Practices applied.
- Reasons for failures.
- Where agile creates value.
- What tools are used.
As projects and teams I am working on get more interwoven and organizational issues and management processes are gaining more and more traction on the 3 project dimensions time, budget and quality, I was thinking about what I would do as a manager in charge to let steam off the many issues we were facing and become productive again.
A low hanging fruit I identified, was the overall uncertainty about the many projects and tasks running at the same time with nebulous requirements and developers working in parallel on many things without clear priorities, which resulted in an ad-hoc development and fixing-style of work. This created an atmosphere in which it was nearly impossible to plan – a vicious-circle.
As a consequence I was thinking about how we could …
- … make the ongoing project-related processes more transparent to all participants (Chicken and Pigs),
- … display project progress, status, expected outcome and deadlines, and
- … visualize the current consumption of available ressources and the team’s mood.
During my research I came accross the term ‘Big Visual Charts’. Once you enter the arena of visualizing processes, you will also come across closely related topics like Kanban (Japanese for card or sign) and Lean Production.
- Hand-made drawings on a wall draw more attention than everything electronically distributed or printed stuff. They are easy to maintain and unique.
- Capture what is important for success, spotted problems, especially recurring ones. Capture good things and bad things equally.
- Do not be fingerpointing in your visualizations, just display facts to trigger goal oriented behaviour. Your goal is always to become more effective through behaviour adaption.
- As time goes by, your charts evolve and display certain patterns which work as trigger for people to come together and find solutions as a team.
- A central project dashboard helps the team and the project stakeholders to understand the bigger picture, what they are currently doing, what comes next and what they want to focus on. It helps the team to self-organize and prioritize tasks.
Examples and inspiration:
One nice example of a project planning board is this one from the ‘Agile in Action’ site. See ** link from the above list for explanations.
Nice to see the Southpark icons for each team member ;).
This one focusses on the planned stories (green) plus incoming change requests (yellow) and defects (red) to be fixed. It becomes obvious if there where fewer changes and less defects, the team could concentrate more on the production of story points. See * link from above list for explanations.
A burndown chart in Scrum showing the remaining stories in the project backlog. It also visualizes the progress towards a deadline. See **** link from the above list for explanations.
There are many more chartable things:
- Show team velocity, the number of story points finished or how many ‘ideal man-days’ your team spent actually in production per iteration. This knowledge will also help you plan more accurately in the future.
- Defects reported and defects fixed.
- Unittests and actually working unittests, or code coverage of your test suites. Discover how better code coverage and more tests affect reported defects and leave more time to be productive in other areas in the future or reduce overtime.
- Hours spent pair-programming.
- Track unplanned interruptions by adding a red sticker on a calendar or the story card you are currently working on.
- Team code ownership, number of people contributed to certain modules or average contributors.
- Last date the boss ordered pizza for the team.
If you engage in agile development methods, sooner or later you will come accross the ‘Chicken and Pig’ analogy. It’s purpose is to depict the different levels of commitment of project stakeholders. It summs up like this:
A chicken and a pig decide to start a restaurant. The chicken suggests to serve bacon and eggs. The pig responds, “No thanks. For you, bacon and eggs is simply involvement. For me, it is total commitment!”
This translates into: Chicken, while still project stakeholders, are only losely committed to the project and are not accountable for deliverables. And Pigs are the ones held accountable for deliverables (developers, architects, designers).
Now, how can you translate this controverse picture into being more productive with your team and still love your work without getting fried or frying colleagues?