ESE 499 Systems Senior Design

Ben Allen
ben.allen@wustl.edu

Brian Lukowski (Supervisor)
Brian.L.Lukowski@erac.com

Prof. Heinz Schaettler
heinz@ese.wustl.edu

Resource Allocation Optimization in Agile Software Development Project Management

May 8, 2007

Abstract

Agile development methods are currently in use throughout the software development industry, including in the Data Warehouse department at Enterprise Rent-A-Car. In my experience, Agile methods successfully achieve the aims of iterative development, making the software development life cycle more efficient and effective. However, it seems that the assignment of tasks to developers under the Agile development method could be much more efficient. This report describes the findings of applying operations research tools to optimize the scheduling of tasks to developers on a team.

A Summary

Beginning last summer and extending into the fall, I worked as a software engineer intern in the Data Warehouse department at Enterprise Rent-A-Car. During my internship, I was assigned to work on a project to develop a software application to help manage software development projects within the department. As a part of this project, it was necessary for me to become familiar with the Agile software development methodology practiced in the department, as well as some project management basics used in conjunction with that methodology.

In thinking about a potential senior design project, the optimal scheduling of tasks to team members caught my attention. I knew enough about operations research from my coursework to say that there was something in the OR toolbox that could help to solve the scheduling problem.

Like with many other operations research projects, the modeling of the system consumed a majority of the time and effort I invested in the project. The models were revisited and revised many times; the process followed is outlined below. Above all, I strived to find a model that would match the flexibility of the Agile method. I was looking for something that could be easily used to plan scheduling before each 2-week iteration.

I had an idea to model the system as a linear program, specifically as an integer program. That idea seemed to fit well, since all relationships in the system were linear. To test my hypothesis, I decided to first model a simplified version of the system, with a reduced number of tasks and developers. The following linear program, shown in Figure 1 below, was my first attempt to capture the nature of the system.

Figure 1. Simplified linear model

To understand the model, letís examine it starting from the top. We are seeking to minimize the total amount of time spent working by the group of developers (3 in this case) across all assigned tasks (6 in this case). We sum the decision variable Xij over all developers and tasks, giving us the total amount of time spent. The first constraint guarantees that the actual work done by all developers (with velocity factored in) for a given task is equal to the required time for that task. The second constraint maintains that all developers are committed to work less than the maximum available time. For the purposes of this project, I assume that a developer is available a maximum of 32 hours a week, making 64 hours total for the iteration.

I returned to the project after a few weeks off. In the process of getting back up to speed, I was looking over my simplified model and noticed something that was not quite right. Although not as glaringly obvious as the integer requirement, the problem I found still affected the model. The problem was that I had factored the velocity into the model in the wrong place. With the velocity impacting the sum in constraint 1, the model does not quite reflect reality. That is, the velocity does not directly influence how many hours a developer will work on a given task in a week. Rather, the velocity will impact the actual length of time it takes to work a given task. Consequently, instead of being included in the constraint, the velocity should be included in the sum found in the objective function, as shown in Figure 2 below.

Figure 2. Simplified linear model with velocity correction

Having convinced myself that the simplified model was accurate, I was ready to move on to the last requirement for the project, which was to expand the model to cover a more realistic view of the system. As is usually the case, more realistic meant more complex. However, building on the foundation of the simplified linear model I had already developed, adding in some additional factors and complexities turned out to be a manageable job.

During my internship, I had the opportunity to work with one outside consultant on a project for a brief period of time. This is inspired me to add the factor of developer cost into the model to make it more realistic. After the change, the model would focus on minimizing both project duration and project development cost (in terms of wages for developers). Honestly speaking, this additional factor seemed to be only the tip of the iceberg. However, adding any more factors seemed to be out of the scope of this project, so I left that for future work. After adding in the additional factor of developer cost, the new model has two additional terms in the objective function, as shown below in Figure 3.

Figure 3. More realistic linear model

Those two terms are BPC (Base Project Cost) and CC (Consultant Cost). BPC is the cost incurred by having all the in-house developers on the team. They get paid a fixed amount, whether they are assigned a full load of work or not. Thus, this is a fixed cost relative to the size of the team, assuming an average pay rate for all developers. The second term, CC, is a little bit different. As I have modeled it, you only pay the consultant for the hours he is assigned to work. Whether this is always the case in real life situations is debatable. Also, the changes in the values for i deserves explanation. The single character developers (A-F) are assumed to be in-house team members, while those with three characters (OCA-OCC) are outside consultants. I also expanded the size of the model to more accurately reflect reality. There are now a total of 9 developers (6 in-house nd 3 outside consultants) and a total of 15 tasks.

Conclusions

I concluded from my work that linear programming, specifically integer programming, is an effective tool for modeling the scheduling problem faced in managing Agile software development projects. In the models I developed, I saw an efficient and flexible scheduling tool that seems well-adapted to fit in with the iterative development methods. While I was not able to examine the optimal results for the most realistic case (more realistic model with integer constraints), I trust that with an unlimited version of the MPL software, I would be able to run the model and see good results. That unfortunately will have to be left for future work.