Importance of Requirements Management for Agile Development

November 21, 2007

Recently, a colleague and I were discussing the importance of requirements management when leveraging Agile development methodologies. The discussion resulted in a summarization of three primary reasons requirements management is critical to success in Agile development. They are Quality, Agility, and Management of Expectations.

1. If a project has ambiguous requirements the team cannot determine at the end of each iteration if the product is releasable. What happens is the team demonstrates and exits the iteration without good acceptance criteria. This means there is questionable quality at the end of the iteration. The result is a large QA cycle at the end of the release and the date slips. The team simply cannot tell if an ambiguous requirement has been met. This puts them into defect management. Its no longer about delivering incremental working software when this happens. It is more about large releases and working through a stack of defects in the end game. Improve requirements and improve quality.

2. Release planning is about assigning “value points” or IDDs or some other sizing mechanism to requirements and laying them into iterations. These requirements become the fundamental unit the team develops against during each iteration. While requirements will always have interdependencies, they need to be as loosely coupled to each other as possible. This is where the team “gets” their agility (or should). Teams need to be able to move these requirements between iterations and between releases. This presupposes a couple of things. First, there must be a continuous backlog of requirements to be consumed an ongoing basis. This backlog should be used across iterations and across releases. Second, the backlog is reprioritized and elaborated on an ongoing basis. Teams must have near perfect requirements to be truly agile. Improve requirements and increase agility.

3. Requirements management is critical for managing existing consumer expectations. There needs to be a process that takes requirements from various sources, determines if they should be added to the backlog, and disposes of them properly. This allows for management in many directions. I like to call this requirements work flow. Easy to describe but seemingly difficult to do. Improve requirements and manage expectations.

For teams new to Agile good requirements management (in this form) will likely be elusive. However, a detailed understanding of requirements management and its importance will significantly increase the probability of success when transitioning to Agile.


The Passion Behind the Software

November 11, 2007

It must have been about ten years ago now, perhaps a little more. At the time, I was conducting a self study of TCP/IP. The motivation behind the study had little to do with economic gain. I simply had a curiosity for how networks functioned – especially the Internet. I had set up a few small websites and written some freeware programs. The excitement of someone viewing my web pages or downloading my programs still makes me curious. Why was it so satisfying?

During this same time frame I developed a small Win32 application that performed an ICMP Ping. It worked very similar to the command line version on Unix. It differed from the command line version on Windows in that it provided much more data about the results of Ping operation. Most notably, it was an elegant (for the time) GUI application. The reason for writing the program was simply to allow me to advance my knowledge of TCP/IP.

Upon completion of the program, it was made available to the public via a few freeware websites. It was downloaded frequently. Every day upon returning from work, I would rush to the computer to go to the website and see how many people had downloaded it. On the days with a high number of downloads, I would feel energized and motivated. This frequently motivated me to enhance the program. Never once was profiting from this utility seriously considered.

A few months passed, there was an email in my inbox from one day a company in Australia. The letter told indicated this company was deploying a standard desktop software environment to the entire company. All 30,000 desktop computers would have the exact same configuration. The letter was requesting a price to allow them to include the ping program as part of their standard desktop environment. They were interested in a feature in the program that allowed the user to export the ping results to a text file where it could easily be attached to an email an email. The letter went on to say the company was wrestling with network issues. They needed an easy way to help resolve network problems. The users were not advanced and asking them to capture output from a command line Ping utility was proving to be difficult.

At this point, I was overwhelmed with excitement over the thought of up to 30,000 people having my software installed on their desktop computer. It simply did not occur to me to try to sell them the program. It was free software. It just was not about making money. I responded back to the company allowing them to use the utility free of charge. It was quite gratifying just knowing they were using my code. In the end, I am certain the company would have happily paid me for the software.

Almost every time I tell this story, someone talks about the money that was missed. The response is always the same. It was not about the money. It was about the satisfaction of knowing my code was in use, knowing someone found it useful, and knowing I helped this unknown company with their network problem.

This very simple example has millions of occurrences amongst open source and freeware developers. A few months ago, I purchased a MacBook Pro laptop. Not long after the purchase, it seemed to run very hot. Attempting, to solve the problem, I googled “MacBook” and “Heat”. One of the top results contained a link to a free program called “Fan Control”. This utility allows the user to control the fan speeds such that the system runs much cooler.

About two weeks ago, Apple released their new operating system known as “Leopard”. Upon install, I noticed the laptop was hot again. Back to google, I went. This time I added “Leopard” to the search. Sure enough, there was a link indicating there was a fix to the fan utility which made it compatible with Leopard. Not only did the author of “Fan Control” provide the utility free of charge. He also provided support and patches faster than most large software companies.

The over arching question is “Why?”. What is it that drives people to work for free? What motivates them to create high quality deliverables? Is it the satisfaction of participating in a broader universe? To belong? Is it a desire to leave a legacy? Or perhaps, a desire conquer or create something? Is it the ability to control ones own destiny?

Regardless. of the answer, software organizations have a unique opportunity to understand what drives software engineers and introduce those key characteristics into the work environment. For example, if it is true that leaving a legacy is important to developers, companies should create an environment which publicly (internal or external) acknowledges the work that has been accomplished by individuals.

Is it possible bring the passion of free software development into an environment where people are paid to produce?


What makes them tick?

November 10, 2007

Recently, I was involved in a discussion regarding the optimal organizational structure for a large software engineering organization. Several of the attendees were proposing various structures. The primary goal was efficiency and maximizing the output of each individual.

The proposals included ideas such as creating a resource pool made up of software engineers with varying skill sets where team members act as a group waiting for assignments. In this scenario, any given engineer could be working on many different projects over a period of time. The source code tree he is working on today may very well be different than the one he had worked on even the prior week.

As the discussion progressed, I found myself believing the participants had missed a critical point. My belief was and is workers (software developers in particular) need to feel a sense of ownership in the project they are working on. In other words, most modern day developers are not content to work on code where they do not have an understanding of how their effort relates to the success of the unit. Beyond understanding, they need to feel as if they have influence. My belief is not only based on a suspicion regarding what motivates software engineers, it is primarily based on personal experience.

During the course of discussion, I commented, “regardless of the structure that is chosen for any organizational structure, it is critical to analyze the individuals which participate within that organizational structure. You simply cannot make a decision regarding organizations without an understanding of the impact it has on the individuals”.

Admittedly, the notion is somewhat intuitively obvious. However, I have witnessed many discussions regarding companies, organizations, etc. which simply do not take into consideration what it is that makes the employees do what they do. What makes them tick? While its impossible to generalize across a large organization, everyone is different, it is possible to understand the general effect an organizational structure may have on a team. The first test, simply ask yourself the questions…How would I respond if I were put into a given work structure? How would it feel to transition from collectively owning a product to serving a role in a resource pool? Would you be as motivated and energized?


What’s in a name?

November 10, 2007

Today, this blog received its final name “Working Software Every Two Weeks”. While Agile development may mean different things to different people. One key concept remains consistent. The successful Agile development team will focus on completing working software in very short time frames or increments. For many Agile teams the chosen length is two weeks.

For me personally, this name carries great significance. My first introduction to Agile development included the statement “that is a nice waterfall process, however, I am most interested in a software methodology that allows us to deliver meaningful software every two weeks”. Admittedly, I was quite skeptical at the time. Today, the skepticism has been replaced with deep conviction that Agile development is the most productive and rewarding way to create software.


Managing a Large Agile Software Engineering Organization

November 8, 2007

Recently, I had the privilege of presenting a paper to a number of companies interested in Agile software development at the Agile 2007 conference. Entitled “Managing a Large Agile Software Engineering Organization”, the paper discusses my personal transformation as I was introduced to Agile software development. Below you will find the abstract and link to the article.

Abstract
This is the story of my business and personal transformation as our department adopted the Agile methodology. The bumps and bruises along the way forced a shift in management philosophy. Embracing the transformation has enabled significant success within the company. The confidence of our customers and internal organizations in our ability to deliver high quality software has increased dramatically. Software releases are now delivered on time with an improved level of quality. However, this success did not necessarily come easily. There were many obstacles to overcome as this large organization transformed itself from a largely waterfall development organization into a high-output Agile development machine. This article presents this transformation and the impact it had on the organization’s leadership and management styles.

Unfortunately, you must be a member of the IEEE computer society to access the article free of charge. Otherwise, there is a fee to view the full article.

Access the Article Here


Welcome to Paul Beavers’ Weblog

November 8, 2007

Next month, December 27th to be exact, I will complete twenty years of professional software development. It seems most appropriate to celebrate this milestone by establishing a site which allows me to share my software development ideas and general management principles with the software engineering community in the form of a blog.

The change of the software industry over the last twenty years is amazing. It’s virtually impossible to imagine building software without access to the vast number of online technical resources. During the course of writing a program today, most programmers make countless trips across the globe searching for information. All from the convenience of their computer desktop. Twenty years ago, programs were written with only a few examples and a couple of hard copy manuals. Today, online resources are the sole source of information for most developers. It is with a sense of gratitude for this medium that I offer this site to you.

Over the last twenty years, I have had the privilege of writing applications for IBM mainframes, TI business systems, Solaris, Linux, and Microsoft Windows. This development was done using a wide variety of computer languages and enabling technologies. Additionally, I have been exposed to many different management philosophies and and software engineering methodologies. Hopefully this is intriguing enough to make you curious enough to check back here from time to time for information you find relevant.

My passion lies in the area of Agile software development. You can expect to find a number of articles here directly related to Agile development methodologies. From time to time, you will find interesting writings on various technical topics. Sometimes you may even find a post regarding something not related to software or technology. While I cannot commit to a frequency of postings, I will strive to make the postings here worthy of your investment in the time required to read them. If you read something here you do not necessarily agree with, please feel free to post a follow up telling me so. I believe good spirited debate will help us all to improve.

I am excited to have this opportunity to share with you.

Sincerely,
Paul A. Beavers