Let's Talk Dev

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.

 Today is my birthday! That always makes me look back on things. The most immediate thing that comes to mind is my need to keep things in perspective.

We all get so caught up in what we are doing that sometimes we forget to take the time to see where we are right now. Take a look back and see all the things you've gone through in life and enjoy where you are now.

I so often look forward at what is happening in the near and far future that the joy of the present takes a back seat.

So today I'm going to breathe deep, smile, and enjoy the now.

If this doesn't seem relevant to software development, think again. We are always running hard trying to meet a deadline or addressing an issue. Take the time to look back at all the progress you and your teams have made over the last year.

Hopefully it will make you smile.

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've been seeing a lot of articles and books out there talking about how motivation is not about money. Ideas that bonuses are more harmful than helpful and that what really motivates people to commit themselves to their work are relationships and culture. It's the people and being emotionally invested in what you do, not the money.

Well, this is true- in part. People are motivated by these things more than by money but that is not the whole story.

Take a quick search on Google and you can find plenty of the books, websites, seminars etc. on this topic all purporting to tell companies how more money isn't necessary and probably even a bad idea. Remember that these are people trying to sell advice to companies who are looking to keep expenses down. They are selling the answers companies want to hear.

Even though there is some truth to their answers- all good scams involve a grain of truth. I'm not saying that these things are all scams- just that they smell suspicious to me.

The reality is that if your compensation system undervalues your people they will leave. The folks that leave will be the most qualified as they are most able to find someone who will pay them a fair market rate.

If you are being paid 20% under market it doesn't matter how much you love your job. Eventually reality will hit home and you will realize staying where you are or leaving can mean the difference between your kids going to college or not. It might be the difference in retiring at age 55 or 65. These realities will eventually take precedence over liking your job and the people at work.

So please, before you decide to forego bonuses or raises think about reality. When you review the pay scale of your teams take a look at the actual market. If you pay your workforce significantly under market you will lose good people.

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.

Business people focus on business requirements. When they consider requirements they will be thinking from the client’s viewpoint. The focus will be on what features will be required. They will be paying attention to what business processes are being addressed.

Sometimes items that hint of a technical requirement may work their way in like a service level agreement (SLA). Any of the technical requirements might get addressed in the business requirement but more than likely they will not.

If you don’t step in as a development manager and make sure that the technical requirements are flushed out it won’t happen. You have to make it happen.

 If the developers jump right into building the system key technical needs will be overlooked.

The best developers and architects will try to build most of what will wind up in the technical requirement into the system without it being specified. Most developers will find themselves pushed into a corner with deadlines and these technical considerations will go by the wayside. If we have clear technical requirements for the system this can be avoided.

In order to make sure we get a good system with all of the technical considerations being addressed we need to create a technical requirement as well as a business requirement.

Regardless of your development methodology you are using this holds true. It is just as true for Agile SCRUM as it is for Waterfall. Any functionality being added to a software system should take into account the technical requirements as well as the business requirements. It can be done on the system level or the individual functional level. It just has to happen.

It is the responsibility of a development manager to make sure that these technical requirements are flushed out and included. It may involve architects, team members, or other resources to help define these technical requirements but the buck stops with the development manager.  You would never let your team try to build a system without a business requirement; likewise you should not let them build a system without a technical requirement.

What type of things should be in the technical requirement?

A lot of what goes into the technical requirement should be decided in conjunction with architecture and support. Usually these requirements would reflect a standard for the entire product suite. There is no end to what you might consider but here are some items I recommend considering for your technical requirement:

• Instrumentation - One of the key features that will go into the technical requirement are the instrumentation needs of the application. The needs will vary from application to application and even within features of an application.
• Multi-Language Support - Though the business might not be planning a multi-language version of the application consideration should be given to the ability of the system to be expanded to include other languages.
• Themes/Skins - Any application will want to undergo change from release to release. The need for adaptability should be considered. Allowing for themes/skins in your applications will allow you to adjust to changes in marketing and make it very easy to give the application a visual facelift as you release newer versions. The need to do this from the client point of view would be a business requirement but the ability to handle should be considered a technical requirement.
• Scalability - How scalable does the application need to be. I would suggest that all applications should be highly scalable. My view is that if I get hit with an unexpectedly large number of new clients from sales I’d like the option of just buying some more hardware to keep the system up and running. The needs of individual applications will vary but this should be considered.
• Ping - What will it take to ping your application and verify everything is up and running? Single install applications don’t often need this but enterprise systems will need this always. You are going to want to consider how you will verify that everything is up and running and if there is a technical requirement that needs some implementation to make this work well.
• Warnings/Issue Reporting - Does the system have a need to send out warnings when certain things happen? Perhaps this can be covered in what you are planning for instrumentation, perhaps not. I definitely want to know when there are issues happening in my production environment.
• Client Support - Does your application support only a web based client or maybe other clients like a windows forms client or even an iPhone or Google Apps client? Consider the fact that you may need to support other clients in the future. How much support for this does your application really need?

Add to the list as you need and make sure that any technical concerns raised by support reps, database engineers, automation engineers, test engineers, developers and architects are all addressed.

It looks like a lot of overhead but the results will be much better for the effort.

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.

Ok, its getting close to the end of June and as promised this blog is fully up and running. There are even a few posts. You'll see a lot more in the coming months. 

So today I read http://www.physorg.com/news196258264.html and got all excited about photonics as a possible next step. I also keep reading about the advances in quantum computing including the quantum encryption being used at the world cup matches in Africa. It seems to me like there is a bit of a race between the two concepts to land the next evolution of data processing.

After thinking about where both of those technologies are I have to admit that it looks much more likely that we'll see a photonic processor in a PC long before we see a quantum processor. At the same time I do think the quantum techniques will come into more use.

Perhaps what we'll see is a move to photonics for general computing with quantum techniques being used for specialized applications like encryption. In the last 10 years we've gone from the introduction of a 64 bit processor to 6 core hyper threaded processors. I'm looking forward to the next evolution of processors. My money is on photonics as being the next step with quantum processing not far behind.