Our whole R&D team, around 80 people, were actioned for an all-hands-on-deck “operations” meeting, lasting 4 hours.  This is a mind-numbing meeting where each development team member would have a representative stand up and recite a 4-quadrant charts, “red” “yellow” or “green” status, issues, gantt chart changes, in poke-me-in-the-eyeballs-with-a-needles  boring details.

The tension:  This was a three-fold aspect of tension:

• Everyone had to be pulled away from their work..nobody likes this.
• Everyone was subjected to a conjectured, almost fabricated view of how good they are doing, to upper management for a critique….and usually of presentation style vs content.
• In mind-numbing, boring detail.

I slipped out, noticed a bag of popcorn and a microwave. Hit 5 minutes instead of 2. Ran back into the room, and told a colleague “if you smell smoke in 5 minutes, run out and pull the fire alarm.”

Post-fire, I emailed the company fire-marshall on the risk of holding company meetings where “everyone in R&D” attended. Could we not just send representatives in case of fire as we saw last week?

The short term results of the hack:

• The whole team was no longer pulled away from work…
• The project managers represented the teams…(while this is a good thing in that the PM is no longer bugging the team during that review day, it is a bad thing we need PM’s at all.)
• The lie of good progress still persisted….

The next hack I’d like to plan is one that promotes viewing the working software in a culture where status reports are preferred.

Suggestions on that are welcome!!

This hack was submitted anonymously

Culture & Crack: It’s often hard to convince a buying department of a large firm that an agile approach to build a piece of software is less risky and the result may fit much better the needs of the users. I’ve been in a situation where the conflict between the entrepreneurial and agile mindset of the product manager who was asking for an internal tool to be build by an off-shore subcontractor and the strict purchasing rules of a fixed price project could not be resolved – at least not within a reasonable time frame and effort.

The Hack: Instead of trying to convince people of the buying department about the benefits of agile contracts we decided to create a fake fix price contract with made up milestones that we draw from an initial version of a product backlog just to please buying department rules. On a personal level the subcontractor, provider of off-shore development and the product manager agreed on an iterative approach including free changes after each iteration within the budget boundaries given by the contract.

The Result: Both parties knowing that the contract wouldn’t help a lot in case of failure with the project actually helped to create a bond within the team. The safety a contract would normally provide actually was found in the agile approach chosen, co-dependence of product manager and team as well as trust that has been created by colaborating on the product backlog with the whole team involved at the off-shore development site. After several increments shipped and changes to the product backlog the first version was delivered into production two sprints before last milestone given in the contract. The saved two sprints were then used for later maintenance and smaller improvements after the software was used in production for a while.

I would consider the hack close to red zone. All depends on agility of the team and luck. So I would think twice if it’s worth the risk before working on a bigger project that doesn’t have a valid contract and always prefer agile contracting clauses like change for free.