At the TDD workshop at ICST in Paris on April 10, Catherine Louis and I will invite collaborators to launch a study on A-TDD in large scale, complex product development. There is very limited research on Acceptance Test-Driven Development in Large Scale product development. By collaborating together we hope to:
Find new and Innovative ways to introduce A-TDD into Large Scale Complex Product Development
Maximize your chances of Success with A-TDD introduction in your development practices.
Explore the frontier of Change adoption
Collaborating on a framework for introducing Acceptance Test-Driven Development in large, complex product development
Iterating and improving on that framework
Publishing the resulting research, identifying all critical success factors.
You can find additional information by downloading our invitation here. If you are interested in collaborating or would like more information, please contact us:
On the flight from Toronto to Seoul I had a chance to read a Harvard Business Review back issue from December 2009. In it was a great article titled: The Innovator’s DNA. The article talked about the characteristics of great innovators – how they think. It boiled down to five key skills.
While in Paris, I had the opportunity to attend a talk by Scott Ambler, a fellow Canadian, on “Scaling Scrum – Lessons from the Trenches”.
Scott’s view is that Scrum by itself is not a complete solution for product development, which of course is true (duh!). The front end and back end of the business process also need to be involved and there needs to be some governance structure in place among other things to make sure a large distributed and complex development activity can be executed using Scrum and other Agile methods.
Feature teams as opposed to component teams allow you to organize in a way that maximizes architectural integrity and business value demonstration at the User Story level, and ultimately, at the feature level. Check out Catherine Louis’ slides on how to organize around a complex, multi-network element feature in the telecom domain. Really great work. You can find them here.
The Theory of Constraints (TOC) is all about flow, and identifying and removing bottlenecks in the flow. Think of the analogy “the chain is only as strong as its weakest link”. The weak link is the bottleneck in the flow from from quote to cash.
A simple example is to look at manufacturing where scarce machinery or skills creates a backlog of work directly in front of it. Inventory piles up as teams in different departments build excess stock in the production chain which the bottleneck resource cannot keep up with. Software is no different. In our world, we see it all the time. Scarce skills, people with specialized expertise cause those who need their services to queue up in front of them.
Root cause analysis is at the heart of TOC – something that we in the software industry understand very well. TOC applies 5 focusing steps to identify constraints and their root causes in the context of a continuous improvement exercise. These 5 steps are:
Identify the constraint
Decide how to exploit the constraint
Subordinate and synchronize everything else to the above decisions
…organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.
Think about your product and it’s strengths and weaknesses. Can these strengths and weaknesses be mapped to the strengths and weaknesses of the communication paths in your organization? Component-based teams and human relationships are at the core of this idea. Continue reading →