I read Jon Aizlewood's blog post 'When Agile's not creative' with great interest (I'm working on the same project). What he raises are common problems and I have some suggestions on how to solve those.
Discovery shouldn't just be at the start of a project
There's a misconception that 'Discovery' only happens at the start of a project. This may be compounded by the fact that in our projects we call the first Sprint 'Discovery' rather than Sprint 0 or even just treat it the same as any other Sprint. As such, that might add to the idea that we can only do 'discovery' tasks in the 'Discovery' Sprint. Not true.
Teams should absolutely be allowing for further discovery to happen during later Sprints and the possibility of refactoring, either in design or development, or both. That process of iteration can happen for a number of reasons - as a result of new information which has come to light through user research, or as the design system is developed throughout the project.
If you are working in a project where 'Discovery' only happens at the start of a project, then I'd argue that's not Agile. The creative process is not linear, and the iterative nature of Agile can accommodate that non-linear approach very nicely.
In the specific case Jon mentioned, we're talking about developing the design system for the project. In Sprint 1, Jon developed the design direction as a first pass so that in theory, we could start the implementation of this on real user stories. If we did Sprint 2 planning again, I would have offered two choices:
- Continue to develop the design direction until it's ready to be used in implementation, before starting on any specific user stories. If an essential task isn't finished at the end of the 'Discovery' Sprint, you just continue with that work in Sprint 2. I'd suggest that continued until Jon feels that they have 'just enough' design direction to start on implementation rather than completing it in full.
- Or, start implementation on specific user stories but ensure that the Sprint backlog also contains a task to refactor designs or amend the design system, and it's taken into account in future Sprints.
Design refactoring
Jon refers to allowing time to 'ensuring that the separate, sometimes ad hoc flows and design comps you’re creating actually work together in the wide angle lens of the design system.' Yes siree, yes and yes. I would question is whether this is strictly a 'day' but just an activity we factor into Sprints, the duration of which is determined by the level of effort required for that Sprint, and value. So in short, refactor when it's necessary, rather than because it feels like a mandatory part of the process.
As a note of caution, 'refactoring' can appear to be a bit of a blackbox so applying the rules of prioritisation to any this work would be a good way for everyone to agree what and why changes are being made.
Retrospective
Worth mentioning that this kind of discussion is perfect material for the Sprint retrospective!
