Teams

Building motivated teams that produce predictable results is a very hard problem to solve. Here are some thoughts on how you can start making that happen in a Scrum environment.

Role in Scrum:

'Team' is a role in Scrum along with Scrum Master and Product Owner. The way I see it, it is not an accident that the entire team is considered as a single role. Individual developers, testers etc aren’t roles in Scrum, the entire team is. I believe this is an emphasis that the team needs to act as a single unit.

I have been on several projects where new Scrum teams were created for each new project. As a Scrum Master, I believe it is my responsibility to push back on this type of behavior within the organization. One of the benefits of having a multi-function Scrum team is that it can handle most projects when given appropriate support. If teams are changed for each project, you lose the data collected for the team - e.g. velocity. A single team kept together for a period of time will give you more predictable results than new teams formed for each project.

Self-Organizing Nature:

Scrum emphasizes that teams need to be self-organizing. This is very different from a traditional top-down management point of view, and it is easy to imagine that some leaders may not fully appreciate the advantages of self-organizing nature of teams. I believe one of the key advantages of having self-organizing teams is that they have a higher likelihood of meeting or exceeding their commitments.

As a Scrum Master I believe one of the starting points in creating self-organizing teams is to give them a single backlog to pull work from. Having a single backlog is the first step in being transparent about your minimum viable product. This helps the team get a clear direction, which helps to self-organize.

I also believe Scrum teams work best when they decide to pull work in - either in sprint planning or as stretch goals for a sprint. In my opinion, it is difficult for team to self organize when when work is pushed on to them.

Stages:

Teams go through several stages as a group of individuals come together and work with each other.

1. They usually start off with what is called ‘forming’ stage, where they get to know each other as they start working together.
2. The next stage is usually learning to adjust with each other. Everyone works a little differently there are obvious tensions and pressures during this stage. It is aptly called ‘storming’.
3. As folks settle in and understand how each individual works, they can slowly start getting comfortable with each other. This stage is called ‘norming’.
4. If a team stays together for a considerable period of time, people can start learning the strengths and weaknesses of each other. They can then start balancing responsibilities more efficiently. This stage is called ‘performing’.

As a Scrum Master, I think it is helpful to have the team articulate what stage they are in. This is especially important when the team is in ‘storming’ stage. It can be helpful for folks to understand that there is a possible end to their frustrations with the team, and they most probably will be able to see past their differences and work together.

Motivation:

I believe teams can be motivated in 2 primary axes. I think both are equally important.

The first is transparency and power. Teams should be clear about their minimum viable product. They should also have full power to implement it the best way they see fit. If you have architects and designers who are outside the team dictating how code needs to be structured, it can be demotivating for the team. In order to have a motivated team, you need to give them power, not permission.

The second motivating factor is the performance incentives that folks receives from their employer. It is important to align incentives to team performance and not individual performance. When you incentivize team success, there is higher probability that folks on the team will ask for help in getting the job done. If individual performances are incentivized over team performance, some people can tend to hoard knowledge in an effort to making their role more essential over others. This leads to competition within the team members and hurts the product being built. 

I think it may be best if both individual and team performance are factored in the incentives, with more weight given to team success / failure. If you have individual superheroes within your team, that may be a likely symptom of incentives for individual performance prioritized over team performance. The downside of having superheroes is that you have to think about the loss to the team when the superhero eventually decides to pursue other opportunities.

Rate this post!

☆

☆

☆

☆

☆

Influence without authority

As a Scrum Master, on the one hand I have been held (directly or indirectly) responsible for what the team commits to and delivers, while on the other hand - I don't really have any authority over the team. This situation is very common and not for the faint of heart!

Here are some of my thoughts on how to deal with and possibly make the best out of the situation.

Coach

Coach the team to under commit and over deliver. Try to get your team in a state where they are consistently meeting or exceeding their commitments. This helps build predictability and team credibility with the stakeholders. More credibility usually means more independence. 

For example - when you have a team that meets their commitments consistently, you can push back using objective data points. If your team finishes ~40 story points worth of work each sprint, you have data to back your position that the team will not be able to make the 400 points that you may be pushed into doing in this 1 sprint.

If the team gets into a position where they will not be able to meet the commitments they have made, communicate the information as early as possible. If you communicate early, you have a chance of getting help - either in the form reconsideration of the minimum viable product; or in other ways that the team deems fit.  

Failing early is almost always better failing late.

Create environment where the team holds itself accountable

I talked a little bit in my post on Scrum – metrics what you should measure. I mentioned 2 sets of data points there – team velocity and percentage of commitments met.

In each retrospective, I encourage displaying these data points to the team and asking them – what is wrong with the picture. This helps create an environment where the team holds itself accountable. Retrospectives are also a good place to display the sprint burn down chart and asking the team what is wrong with that picture.

Another good question for the team in each and every retrospective is – how did you add value to the product in the last sprint? This discussion around this question can also help the product owner get feedback on the minimum viable product.

Rather than answers or justifications, try to get the team to ask the right questions.

Establish cadence

If your team produces working software at the end of every sprint, you get minimum viable increments in the hands of the users early and often. If you establish a cadence where you are delivering working increments often, there is less chance of feeling pressure about something being behind schedule. 

With a reasonably working cadence, folks tend to lean automatically towards prioritizing the backlog. If your cadence is not predictable, people can ask for more features early. 

With predictable cadence, people know that the team is actively working on the product and will deliver on their requirements sooner or later.

Manage Up

It helps if your higher ups know and understand the values in Agile and Scrum. However, if you are in a position where your organization doesn’t fully appreciate the benefits of Scrum, you need to coach / influence them. 

I recommend starting out by trying to get support for increased release frequency. This is not a terribly hard sell, because you are saying that you will deliver more releases to customers. This automatically creates more opportunities for your team to deliver on more minimum viable increments. 

If you can successfully and predictably start with 1-2 releases, it is easy to start demonstrating the advantages of having a cadence. With a predictable cadence, you can say – feature 'ABC' is prioritized for the next release, which should be very soon - maybe in a couple of sprints.

Servant Leadership

It helps if you adopt the attitude of serving your team, serving your product owner and serving your organization. Steadily building trust with the team and with your boss creates an environment where they will shield you when you need them to.  

I loved this TED talk in this context.

Learn to deal with the pressure

It is important to know that is part of the job you have signed up for. If you are struggling, ask for help. Talk to other Scrum Masters in your organization. Be transparent with the team and your higher ups. Share the joys of success and pain of failure with your team.

Rate this post!

☆

☆

☆

☆

☆

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!

☆

☆

☆

☆

☆

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!

☆

☆

☆

☆

☆

Ratings!

Hello!
I am really hoping to get some feedback on the blog. Comments are more than welcome, but I've also coded up a small ratings gadget and added it to each of my blog posts.

Please rate the post to tell me if you like it or hate it!

Thanks a ton!
Amol

Rate this post!

☆

☆

☆

☆

☆

Story Estimation - sizing and splitting

I have found that a lot of people have problems with sizing / estimation meetings, so here are some thoughts on that topic. Let's start by defining Story Points - the unit of estimation. To put simply - story points are a measure work effort. We use units of work effort to derive time. 

Why estimate?

In my opinion, the greatest need for estimation primarily arises from the need for release planning.  Most teams I have worked with work on some sort of a plan for releasing their software to the users. Estimates can provide data about how you are doing with reference to your plan.

Not everyone may need estimates though. If you are experienced in Agile, consider giving up estimates for a release or two. However, if you are starting out on Agile, I recommend starting on the side of having estimates. 

Sizing defects?

In my opinion, if a defect must be fixed for the release to go out, it doesn’t matter if you estimate it or not. If you are want to gauge how many low / medium priority defects you can fix in a given time frame, it may make sense to put sizes on them.

Defects can be notoriously hard to size, so time-box the sizing activity. 

Now that we've covered the basics, lets talk a bit about what the Scrum Master needs to do in order to have a successful sizing meeting.

Coaching the product owner on Minimum Viable Product:

I think this image is a perfect example of Minimum Viable Product. I'll let you think about what it is saying. All I can say is that I'm a big proponent of starting out by trying to build stakeboards, not spaceships. Coach your product owners to do the same.

I came across this example from the wonderful podcast at - This Agile Life

Coaching the team to embrace unclear requirements:

At the outset of a project, I tell my team the following 2 points: 

• Inspiration does not come in the form of a prioritized backlog. 
• You don't really know the full potential of your product until you've built it. 

An example of product potential is - I feel confident in saying that Twitter didn't start out trying to build a tool to overthrow dictators. Most products aren't used the way they are initially defined. This makes the product definition job a really hard one. When building a new product, there is no right or wrong answer. This is a wonderful reason to embrace Agile. It is the job of the team to shape unclear product requirements / stories and help build small increments of functionality. Sizing aids that process. Don't shy away from it, even though it can sometimes be painful.

Mechanics of sizing and splitting meeting:

Reference Story(s):

I recommend defining at least one, possibly 2-3 standard / reference user stories. User stories in the product backlog should be estimated based on these reference stories. A reference user story can be story that is fairly well understood by everyone in the team. A story that is already implemented by the team can be a good candidate reference story. It is best if it touches all the layers - UI, business logic, database / server.

Some points that aid sizing / estimation meetings

I've been a part of teams where team members cannot take their engineering hats off when putting a number on the story. For whatever reason, they are scared to put numbers on user stories. I call this "everything-is-a-5" syndrome. I use an Earth vs Sun example to try to overcome this. Even though the Earth is much smaller than the Sun, it doesn't mean there is no work involved in building Earth. It is just that it is less compared to building the Sun. So Earth and Sun can't both be sized to 5.

Sizing  based on "what?" and not "how?"  

I encourage the team to size based on the “what?” and now the “how?” Let's take an example: Let’s say our reference story is one where - we top off the coolant in a car. The story we need to size is say - changing brake fluid.  

I have seen teams get stuck in discussing the implementation details of the brake fluid user story. This has the potential to make sizing meeting remarkably painful. To overcome this, I explain to the team that the question "what?" should yield the size of the story, while the question "how?" is solved in the sprint itself. 

To help aid sizing based on "what?", I encourage teams to try to take a step back and understand what we are changing / touching with the story being sized. Once that is clear, I compare and contrast the story being sized with the reference story. 

For our brake fluid story story, I can say that the car will have some sort of a container holding the brake fluid, just like the coolant container in the reference story. The reference story only involves topping off the coolant container, while the brake fluid story is about changing the fluid. Based on this information, we can say that the brake fluid story is bigger than reference coolant story. This level of detail is generally enough to put sizes / estimates on stories. 

I find that using this technique has yielded reasonably quick and usable estimates. 

In addition to the points above, I found this article by Mike Cohn really helpful to have an "Estimation 101" workshop with my team.

Rate this post!

☆

☆

☆

☆

☆