Valuing Simplicity

I am a strong believer of breaking giant problems into smaller ones, to understand what the problem really is, and then solve it. As a Scrum Master, I encourage my teams to value simplicity with products and processes.

Valuing simplicity with products

In any Agile environment, it is important for Product owners to figure out what their minimum viable product is. I talked a little bit about this in my post on Story estimation. 

Simple MVP

If POs think about their products enough, they can help define a simple and clear minimum viable product. This can enable teams to build good quality products that reach customers quickly.

Simple UX

Simplicity should also be valued with user experience. If you are overhauling an old system this can mean providing an experience that matches an old system, or creating new easy to understand action flows throughout the new system. Listening to end users is key to creating simple designs. 

The word 'simple' in this case, refers to easy-to-use systems, and not necessarily easy-to-build systems. There is be a balance with that problem, that teams and POs need to find.

Simple design and architecture

I encourage my teams to value simplicity in design and code while building products. I have experienced first hand that simple designs with decent documentation end up being easy to understand and maintain. Although we knew this already, as a developer, me and my team have been involved in building an extremely complicated architecture in order to solve a reasonably simple problem. 

To help encourage teams to build simple systems, I remind them that real technical skill involves building complicated products with a simple design. Anyone can complicate matters, building simple systems takes real skill!

Valuing simplicity with processes

In my post about What, When and How, I talked a little bit about trying to coach teams by asking them to think in terms of those 3 simple questions. There are several other things that Scrum Masters can do to help create a simple process. Here are a few examples:

Single Prioritized Backlog

Having a single prioritized backlog - with both defects and stories prioritized together, helps simplify the Scrum process. If the backlog is well-groomed, folks on the team have a single place to go to for -

• Gaining insight into product road-map -- near term and long term.
• Picking up additional work in a sprint if needed.

Scrum Masters can definitely help in backlog grooming process, but I have found that it is really helpful if the product owner maintains the backlog. This helps give them great insight into the product and the team's progress.

Metrics

In my post about Scrum - metrics, I talked a little bit about the metrics a Scrum Master should maintain. In my experience, if you implement a basic version of Scrum, the basic metrics like - sprint velocity and sprint burn down are really easy to figure out and track. If your team uses electronic tools and boards, the metrics are usually under sprint reports. However, even if your team is not using electronic tools, these metrics - sprint velocity and burn down are simple to generate. 

Easy to follow processes

I try to make the life of my team members easy by having simple process. They should ideally have a single place to go to for picking up new work. They should ideally have to follow same sets of procedures to move tickets from "to-do" to "in-progress" to "done". They should also have a single straight forward way of seeing metrics that the team is tracking.

I have been in situations where this wasn't possible and I worked hard to change it. On a few projects, we had to apply specific labels on issues for them to show up on our electronic board. We also had to follow separate procedures for moving tickets on the electronic board, depending on whether it was a user story or a defect. With these challenges, I found that folks on the team found it really hard to remember how to close tickets, making their life unnecessarily complicated.

Rate this post!

☆

☆

☆

☆

☆