HOW DO WE WORK?
On 1 November 2019 a certified and experienced scrum master, Diderik van Wingerden, joined the 121 team. A few weeks later on November 23rd 2019, the technical project manager of the 121 team, Lars Stevens, passed his Professional Product Owner 1 exam. The result?
- Clear “Process” for a newly formed scrum-team
- A clear focal point for our consortium members
- Structured meetings with clear actions & deliverables
WHAT IS SCRUM?
The 121 team uses a Scrum (Agile software development) approach. Scrum is a simple framework for effective team collaboration on complex products, but it is difficult to master. In a basic, self-organizing, scrum team there are three types of roles:
- Development team: actually build the product in small increments and is cross-functional which includes Front/Backend developers and HCD/UX/UI designers from both within 121/510 and 121 technical partners such as Tykn & Disberse.
- Scrum Master: a servant leader responsible for promoting and supporting the Scrum framework inside and outside of the team
- Product Owner: maximises the value of the product built by the development team
Scrum rests on the Agile software development manifesto which describes a philosophy of “dealing with the empirical process of developing solutions for complex adaptive problems”. The following values are central in that approach (the items on the left in bold are valued more than the items on the right):
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
WHY DO WE DO IT?
We were looking for a new software architect and one of the applicants turned out to be not only a seasoned software architect but also an experienced scrum master.
As soon as he started to support our team in the use of the Scrum framework, we realized we could be far more efficient by realigning roles. Previously, we had no scrum master and the role of product owner was shared between three individuals: project manager, software architect and the UX UI designer. Shared responsibilities are notoriously difficult to manage, which is why Scrum promotes to have one product owner for one product. So we dedicated one person for the job.
It soon became apparent that this was a very good step!
As a product owner is:
- Accountable for the product
- Manages and prioritizes all the work on the Product Backlog
- Ensures that the Product Backlog items are clearly expressed
- The voice of the end-users towards the development team (together with the UX UI designer who conducts user-research, co-designs and user tests with all stakeholders)
- Guard the product vision
HOW DO WE DO IT?
Our Scrum Master supports the Product Owner in more effectively managing the Product Backlog and facilitating critical meetings, also called Scrum Events. These pre-set meetings aim to minimize unnecessary meetings and are all time-boxed. To enhance the understanding of the role of Product Owner a self-study and exam from Scrum.org was done and then put in practice. The Product Owner then started visiting other organizations with experienced product owners and Agile processes to better understand the practice.
So based on directions of the Scrum Master, theory and practice, the Product Owner could take back some work that was better suited to their role and ensure the continued work was even more effective.
WHAT DID WE LEARN?
Our biggest lesson learned is that although Scrum is a proven method and simple to learn, it is hard to master. To get it working as a process, you need to both bring in experience and train people.
Exactly because Scrum is quite simple, it can be a very good starting point but there are a few learnings.
- Avoid cherry-picking elements of the framework that are convenient
- Do not create a Scrum Team with only developers, dedicate a Product Owner and Scrum Master
- When there is a product backlog, somebody (in Scrum the Product Owner) must have the clear responsibility to manage and prioritize it
- Only commit to working in a sprint when it is refined and everyone understands the work to be done
- Check for hidden waterfall planning within each sprint
- Do your retrospective meeting each sprint, this is where discussions take place about the process and improvements are identified
- Commit to a sprint as a team, not as an individual
Implementing and creating a true Scrum team has already shown significant improvements. We continue learning and continue improving! Plus the team is happy to share our lessons learned both inside and outside of our organization. So if you have any questions or want to know more about our project, please contact email@example.com