Scrum = Happy workplace!
This is indeed true, but who and what makes the workplace happy will vary depending on the variety of practices a Scrum team adopts and adapts to during the product life cycle. Being a passionate product owner and working with passionate minds, our Scrum team tries to bring their best to our products. I want to elaborate on two specific practices: discovery
and team time
, which are helping our teams live with the product better.
Acquire the proper mindset through product discovery
We usually develop the product vision and also the mindset required when the product cycle begins. Kickoff is not formal until we are done researching the must-have user wish list, user base, design, and expected delivery date. The delivery date is crucial, because we always want to beat that. Although the product idea is born out of user need, creating a perfect infrastructure to convert the concept to reality falls on our shoulders, and that is what we call discovery.
This phase is the foundation of our craftsmanship, and if we get this right, half of the work is done! So as a team (product owner, architect, development team member, UI designer), we embark on this phase as a blank slate and let the user draw the picture for the first week. This discussion leads to creating the user interface, logic, and the super-critical versus the OK-to-live-without user needs.
After the timeboxed discovery sessions with users, the Scrum team goes to the board with no specific rules, and members hear each other out. This is also a timeboxed meeting, which lasts an hour, to confirm the team's understanding of the user's needs, share ideas for execution, and determine the next steps required to begin work. Depending on the product need, the discovery session may run from one week to three, daily or on alternating days. The idea is that the entire Scrum team knows about the product. Every team player has tasks to do after every session during this phase, and this is discussed and shared with the team.
Here is the breakdown of a two-week discovery phase for a complex tool developed in 12 weeks:
Duration: three weeks
Participants: users, team (PO, architect, UI, development team)
- Session with users across the globe: two hours on alternate days for two weeks.
- Quiet time for an hour.
- Team time for an hour to confirm and discuss the next steps (such as who will design the UI); for the development team to set the development work and think about the source, performance, jobs, etc.; and for POs to start building the backlog.
- At every session, the product needs and tasks become clearer, and by the end of the phase, the PO will have a backlog that is prioritized, as was previously discussed with the team and estimated at a high level.
- Between the end of the discovery phase and the beginning of Sprint 1 and Scrum, the team publishes the backlog and the high-level estimations and stories that will be in the first few sprints. Team norming was completed in discovery; the team has thought about the product complexities; and the Definition of Done list, the readiness checklist, the engineering practices, and the formal kickoff to mark the sprint are all done.
Sprinting with team time
With the groundwork done, the team has great ideas to implement within Scrum. Every sprint, the Scrum processes is followed. We begin the day with the daily stand-up.
We encourage engineering practices such as pair programming refactoring. After half a day, we meet again for team time, which is a mandatory 20-minute meeting during the initial sprints, when any dependencies or any impediment for which the team members need each other’s help are quickly discussed. This is actually a breather for the team and does not interfere with the daily stand-up. It has proved very helpful, especially when teams have multiple vendors who may be new to Agile and are distributed across geographies. For example, the UI design can be the latest and best, but if there are any technical challenges in implementing the design with the current platform, teams can discuss them with the users during team time, secure the flexibility in design, and get back to work.
This time can also be leveraged to showcase progress or propose some ideas to users who will make the product better, while keeping the team informed and on track as to the effort made to develop a better product. As participants in this meeting, users literally live through the complexity of the product delivery. The last minute is a teaser in that we cheer for the team member who brought the hot items to our team time and ensured that impediments were cleared. Empowerment is ensured!
Sprint planning/backlog grooming and sprint review
This is the remaining part of our sprint life and ensures that we are developing the right product.
A biweekly retrospective is encouraged. We scrap the unnecessary team time to accommodate the retrospective. We ensure that the retrospective theme is always different and fun, which generates incremental improvements every week. We often view the latest Hollywood movie and use it as our retrospective theme for different teams, which proves to be a good ice-breaker.
Every product, team, and organizational culture is different; these practices can be tried and tested if the team wishes. It does work! For us, once the product is delivered, we have a team that celebrates the joy of the successful product journey.