I recently had an interesting conversation with a colleague about team productivity. He had just returned from a conference which included a “hack day” component where small teams would develop a product of their choosing (within constraints) over a single day, presenting the results at the end of the day.
The colleague was comparing the productivity of his hack day team with that of our project team and wondering what lessons could be taken from the former to increase the speed of the latter.
My gut reaction was that comparing a hack day to a day in a project team was like comparing apples and oranges, but after compiling a list of the differences (see below), I’m not sure how different the two “need” to be if you choose to optimise a single team’s productivity over a short period.
A hack day…
whereas a project team…
|isolates teams from any outside interruptions||lives inside a corporate environment, with meetings, social events, random conversations|
|focusses people because the time is very tightly time boxed||usually has another day, another iteration, another release|
|team will choose to work on something that is highly interesting to them||works on what is highly valuable to the business – any benefit the team derives is a side effect|
|works in a pure XP mode with an embedded customer and no external stakeholders||may have an onsite customer but will almost always have external stakeholders to manage|
|wont produce code to production level but rather as a working proof-of-concept with correspondingly less discipline||needs all the code to be production quality (i.e., highly tested, well designed, etc)|
|team can arbitrarily choose to not do implement features that are technically difficult irrespective of value||will usually need to deliver high value functionality, even if it’s time consuming and complex|
|team can deploy their creation themselves into a lightweight environment paying no heed to any levels of governance around the deployment environment||will need to deploy into a managed shared environment, adherencing to non functional requirements|
Now not all of these differences need to apply to project teams in all situations. For example, in extremely time critical situations, there are usually ways to extract teams from the distractions corporate environments presents.
However there are still a number of significant differences between these two working environments that can leave an impression that the perceived velocity of a hack day is far in excess of that of a project team. If I was forced to identify the biggest hurdles to productivity between the two I would look to the absence of external stakeholders and the high level of alignment between the interest of the team and the problem domain. The former can be addressed in corporate environment through careful recruiting and judicious team composition.
The latter (managing external stakeholders) is a far harder risk to mitigate.