Let's Talk Dev

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.

I had a situation where one of my teams had some local members and other members who were remote.

At first I tried having the remote team members participate in their daily status meetings via a conference line. That worked, but just not as well as I would like. It was difficult for the remote folks to keep up with what was going on and often there would be discussions that they would not seem to know happened.

After struggling with this for some time I decided to try holding the status meeting over the phone for the whole team. It worked very well.

In fact I have one team that currently is in this situation and I find that having all team members reporting via phone puts everyone on a level playing field. The status meetings run quickly, everyone lets the person reporting talk without interrupting, and the meeting gets handled quickly- just like a daily status meeting should.

From this I have formed what I will call Remote Team Rule 1.

Remote Team Rule 1: When a team has remote and local members, daily status meetings should be held as though all team members are remote.

I agree with the premise that communicating and team building is easier face-to-face than doing it remotely. That however, is irrelevant. We live in a world where remote working is a reality and will continue to be so. It is high time for software professionals and companies to recognize this reality and do what it takes to be good at handling things remotely.

If you question the reality of remote working being here to stay please take a look around. You will see more and more people working remotely. Just look at things like Facebook. People all over are connecting remotely and maintaining relationship at a distance. The kids going through college right now have vast remote networks of people they have never met. Plenty of people will embrace doing things remotely.

I am utterly convinced that over the next decade our profession will embrace remote teams and in a big way. I’m talking about remote working in ways that we have only begun to imagine now. The concept of needing office space for a software development team will be antiquated. Just wait until some 20 year old kid drops out of Harvard and starts up a massive software company using his network of remote developer friends located around the world to build a product line. Think that’s impossible? I think not. Even if that doesn’t happen lots of companies are embracing the concept of remote working. If the rest of us in the software business are not ready to deal with that kind of challenge we will find ourselves obsolete and out of work.

The end game is a matter of survival. Being good at doing things remotely is a necessary skill for survival in the future of software. Acknowledge reality and get good at doing things remotely.

So Going Forward…

In this topic I will continue discussing ideas on working remotely. This will include building remote teams, managing remote people, conducting remote meetings and anything else that come to my mind regarding dealing with remote work.

As managers we love to count how many widgets are produced and at what defect rate. In manufacturing you can easily count widgets and defect rates to determine productivity and quality. You just plain can't judge software development productivity this way. There is no good way to determine what we mean by 1 widget of software. All the numbers are subjective. Software development simply isn't manufacturing.

Because of this, productivity of a software team is not measurable so stop wasting time trying to measure it. Instead, measure the change in productivity. 

I know, this statement contradicts itself. If you cannot measure productivity how can you possibly measure the change in productivity? Well, you really can measure productivity; just not in a way that is useful for direct comparison from team to team. If we look at the change in productivity now we are dealing with something that is comparable and is useful.

Some well known processes like Agile SCRUM recognize this by stating you cannot compare the number of function points produced by one team to that of another. The idea here is that any point system used to measure the amount of functionality added to a system is subjective and will only be valid in terms of that particular product and the team that produces it. Sure a team can determine a point value for each piece of functionality they add to their system, but that number will always be in that team’s units. You just can’t compare that number to another team’s number so there is no way to know if that measurement represents a high or low amount of productivity.

How fast those points are added to the system is called velocity. You can examine a team's velocity and look at how it changes over time. How velocity changes over time can then be compared to how other team's velocities change over time. This can give a good understanding of how successfully a team is increasing productivity. You can even compare this rate of change to other teams.

Quality Also Counts…

You can also look at how many known defects there are in your codebase. This is absolutely necessary as we don't want to get inflated productivity numbers by building lots of things that don't work very well. Heck, you can even get fancy and measure that in relation to the number of function points in your application to get a real sense of the defect density.

By examining how velocity and defect density changes over time we can see if we are producing more functionality at a lower defect rate. If we are doing that, we're on the right track. We can even compare these rates of change to other teams to help us understand what team is being the most successful. We might even be able to start looking into what one team is doing that is working that other teams might want to consider adopting.

So Going Forward…

It seems pretty straight forward on the surface but there are lots of complications to consider. Going forward on this topic I will be discussing ideas on how to measure these things and how that measurement can be used to improve the overall productivity of a team. 

Every time I look there seems to be another article on http://www.physorg.com talking about a new research breakthrough in quantum computing and the physics needed to make it work. At the current rate of development it will not be long before quantum based communication is feasible on a much wider scale and those same techniques have the potential to usher in a new age of technology that will make the current level of speed, miniaturization, and raw computing power look like a Model-T compared to a Ferrari.

I do not expect that we will see this transformation within the next few years but within the next 10 to 20 you can bet on it. At some point in this timeframe this transformation will take place and once it starts it will take less than 5 years to become pervasive.

What can I say?  I am excited about the future of computing technology. Just think of the neat stuff we’ll be able to build with it! Whoever can leverage this computing power will be a force indeed.