How a constraint can move within a software development system
Below is a link to a good article from the folks at Net Objectives regarding Agile and Theory of Constraints that I came across this morning. It talks about what I have seen recently on a project on how the constraint can quickly move to another part of the software development system.
http://www.netobjectives.com/blogs/comment-on-TOC
In the example I give below the constraint has moved from developers to BAs as we have optimized our coding teams. It’s important to recognize how we optimized the development effort and specifically how this has moved the constraint onto the BAs. The bottom line is this:
On our project, by optimizing our coding efforts we are getting to the hard details, the details that are not captured in the client’s requirements document, much faster than we were before.
How have we gone about doing this?
1. We are actively reducing the number of story cards in play
A developer should not have more than one card in play. We tend to let a developer take on another card because they are blocked, often because of requirements questions. By only letting a developer have one card in play at a time it will force the developer to deal with the hard stuff right away and not put it off until later. This requires an immediate conversation with the BA to work out the details.
2. We are forcing the focus of our development efforts back onto story cards rather than tasks
We want to keep the development cycles on story cards as short as possible. To do this we are centering our daily standup around story cards rather than each developer’s status. This helps us identify when a story is taking longer than expected. What we are finding is that a story is taking longer because of requirements issues which requires a BA to resolve.
3. We are optimizing the whole development team through greater collaboration between UI and Services Teams
Once again, the optimization of the whole development team allows us to get to the hard details sooner, specifically, the details of the interfaces between UI and Services. These details only get identified and sorted out through coding both sides of the api at the same time, not documenting them. And we are not just talking about api signatures, but the edge cases that are frequently not identified in a requirements document that require conversations with a BA to resolve.
As you can see, all this requires that a BA be available to developers to keep them from becoming idle or inefficient. This becomes a point of contention for the BA’s time if they are given a mandate to complete a set of documentation well ahead of the developers need for the documentation. Management needs to align their expectations of BAs to provide Just In Time requirements.
