The Design of a Team
Bit of a random walk, based on speaking, reading and dealing with numerous team learnings over a duration of time.
David Hanna provides a awesome quote that is worth re-reading to make sure you fully understand it:
All organizations are perfectly designed to get the results they get.
Team bashing to deliver results may not be the solution, although its unfortunately often the “management” style used when the results are not what the organization wants. Now think about the quote above. Maybe the organization has constructed the team, such that the team has essentially been set up to fail?
This lead to Paul Drucker when considering “management”. Mr Drucker provide 5 basis tasks of a manager. Success provide a good view on Mr Drucker’s management theory, likewise BusinessWeek. A few classic comments from Mr Drucker:
- Most of what we call management consists of making it difficult for people to get their work done.
- The most important thing in communication is hearing what isn’t said
- The productivity of work is not the responsibility of the worker but of the manager.
More recently Chris Parsons offered an insightful talk at the Scottish Ruby conference earlier this year, “Leading Software Teams Well”. The session is well worth listening to, specifically because it re-iterates some age old points, which are unfortunately often still lost today due to bad leadership and management. A few key points:
- Management structure often gets in the way
- Leadership is NOT management. Management as per an assembly line is legacy in software engineering – you can’t control people!
- Task delegation😦 An agile anti pattern if ever there was one.
- Job titles – I’ve always found job titles to generate the silo mentality on teams, generating Microsoft Excel resource movements :( Trial before hire is definitely the best approach is possible – compromised hires will cost you and your company serious money
- Stop the finger pointing within a team!
- Raise your replacement!
This leads me to BDD, and the issue I have with CV’s that says they follow BDD, but actually a person just followings general “testing”. This is better clarified by surfing over to the Agile Alliance web site, and the BDD page, which in my view provide some very well written points on “Sign of use”. Specifically, think about the implications of following compared to you usage of “testing” today, and the possible breakage from story (with acceptance criteria/tests) to code:
- A team using BDD should be able to provide a significant portion of “functional documentation” in the form of User Stories augmented with executable scenarios or examples
- Rather than refer to “the unit tests of a class”, a practitioner or a team using BDD prefers to speak of “the specifications of the behavior of the class”. This reflects a greater focus on the documentary role of such specifications: their names are expected to be more expressive, and, when completed with their description in given-when-then format, to serve as technical documentation.
Which brings up another anti-pattern – Cucumber is a testing tool. If your of this view, then consider having a read of this posting. Dan North provides further BDD samples here, specifically around story’s being “the result of conversations between the project stakeholders, business analysts, testers and developers”. For me, a well written story with acceptance tests (AT) which generates code and “tests” that don’t leverage the work put into Given-When-Then AT’s seems like a broken pipeline – even more so if the AT’s are leveraging a DSL when written prior to coding.