Welcome to the first installment in a multipart series focused on engineering effectiveness. In this first installment we will discuss the components of an effective engineering group as well as components of process optimization. Further installments will focus on ways to measure and then improve the overall effectiveness of your software development group(s).

Perhaps you have had the joy of being part of a team that is the development equivalent of the flying Wallenda brothers—appearing to defy the very laws of physics, perhaps even daring the earth to come up and swallow it—only to amaze its audience with a quadruple flip without a net. More than likely, though, you have been part of a development team that can’t decide where to go for lunch or code its way out of a wet paper bag with a switchblade USB key. So, what makes one development team more effective than another? No doubt the answer is a mix of complex human motivations, behaviors, and managerial skills. However, there are also specific elements that can be examined, measured, and systematically improved.

Leaving sociopathic personality disorders aside for the moment, let’s focus on those critical elements that we can reasonably manage. Assuming that the rest of the organization has identified the right products and applications to build, I like to think of team effectiveness in three dimensions: process, technology, and quality. As you can see illustrated in Figure 1, development teams can examine their efforts by each of these 3 dimensions, ensuring that the entire effort is aligned to the objectives of  the business. By objectively evaluating these three dimensions, you can set on a path to increase the effort spent by the team on actual development and use the resulting benefits to help drive cost savings or investment in new innovative solutions. We have seen overall productivity, as measured by the number of standardized story points delivered, improve my 30% or more.

Figure 1: Components of Engineering Effectiveness

Business alignment is a critical component of the process often overlooked when assessing the performance of a development organization. The first step is to clearly understand how we, as a software group are able to help the business drive new revenue, launch innovative products, lower costs, or whatever the business decides are their objectives for the next 1 – 3 years.

For the purposes of this series, we will focus on process optimization, which is also typically the low hanging fruit for most companies. As a consultant for several large organizations, I speak with a lot of CIOs and software development leaders about their effectiveness. Most often, we start with assessing and transforming their development process before taking other steps. The general theory is that fixing bad process first creates the biggest opportunities to address quality and technology issues, as well as potentially addressing their underlying cause. Starting with process optimization may prevent some of the other trouble areas from reoccurring in the future.

Process Optimization
Agile is all about more effective delivery. Most of us who are drawn to agile methodologies have an internal drive for constant improvement. We know there must be a better way to deliver quality software that quickly meets our customers’ most important needs. This is the thought that drives us every day, and it’s the thought that brings us to agile and brings companies to leverage agile coaches, experienced Scrum Masters, and effectiveness consultants.

The vast majority of companies I work with have some kind of distributed development that presents significant challenges in their delivery and productivity. Let’s face it; spreading your development team across time zones, cultures, and languages is a really hard thing to do without negatively impacting development productivity. Either employees are in different countries, different regions, or, perhaps, just working from home rather than collocated in an office. In many ways, this very notion is the opposite of what agile was founded to accomplish. The reality, however, is that development teams can have their cake and eat it too. Companies can leverage talent across geographies and time zones and be agile. Though geographically dispersed development demands more process rigor and careful systems configuration than having everyone in the same room.

By following my process optimization triangle (Figure 2), software development groups can ensure that their methodology, tools and metrics are all aligned to meet their needs. I’ve seen many companies that have well documented processes but have neglected their tool configuration and integration. Most organizations also do not consider appropriate metrics when examining their process. This is akin to flying an airplane without a cockpit display. Since this is a complex and important topic, we will devote an entire installment of this series to the identification of relevant metrics, how to collect, validate, report and interpet these critical indicators.

Figure 2: The Process Optimization Triangle

In order to achieve maximum effectiveness with distributed teams, there are several key points to keep in mind.

Team Organization
It is absolutely critical to place the right people in the right roles within each geography so as to ensure an effective distributed agile team. I can’t tell you how often I see companies consolidate their knowledge in one location, such as their US headquarters, while delegating development or QA to other regions. This approach negates any benefit from agile development. Let’s remember that the only way to make a team productive is to have it as self contained as possible. Of course, no development team can be truly independent due to reliance on business stakeholders and other outside input, but you can do your best to include all relevant functions within each geography.  We suggest the type of structure shown in figure 3, where there are proxies for the primary product owner and architects are resident locally to the development team. This approach requires the “product ownership team” to be in almost constant contact and lock step in its vision. Giving the development team real-time access to someone who can provide product direction allows the team to work without disruption by time zone differences, language barriers, and cultural differences. We certainly do not want to force or even suggest some kind of hierarchy globally, but rather provide the best knowledge as close to the development team as possible.

Figure 3: Recommended Distributed Agile Org Structure

There are several other key elements of optimizing agile software development effectiveness, especially in a distributed environment. We will explore techniques for objectively assessing and measuring your process effectiveness in the next installment of this series and then focus on metrics and how to use them to help optimize your development efforts. Remember, software development is all about helping our business drive innovation and customer delight! The more friction we can take out of the process, the better we can meet these goals.

Trackback(0)

TrackBack URI for this entry

Comments (2)

...
written by Neil Fox, June 08, 2011

Hi Mark.
Distributed scrum teams are challenging for a multitude of reasons. I've managed several of them and the most effective had several qualities in common:
1. They knew the domain and product VERY well. This was challenging for new team members but we focused on up front indoctrination so they could interpret the user stories more effectively.
2. Every team member had a fanatical devotion to instant messaging. Not every team member was available all the time due to time zone differences and other factors, but when they were on line, they were available via IM. This created as much of a virtual work space as possible.
3. Constant real time updates to the development management systems. It doesn't matter too much which systems you use, but configuration of the systems to support the process is important (I'll talk more about this in the next article) and keeping the system, including a Wiki, updated become a critical success factor when the team is dispersed.
4. The final element is a really strong Product Owner. The PO needs to be proactive about keeping the team updated on the details of the product priorities. If you don't have a strong PO, it's going to be almost impossible to be effective in a distributed environment.

Hope that helps.

Others please chime in if you have different tips!

Neil

• 
• +1
• 
• 

...
written by Mark Waite, June 08, 2011

Thanks for an interesting first article. I would love to place the product owner in the same geography as the scrum team. I've enjoyed that working model very much in the past.

Unfortunately, my scrum team is split across geographies. We are a team that needs to provide services to developers around the globe, and we need those services to be provided in the time zone of the recipient. We've consciously sacrificed the efficiency of local development in favor of the efficiency of providing support to our stakeholders in their time zones.

Are there techniques you would recommend for people like me who have consciously chosen to split their scrum team across geographies to better serve their stakeholders by time zone?

• 
• +0
• 
• 

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview