Today we really properly finished the rewrite of a number of features related to an external client project. I’d like to post a case study with before / after examples shortly, but need to work out how to protect the innocent first…watch this space.
We made some deliberate compromises in the way we’ve restructured:
* Valuing e2e view and line of sight to the customer over feature size. i.e. not breaking out into smaller tasks to target a specific technology component, an individual SME or similar; even if we think we could get it going faster across different teams in parallel.
– So that we retain an understanding of what’s important to our customers and encourage pairing / cross-skilling
* Valuing correct features at the program level, over some tough decisions about task ordering at the team level – i.e. the program features are whole-of-team, but epics and stories that make up that feature (which the teams work out themselves) may not have the full slice, e.g. Lab builds vs Production builds split. We think it’s better to get it right at the feature level first and worry about team practices later.
– So that we encourage teams to work together towards a common goal
* Capturing intent of the whole over clarity of our piece in the puzzle – this work is part of a broader program, for which we’ll deliver an infrastructure component, but additional work in the application layers is required to deliver value to the end customer. In restructuring our features we’ve chosen to capture that broader business value in the way we phrase the feature, but to limit what’s expected in the build via the acceptance criteria.
– So that our teams understand what’s important to our customers and are encouraged to collaborate and break down the barriers into our parallel constructor teams, rather than putting the blinkers on from the get-go.