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.
This term simply stands as a reminder for, how many people need to get hit by a bus to leave you without anybody being familiar with one of your mission-critical applications. If the number equals one, you might re-consider your strategy…
Don’t forget, there are also more common ways for developers to go somewhere else (better offer, kids, sabbatical etc).
In an article from 1968 with the title “How Do Committees Invent?”, the author Melvin Conway makes the following point, which later became established as “Conway’s Law”:
“Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’s communication structure.” (Original Article) (Conway’s Law on Wikipedia)
Conway suggested an approach containing the following steps:
- Define your business mission.
- Learn the business processes from the business owners.
- Re-engineer these business processes to match their mission.
- Structure your IT to support no 3.
His concluding points:
- Design according to the need for communication.
- Your design will never be perfect because things change and require your processes to adapt accordingly.
- Reward people who keep the organization lean an flexible.
- Adding more manpower does NOT equal adding productivity into a design effort.
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?