Let's Talk Dev

So often I hear people taking note of the number of meetings involved in running a scrum team. It strikes me as curious because before I used scrum there were still lots and lots of meetings. More of the meetings revolved around planning things that later were scrapped or projects that were rescheduled many times.

In scrum, the meetings that we have are all about keeping the team on track and just planning enough to do the next sprint. Sure we spend a few minutes every day in our daily scrum. That takes the place of me showing up at team members' desks, chatting, emailing, and otherwise bother folks about the status of the work. The team stays on the same page and things really keep moving.

My experience has been that more work gets done because of these daily meetings.

Now, the other management meetings that are no way related to scrum- that's another story all together. 

Ideally the commitment made each sprint is by the entire team to complete all of the committed work as a team, not simply to complete specific tasks as individuals. 

When the commitment is to the entirety of the sprint a team member’s work is not done until all of the committed work is done, not just their individual tasks.

When a person is working on two teams they are forced to look at the work they are doing as an individual commitment instead of as part of the team commitment. Once their committed tasks are complete for one team they focus on their committed tasks for the other team. This forces them to be less than a fully committed member of either team. 

Accountability and transparency are two important aspects of any team based system such as Agile SCRUM.

Working on two teams also provides opportunity for someone to hide work done outside of teams by pointing to work being done on one team or the other. This reduces accountability and transparency. The person often won’t even be aware that they are doing this. Interruptions and other unplanned work tend to take up a lot of time and are simply not noticed as impediments. The person will feel very busy but won’t be bringing much too either team.

There is always more work that can be getting done on a team so any argument that there isn’t enough work for a full time employee in a role on a team is invalid.

Often teams limit themselves to specific work items handed to them by their product owner. In many ways this is correct as the product owner sets priority. The problem with limiting the team in this way is that there are always items that need addressing and investigation that will not be on a product owner’s radar until it is discovered as an issue in production. 

A team should always put the work brought to them by their product owner first but in the rare cases where a person on the team doesn’t have enough to fill their time with the stories brought by product management it is a great time to do those extra things that will never make it into a product owner’s plan.

What kinds of things are these? How about looking for bottlenecks and system performance improvement opportunities? How about looking at system capacity and usage? 

Often the person who finds themselves without enough work on their plate is limiting themselves to a very specific role such as a database engineer. How about taking some of that time to learn some new skills that can benefit the team? Expand your role and become more cross functional. Become an expert on more than just the one area you already have expertise. Use the opportunity to increase what you know and in the long run the team will find itself with a better system and higher velocity of work getting completed. 

Does this apply to the Product Owner and Scrum Master as well?

The short answer is yes. With that said- if there is a shortage of resources, the scrum master and product owner are the first two positions I would share between teams. There WILL be time conflicts between things needed for both teams. This requires a scrum master and product owner with strong abilities to prioritize and a willingness to let the teams members act in their place when needed.

Sharing someone between multiple teams is far from ideal and should be avoided whenever possible. 

In SCRUM we put sizes on user stories that translate into velocity points. This is used for all sorts of things but primarily to determine how much work there is to do and how much has been done.

I've seen plenty of discourse over whether or not stories should be sized based on complexity or the amount of effort the team estimates will be required.

This is a fruitless debate and is a distraction from the goal of Agile SCRUM. Debating this is not useful.

Instead I suggest that effort and complexity really is the same thing. User stories should be sized based on how much work there is to do to get it done because that is what the velocity is supposed to measure.

More complex items take more effort. Items that require more effort are inherently more complex as the odds of something unknown cropping up are increased.

So the question is not of complexity vs. effort- Just realize complexity = effort.

In Agile SCRUM we size things to put an estimate of the effort and complexity involved in producing the work product. We might say that the size of something is extra-small, small, medium, large, etc. These sizes translate into velocity points. How many of these points we complete each sprint tells our product owner how much work he should expect to get done in a release. It is one of the most visible measurements of productivity that will be seen by upper management.

In my teams, the primary things that are sized are user stories and defects. User stories represent new work and defects represent work to fix a defect in the application. I have found that they way teams tend to do their sizing is different for user stories and defects. It is like a different scale is used.

In general a medium sized defect winds up taking a lot less work than a medium sized user story.

This creates an issue when measuring velocity and ultimately when measuring productivity. If your team spends a much larger percentage of time working on defects in one release than in the next, you will see a drop in velocity.

As we know velocity is watched by many folks in any organization. Perceived drops in velocity will raise questions and cause concern. It should! However, in this case what is seen as a drop in velocity really isn't. It is simply an issue with how sizing is being done.

I am now pushing my teams hard to consider sizes of defects in context of user stories that are also sized the same. 

It is very important for a scrum team to size work efforts consistently. Always push the team to compare the work effort of an item they are sizing to other items they have sized in the past- Especially when sizing defects. If you don't then your velocity metric will be misleading.

Sprint demonstrations are important for more than just the development team. They are the opportunity for clients and client representatives to provide early feedback on what is being developed. It is an opportunity to get a first look at the new functionality so that when it is released you are not seeing it for the first time.

Attending sprint demonstrations is a valuable use of your time. Anyone who uses an application or supports clients using an application should attend sprint demonstrations whenever possible.

Attending a sprint demonstration should be something that is done actively. It is your opportunity to raise questions, issues, make suggestions and provide your input on how things being added to the application should function. It is your opportunity to give input on how things that you need to use and support work.

Use this opportunity to help make the applications you work with better, easier to use, and easier to support.

How a sprint demonstration is handled varies but the key value is to get real feedback on what is being built. Anything that helps deliver this value is reasonable to consider doing. Feel free to suggest changes to the demo meeting format that would help make this value more real.

Please- attend sprint demonstrations whenever possible and be part of making things work better.

I currently act as scrum master for two teams, one remote and one co-located. I have found that the conversations around expected functionality and business requirements happen on both teams but the information seems to get lost and confused on the remote team.

This perplexed me for a while. I thought I was doing the same things with both teams. The same basic planning and discussion was taking place but the remote team just seemed to always wind up with more confusion. More of their work had to be reworked to get acceptance from our product owner.

Eventually we began writing down all of our decisions and business expectations instead of just relying on the discussion. We started having our business analyst do more documentation of the features in the beginning of the sprint and reviewing what the team was planning to build.

After doing this for a while I could see it was working. The confusion had been cleared. About that time I realized that this is exactly the same thing my local team was doing all along. The only difference was that the remote team took longer to figure out the need so it was staring me in the face as something that was harder for my remote team.

After thinking about this I realize that remote teams take longer to identify and solve issues with how they are doing things. That is really the root cause of this issue. I suspect a lot of my remote ream rules will be incorporating items identified this way. If I can just find a way to fix that root cause the other rules wouldn't be as necessary.

Eventually technology might solve it and eliminate the difference between remote and co-located teams. In the meantime figuring out this set of rules for handling remote teams is my best answer.

Remote Team Rule 2: Team decisions need to be written down and shared.

Agile is all the buzz in the development community. SCRUM is one of the most popular forms for agile software development. There are plenty of would be gurus ready to help you implement Agile SCRUM and plenty of books to go along with it. Agile SCRUM promises to help you push out better software, faster, and at a controlled cost.

So can Agile SCRUM deliver on its promises?

I've been doing Agile SCRUM for about 2 years now and the best answer I can give to that question is yes; as long as you understand what Agile SCRUM really does. Following Agile SCRUM will not solve your problems by itself even if you think you're following it to the letter. It will not replace good development practices and solid architecture. It will not make up for inadequate quality control or badly designed applications.

What it will do is help shine the light on issues. There will be pain involved in going to an Agile SCRUM world. If you manage the transition the promise is real, but the challenges are many.

Going forward...

Going forward on this topic I will discuss many of the challenges I have seen and overcome. I will also discuss the challenges I am currently dealing with and my attempts to solve them.