How many corporate offsites have you been to that mandated some kind of ‘start with the why’ activity? You know the thing, fumbling around with post-it notes trying to articulate why you like coming to work, looking for personal intrinsic motivators within a business setting ๐ฑ. Simon Sinek has a lot to answer for imho.
Meanwhile, I see so many teams, not just agile ones, really having so little understanding of the ‘how’ of SDLC. Teams are keenly doing research and product design, writing requirements or stories or BRDs or BDUF, drawing Figma flows and colouring in icons, writing copy etc. As if these paper-based, feel-good activities will somehow cure the ills of not actually understanding how to develop software in a fit and proper state.
Eventually, these teams run out of time ‘ideating’ and launch into ‘delivery’ ill-equipped and without the basic ‘how’ guardrails in place. These guardrails include behaviours like refinement, actually having some way to plan timeboxed development, the definition of what good looks like, who answers outstanding queries, etc., and also technical guardrails like automated tests, CI/CD, branching strategy, etc.
If only some of that upfront ‘what’ enthusiasm had actually been invested in putting the fundamental ‘how’ guardrails in place, then future issues with the upstream ‘what’ would be caught, and hopefully addressed, in the right place and at the right time. Instead, it all becomes another disappointing corporate cluster fruit ๐ resulting in more ‘agile hating’.
|
Frank Ray Consulting. Software requirements for agile development teams, particularly remote, outsourced and offshore development teams working in financial services. |