Optimizing Your Development Process
by Neil Fox, VP Strategic Consulting In my last blog entry, How Effective Is Your Software Development, I discussed the three pillars of development effectiveness: Process Optimization, Quality Optimization and Technology Optimization, including architecture, leveraging the cloud, social media, smart devices, etc. This post will focus on Process Optimization.
For many of us (over 40), the notion of process efficiency congers up images of nerds with clipboards and pocket protectors carefully analyzing the motion of workers building products. Just typing the image gives me the willies. Improving software development effectiveness is a little more fun and a lot more interesting! Our concept of effectiveness looks for opportunities to reduce the friction in the development process so that our teams can spend the majority of their time creating exciting new features for our users and not on needless activities.
One size does not fit all. It’s always humorous to consider “Best Practices” as they apply to software development. What may be a best practice for me is not necessarily a best practice for you. There are many factors to consider when reviewing your development process for potential improvement. The kind of work we are doing, the location of our teams, the skill of our individuals, our corporate culture and customer characteristics all have an impact on the effectiveness of our approach. It is fair however, to generalize development into two work streams: new development and application maintenance. You may have other streams of work, but generally they fall into one of these two buckets. New development includes new major functionality, while maintenance activities are typically defect fixes and enhancements. Since maintenance work, including enhancements tends to be more predictable, let’s focus on new development for now.
Every company looks at their software development group(s) (and partners) through a similar lens: How do we best deliver the right functionality to users with reasonable quality? This becomes the goal of our (new development) process improvement initiative – measuring and improving the “amount” of functionality delivered with quality that we have defined as acceptable.
Measuring functionality is a cool topic and one that is often debated. I understand that some organizations are still using lines of code to measure the size of features delivered, but the fallacy of this approach should be obvious. Since human (and nonhuman) behavior is motivated by reward, measuring lines of code results in inefficient code. I don’t think any of us want to drive that kind of behavior.
My preferred approach to measuring functionality is through a disciplined application of story points using a constrained Fibonacci sequence of .5 to 13. Our optimization challenge is to measure the number of story points delivered by a team and then address specific friction in the development lifecycle that prevents the team, not an individual, from completing more story points. This is a meaty topic. There are two important points that I would like to cover regarding the measure of process effectiveness. (We can continue the discussion about optimization in our next blog entry). For today, let’s discuss measuring and estimating work and then how these measures apply to productivity or effectiveness. One of the biggest challenges for most organizations is to estimate (predict) the amount of work to be done on any given software release. The primary cause of software development failure is organizations not understanding the deliverable or the effort required to complete the deliverable well enough to meaningfully determine the cost (and time) of delivery. I’ve found that the best approach is to use (at least) a few Agile methodology concepts. Creating and actively managing a prioritized product backlog will ensure that the development team is always working on the most valuable and important features.
This requires a single product owner to make the call regarding the relative priority (force ranked) of the features to be delivered. If your company cannot appoint a single individual to make the tough calls, I would see this as a serious risk to the success of any development activity. Of course, the product owner takes input from a wide variety of stakeholders, but the product owner makes the ultimate call regarding which features to include in a given release.
Once the product backlog is established, the development team can use a number of techniques to apply story points to the requirements. This approach necessitates the elaboration of the requirements into small enough morsels to be completed in an iteration. I recommend 2-week iterations in order to keep the focus on more predictable tasks. By forcing the requirements elaboration into smaller deliverable elements, we further ensure that there is enough understanding of the requirement to begin development while avoiding the nasty problem of developing features without enough knowledge of what is needed.
I won’t focus too much today on how to estimate and apply story points, since this is not intended to be a Agile training manual, but suffice it to say that by using my preferred method of a Fibonacci sequence -- 1, 2, 3, 5, 8, 13 -- the highest number would be the largest functionality you can deliver in an iteration and the smallest would be the quickest possible task. Everything else is relative to those two extremes.
I like this approach for a couple of reasons. Estimation of work can be somewhat of a 'black art.' I’ve seen many approaches, mostly complicated formulas and estimations of “ideal hours”. The problem with most estimation models is that they typically take a long time and are not very accurate. By using a Fibonacci sequence where the next number is an addition of the previous two numbers you have a spread of options that are grouped at the lower range and further at the higher range.
This allows a developer or architect to quickly and easily determine the “size” of work. If the requirement is larger than a single developer can complete in a single iteration (typically 2 weeks) then you should break down the requirement into a smaller component. The smaller the requirement, the easier and more accurately you can estimate the size.
Measuring the number of story points delivered by the team during an iteration is commonly referred to as team “velocity”. While there are some organizations that use velocity as a measure of productivity, there are other factors to consider. I would suggest that you look at subtracting technical debt from velocity to arrive at your actual team productivity. First, make sure that all stories, including non-functional requirements and defects can be expressed in story points.
Once you have achieved this standardization, it makes sense to subtract the story points missed during a sprint from the velocity of that sprint since we are going to have to make these up later and fix any defects that were not addressed during the sprint. So I like to use a formula such as story points delivered – story points missed – story points of defects to arrive at actually productivity.
By prioritizing your features, standardizing your work output and taking technical debt into account when examining true team delivery, we have created a foundation for optimizing the process. In our next blog entry we will explore common opportunities for making a big impact to delivering features to end users.
blog comments powered by