Continuous Improvement – Helping Agile Teams make NEW Mistakes

February 6, 2014 Paul Peissner

Mistakes in pursuit of curve-jumping innovation are an unavoidable part of the agile process and investment. Some organizations are afraid to allow Dev teams to make mistakes (or experiment with change) and they build engineering cultures that discourage risk-taking or the trying of new things. These cultures ultimately limit opportunities to build competitive business advantages and put their business at unnecessary risk in changing markets. Consequently, mistakes are a necessary component of innovation. That being said, the best Dev teams only make new mistakes.

What do I mean by “new” mistakes? Developers in challenging situations come up with a “new” idea. The idea appears “new to them” because…well it is new for them.  However, there is a pretty good chance that some “variation” of this “new idea” already exists and that there may be a thing or two that has been learned along the way…which might be beneficial to consider.

Innovative and visionary developers should assume that “new” ideas have been tried before. Therefore, they should invest a quick moment to search for existing engineering insights, ready-to-use assets and/or feedback data that might accelerate the effort or improve the quality of their craftsmanship. When Dev teams stop repeating mistakes and only make “new” mistakes, organizations experience faster failures AND faster successes – leading to greater innovation and competitive advantages. It may sound like a contradiction but actually it isn’t.

Encouraging developers to make “new mistakes” (and capturing the valuable learning data) leads to:
1) Acceleration of uniquely brilliant innovations for your business,
2) Reduction of time / efforts in subsequent development projects
3) Improvement of current and future product quality, and
4) Enhancement of engineering craftsmanship (especially for agile teams working in smaller and faster moving isolated local groups, and it’s incredibly helpful for future developers joining these fast moving teams).

To achieve these goals, organizations need to adopt agile best practices and craft (or invest) in an engineering friendly system of Continuous Improvement that helps agile development teams make corporate benefiting NEW mistakes, once. Collaborative environments and systems that capture engineering successes and failures help fast moving (and constantly changing) local agile teams support the organization’s desire for faster innovation in their changing markets.

Are you interested in discussing what a corporate system for collaborative development might look like for your distributed organization? Would you be interested in hearing about enterprise organization stories that have seen 80%+ Reductions in project related costs, 70%+ Improvements in Time-to-Market efforts, 65%+ Increases in Dev productivity, and dramatic improvements in meeting security, compliance, and governance obligations. The teams and partners I work with would welcome the opportunity to talk about what an ideal Continuous Improvement software development system might look like for your:
1) Organizational needs,
2) Industry governance or compliance obligations,
3) Engineering practices (Agile, Waterfall, Scrumfall, etc.),
4) IP identification, security and protection strategy, and
5) Future visions of process efficiency (e.g. Continuous Integration, Continuous Delivery, Deployment Automation, DevOps, etc.).

Let me know if this is something you would like to explore further.
Paul Peissner, Agile & DevOps Enthusiast

Previous Article
Migrating Subversion Repositories to Git – The definitive Guide for TeamForge Users
Migrating Subversion Repositories to Git – The definitive Guide for TeamForge Users

  Many software projects are moving from a centralized version control system (CVCS) to a distributed versi...

Next Article
New Winter 2014 14.0.2 Point Release Available
New Winter 2014 14.0.2 Point Release Available

On this day in 1990, McDonald’s opened their first restaurant in what was then still known as The Soviet Un...