Playing the Software Development Game

Alistair Cockburn promotes the model of  cooperative games  for software development: Viewing software development as a  “series of resource-limited, cooperative games of invention and communication”  meets the objectives for an underlying model of our field: It lets us make sense of historical successes and failures. It names at the top priority level a set of topics that are known to be important to project success but do not normally have a place to live in discussions of software development, topics such as community, amicability, morale, talent, trust, proximity, and sufficiency. It offers immediately usable advice to people busy on live projects. Here's a drawing Alistair uses to illustrate his point: With business stakeholders we should be playing a  cooperative, finite goal-directed  game in which each member of the team understand his or her roles, responsibilities and strengths, the desired outcome is clear, the outcome's temporal horizon is relatively

Among the many great topics in his book  The Principles of Product Development Flow , Donald Reinertsen talks about controlling flow under uncertainty and the danger of congestion.  While WIP constraints help manage the flow of value from a system, by themselves they do not ensure that the system is at a high-throughput operating point. These diagrams show the corresponding effects of hitting full capacity on throughput and delay: Knee - point after which throughput increases slowly delay increases quickly Cliff - point after which throughput decreases quickly to zero (congestion collapse) delay goes to infinity Simply put: when we cram too many projects in the product development pipeline, we create queues.  These queues create a frictional drag on throughput as developers spend more time expediting and less time adding value.  The added load reduces output instead of increasing it.  When the project load hits a critical point, we will see a sudden and catastrophic

Don't worry, this is not just another political rant for or against government involvement in the national healthcare system.  However, since the issues surrounding the launch of the US  HealthCare.gov  site have gotten a lot of attention there are some really good conversations around IT and business project success that are worth reviewing. The NY Times on Sunday published  From The Start, Signs of Trouble at Health Portal , citing the largest contractor on the project who noted that, although they were awarded the contract for in December 2011, actually coding didn't start until Spring 2013, and until late September, days prior to launch, some significant features and user requirements were still being debated. James Turner wrote at Forbes.com that  You Can't Legislate Away The Time, Money and Features Law , and in a few brief paragraphs captures many of the typical failures that occur in a complex project like the healthcare portal, not the least of which is full i

A group of software developers put themselves in a room Friday afternoon committed to delivering an application to help Sara Hutchinson and others who administer Backcountry's Gold Points reward system. Ryan Debenham, Ryan Walls, Rusty Robinson, and Peter Gram applied their considerable skills, knowledge and a set of web app development tools to the task of creating quality software in a tight timebox, starting at 1:00 p.m. with the goal of finishing by 6:00 that evening. At the end of the day, the team had produced software that created value for the small group of people who administer the Gold Points site, and by extension for all the people who benefit from the Gold Points system.  In the process, they validated some important principles that make Agile teams more productive and effective (things like focus, team effort, business user engagement, and more--skip to the end to see a summary). Backcountry is proud of its Gold Point reward system.  Employees receive Gold Poin

With all the yammering from politicians about the debt ceiling this seems like a good time to talk about technical debt. Technical debt  is a  metaphor .  Just as each of us incurs financial debt in life (sometimes recklessly, other times prudently), software gets released to production with some corners cut. The idea that no shortcuts will ever be taken is impractical.  Scrum teams own their solution decisions, including feature coverage and code quality.  Rather than semantic or dogmatic arguments, teams use tools, apply standards and work together (including acceptance criteria, pair programming and code reviews) to release the best quality at the right point in time.  Here's a  matrix  to help frame a view of technical debt: We make deliberate, prudent decisions to ship software because we know it will provide value to the business and we want to deliver value as soon as possible. We introduce technical debt inadvertently because sometimes we just don