Some time ago I wrote a post here about Patterns we can identify in projects and how they relate to the life-cycle model in use for the project. Some patterns are definitely signs of an Agile project (release working software at the end of every *very* short iteration for example). Other patterns are clear signs …
We all have seen it in our projects. Some teams are overloaded and can’t deliver what we need while others are not so busy and could even tackle more work if there was a need for that. This type of partial overloading is easily understood if we picture the work flow as a network of …
Instead of fighting about “who’s agile” or “who’s more agile than whom”, it would be useful to create a set of patterns, that once recognized would help us define if we are or have been able to successfully implement an Agile life-cycle for our project and portfolio. These patterns or symptoms are useful for us …
Just after writing the post about about Never ending design discussions I found one post from Lasse about story points. I think these two posts go very well together, as story point-based estimations is what I use for the Timeboxed estimation pattern.
In this post, Jason explains one common problem with the estimation and planning sessions in Agile teams. The problem he describes however, is quite common and has lead to implementation of the Separate Design and Requirements anti-pattern in the traditional software development world.So I thought I’d write a pattern about a simple and common solution …
Below I try to describe a pattern that I’ve faced and have seen in other teams in the context of an Agile transition.See the explanation section for more details on each of the sections in the pattern.If you have faced similar situations let us know of your own story in the comments below. Proxy Product …
