What, How, When?

As a Scrum Master, it is important for me to help my team understand the process that they are engaging in to build software. 

The challenge with coaching is that many developers I have worked with aren't as excited with Scrum / Agile as I am. I have received feedback from folks to the tune of - we like solving technical challenges, and aren't particularly interested in the paperwork.

I believe it can be counter-productive if a team is trying to adopt Scrum / Agile, and doesn't know the basics of it. In order to help teams understand Scrum, I believe it is important to try to keep it simple.

I encourage everyone on my team to think about 3 questions - What, How and When, when they are thinking about the software development process.

Let's talk about each of the questions one by one:

What?

The question "what?" usually deals the product we are building. Folks on the team sometimes come to me (in my Scrum Master capacity) to get answers to the question - what. In order to empower the Product Owner role, and to have the team learn and respect boundaries, I usually redirect any 'what' questions to the PO.

This entails that the product owner decides what we are building, and although the team can have input, the product owner takes the final call. The team needs to learn the respect that boundary; and in return, I ask the PO to respect that the team builds the product, and how they do it is best left up to them.

The output of the question "what?" in terms of the process is usually the user stories that are written. Scrum is a process of converting 'ready' stories into 'done' product(s). The term 'definition-of-done' is fairly popular and well understood, but if your team is having trouble with the stories that are being written, it might be a good idea to try to get a to a 'definition-of-ready' that you can articulate.

How?

The question "how?" deals with the implementation of the software. This is best left to the Scrum team. As a Scrum Master, if I see chickens trying to dictate the 'how?', I do my best to ask folks to respect the roles in the process. 

The practices like code reviews, pair programming, test driven development, writing and executing unit tests, automation test etc. are part of the question - how. The implementation of these should be up to the team. As a Scrum Master, I encourage my team(s) to do all of the above, but I have worked with teams where we didn't do any of it and still managed to get decent working software out. 

The output of the question "how?" in terms of the process is usually working software produced at the end of the sprint. It is important to have a reasonable definition-of-done, so as to facilitate the question - when.

I have talked about sizing based on what? and not how? in my post about Story estimation. 

When?

The question "when?" deals with the schedule of release(s). I am a proponent building of small features and having feature driven releases. I believe it is a good idea to get features in the hands of the users as soon as they are available. 

The output of the question "when?" in terms of the process is usually the product launch / update date. If your team produces working software at the end of every sprint, you may consider not having any release plan(s) for a release or two. This may obviate the need for sizing / estimation. I haven't been successful at product deliveries at the end of each sprint, but we have been successful at releases at the end of 2-3 sprints. If you have a regular cadence, whether you want to specifically answer the question 'when' is up to you. 

Rate this post!

☆

☆

☆

☆

☆