About to head in to Discovery
Hi, about to head in to another Discovery for a new service.
Couple of thing have cropped up from the small team we have put together for the start. Daily Scrum the PO doesn't want to have them during Discovery, I do.. I see value in them. He sees that the team of 3-4 are all sat very close together and can constantly converse. I'd like to think this happens anyway?
Techniques, In the past I'm sure i've heard of A0 or A1 sessions (maybe wrong phrase) which is flipchart paper and getting down every at a high level before arranging them in to some kind of order. The order of items do we want to be looking at the earliest possible date to deliver an element or the latest? To my mind the earlier it is in place appears slightly counter intuitive as when it comes time we may not actually need and therefore spent time creating something of Zero value..
Look forward to any thoughts.
What is meant by “Discovery” in this case, and how does it help a team implement Scrum?
I realise the Guide doesn't mention Discovery as 'Phase', section or title but in this case we use it as information gathering.
Who are users? What are their needs? How are we currently meeting them? How are we not?
User research, can we actually build a service that meets the needs? We are not looking to design a service or prototype.
This in turn will lead to creating Epics and User Stories and a decision based on the Minimum Viable Product.
If at the end of the process we realise we cannot fulfil or develop the service we stop. This isn't a sign of failure if anything it is a success as we proved there is no need...
So that is the context of the Discovery I am talking about.
Why not start sprinting instead, and thus validate the information being gathered by means of empiricism?
Sounds like you are in one of the early phases of a traditional design process for new products, using Scrum to create the backlog for development, essentially Scrumming the Requirements phase of a project. I recently worked with a team trying to use Scrum in a "discovery phase". Such work can be made to flow through a Scrum process, by focusing individual work items on outcomes, (e.g., user stories) including value delivered as well as valuable new knowledge learned (spikes). However, it may not be the best tool to use in such an environment, it can be as frustrating as trying to hammer nails underwater. Scrum is intentionally disruptive, promoting radical change. It is most viable where the team and its environment are focused on outcomes, highly motivated to improve them, and are willing to use empirical/scientific/economic methods to continually change how they collaborate to get the best possible outcomes. Teams that are just starting out, or who aren't unanimous in their support of Scrum, may want to consider a simpler tool that is more compatible with their overall approach, such as Kanban. Trying to impose Scrum on a team will fail.
Some red flags:
* It sounds like you and/or the PO are trying to control how the work is done, or at least by whom. In Scrum, the team owns how they do their work, POs guide them economically to address the most valuable work, SMs help them to become high-performing. Neither tells them what to do or how; teams cannot self-organize in those circumstances, they won't become high-performing.
* It sounds like your PO is trying to do predictive scheduling, rather than the empirical means Scrum is designed for. Agile/Scrum focuses on delivering the highest value work as fast as possible to get the feedback that drives development. He' be more effective with a framework that works the way he prefers, rather than try to shoehorn Scrum into traditional, plan-driven development, where it cannot thrive.
Some questions:
* Are you the SM in this scenario?
* What are your motivations for using Scrum?