Integrate Software Project Management with Extreme Programming Practices; a case study in Product based Software Development

Ridi Ferdiana Electrical Engineering Department Gadjah Mada University Yogyakarta, D.I.Y 55281 Indonesia ridi@acm.org
ABSTRACT

Lukito Edi Nugroho Electrical Engineering Department Gadjah Mada University Yogyakarta, D.I.Y 55281 Indonesia lukito@mti.ugm.ac.id
is in small software size. Therefore we are developing this project by only four people. The people role of this project is adopted with our daily position in Microsoft Innovation Center lab, like a follow. Technical Strategist, this role is the product manager of the software. He initiates all the key requirements, get a feedback in a meeting, manage the resources and schedule, as well as make sure this software is passed in quality assurance. Project management is captured in this role. Technology Specialist, this role is best fit with technology adoption. He will prepare smooth adoption right technology for the solution, as well as guide the team in technical manner. Developer Specialist, in Extreme Programming this role will build the implementation code, and pairing with Technical Strategist or Technology Specialist, to create better code and also understand the system. IT-Pro Specialist, this role will help the team to provide IT infrastructure, and deploy the system in iterative way, based on our release plan.

In this paper, we describe some advice to adopt Extreme Programming practices in daily software project management. This paper also offers a number of suggestions on running product based software development project management with the spirits of Extreme Programming practices. This paper is based on literate study as well as field study that happen in Microsoft Innovation Center lab, Yogyakarta. Indonesia.
Keywords

Projects Management, Software Engineering, Extreme Programming Practices.

INTRODUCTION

Extreme Programming is one of the process methods in Agile Software Engineering process models. Extreme Programming starts his debut in earlier 90s [Beck, 2001]. This process have already adopted in many software constructions from capstone project [Keefe, and Dick, 2004] through R&D projects [Coelho, et al, 2005]. The successful of the project is some kind of proof that Extreme Programming method can be adopted wisely to provide a value for the customer through better and faster working software. Although there are some of negative argument about Extreme Programming [Stephen, and Rosenberg, 2003], we try to proof extreme programming method by implement this method in our own project. Our project is developing metadata search engine, which will help student to find a journal, related books, as well as expert for their thesis. This project will combine a lot of existing technologies that support academic related searching such as Google Scholars, Live Academia, and Amazon Web Services. Beside of that we will try also build expert search engine based on community approach activities, such as blog activities, and forum activities in related field study. Based on McConnell estimation guide [2006], this project Draft version ACM owner copyright 2009 Last Updated 1.30.2009

PROJECT MANAGEMENT PRIMER

Project management is the act of managing an endeavor to bring it to the required results [Baca, 2007]. The required result is depends on the project sponsor, however in software project a working software and defect free is the main result [Cockburn, 2006]. Project is leaded by project manager. Project manager manages things that related with the project. The things that project managers manage are called project elements. Figure I. illustrates some of the elements in project management.
Risks Quality Deliverables Schedules

Customer

Scope

Process

Budget

Team

Communication

Documentation

Fig. I. The Elements of Project Management

The elements of project management will run in project life cycle. Project life cycle can be defined as all the phases of a project when taken together from the beginning of the project through the end [Heldman, 2003]. Project life cycle is divided in some of phases. Every phase has transition between each phase of the project life cycle, this transition called as handoff. Heldman states that project management consists of five main phases, there are. Initiation phase. Initiation is the first phase of a project life cycle and is where the project is requested, approved, and begun. Planning phase. The project life cycle phase where the project plans are documented, the project deliverables and requirements defined, and the project schedule created. Executing phase. Team members perform the work of the project. Teams are assembled, the task assigned, and the work carried out. Controlling phase. This phase concerns monitoring project performance to make certain the outcomes meet the requirements of the project. Change requests are monitored and reviewed in this phase. Closing phase. The last phase of the project life cycle, where final approval is obtained for the project, Fig. II. Four variables in Extreme Programming The relationship between the variable is described by the arrow. In example the greater functionality will make the time and cost is increment, however give us more time or provide us more cost wont add quality and functionality. These four variables lead us to adopt four values that we must hold on in Extreme Programming method. These four values are communication, simplicity, feedback, and courage. Every value has some practices that we might implement it as a part of discipline in Extreme Programming method. Figure III illustrates us the four variables as well as some practices that related with the variables.

The regular rhythm of projects is straightforward, its mean initiation is come first before planning, and execution is run after planning. However Sliger and Broderick state that the phase is determined by the control needs of the organization [2008]. This means that in software project, the life cycle will be adopted through the software development process. Project management can become managerial framework that will support technical aspect of software development. Frankly speaking project management will steer the software development process and this is what we do in term of product based software development. We encapsulate the essence of project management life cycle in software development process.
EXTREME PROGRAMMING VISION

Communication

Simplicity

Feedback

Courage

Customer Centric Planning Game Pair Programming

Simple Design Methapor Collective Ownerships

Refactoring Small Release Continuos Integrations

Spike Solution Testing Coding Standard

Fig. III. Four values in Extreme Programming. Each of practices is integrated with common software process. We use standard common software process that started with planning, design, coding, testing, and deploy. McConnell [2004] stated that every software project consist of two major steps, there are software constructions and non constructions. Planning, design, coding, testing and deploying are the steps to do constructions stuff. The others like budgeting, scheduling, resourcing is inside nonconstructions stuff. Extreme programming doesnt explicitly state of project management inside the origin discipline, so in this case we try to submit some project management stuff in Extreme Programming methods.
PLANNING

The main reason adopting Extreme Programming is the term of simplicity. We are lacking of the resources who can handle documentation, we are lacking of case tool support like UML Designer, as well as we are lacking of the time. Extreme programming provides us to value the main four variables, in our projects there are functionality, cost, time and quality. Figure II illustrate the four variables with their relationships.

We started this step by inviting the client. Every client that visited in interview sessions majorly is last year student. Many of them have some non-technical difficulties to find related material for their thesis. They express themselves using stories about what they hope in the application that

we want to build. We capture it by using plain paragraph that noted in word processor. Since the application is product based, and will behave generic just like others search engine, we dont face any problem to capturing the user stories. Figure IV illustrates the sample of the user stories that we build in open source software called Agile Planner. The user story consists of the main story, priority (high, medium, low), status (pending, in progress, completed), and story point using the Fibonacci number (1, 2,3,5,8...).

UML. Interrelated Project Communication plan Describe the last experience project that related with the project. Describe all the communication method that used in the project, such as email, public folder/ftp, staging server, and also stand up meeting. Describe the return of investment in this project, including the expense, income, and profit analysis

Financial Analysis

Figure IV. User Story In planning phase we develop two main documents, the first document is project overview, and the second document is developer specifications. Both documents are developed by technical strategist role, reviewed by the all stakeholder and approved at the one meeting in the end of the week. Project overview document consists of project management information that related with the application. Table I list all the main point in the project overview document. Table I. Project Overview Document
Management Point Project Detail Project Summary Descriptions Consist of quick summary of the project, such as project name, sponsor, manager, and client. Consist about the background of the project, the problem that we try to solved, and the solution we offer. Scope of the project, what feature that includes what feature that not included in the project. Describe how we tackle the scope through software engineering process. In this step we give a simple brief about Extreme Programming Method, as well as related technology that we will use. All the people that related with this project, including their role in this project. Describe the output of the project, and the time constraints Describe the milestone or the target that set incrementally, this milestone will be related directly with Release Plan Describe that existing risk in the project such as loss, technical challenges, etc. Describe the key resource, to handle the software project, and the skill that required. I.e. Analysis is handling by Mr. X and the skill needed is

Project overview document become some input for developer specification document. Developer specification document consist of two main points, there are release planning and user stories. Release plan is developed by seeing two points in project overview document, there are Project Deliverables and Key milestone. Key milestone become a title in iteration, and give us a sight how much we divide the project into iteration. In our project deliverable is stated as sixteen weeks. Since we have seven key milestones, we can divide our sixteen weeks with seven milestones; provide us two weeks per-iteration. =
( ) ( )

After we know the iteration and the length of the iteration, we invited our client to do some planning game. We draw a picture in our whiteboard, and write the entire user story in many sticky notes. What we draw in the whiteboard is a table with a placeholder that ready to stick with a sticky note. We stack the card and give the client the entire user stories. Client starts to select the card and put it in the placeholder. Figure V illustrates the digital version of the release plan.

Project Scope Project Approach

Key Stakeholder Project Deliverables Key Milestone

Fig. V. Release Plan and User Stories In this step we do project management activities listed below. Inviting the client for express themselves about the idea they have in application. Create project overview document. Stand up meeting with the client to do a selection of feature in planning game session.

Risks Key Resources

In tailor made project, we think there will be additional step to discuss the rough calculation of the budget. However

since our project is product base project, our revenue is depending on the product sales.
DESIGN

This step is started by revisiting the result of the developer specification. From each use story we try to find the noun. The noun itself is used as an entity in CRC (Class Responsibility Collaborator) class. Figure VI illustrates the CRC diagram that we draw in digital version.

overview become will be refined by the effort of the team member. Team leaderships hold a work to keep project is on track and decided to refine the release plan. Changing the release plan is sometime occurs since there might be a technical difficulties or insufficient technology that we used. Release plan is changing after approval from the team member as well as stakeholder in the stand up meeting. Basically in this step we do project management activities listed below. Record actual and estimates for the team to solve every user story. Track project status openly and honestly, this include the feeling to open a change requirement, just like in agile process. Doing leadership-collaborations management style, who always keep gives them courage to do exploration, build adaptive team, and simplify the plan.

DEPLOY

Fig. VI. CRC design with Additional Arrows CRC provides us more clear what the class will do, and what the relation between entity. From this point of view we find some technical challenges. In example we dont know how to develop a client that used with Amazon web services; in this case we create spike solution, our term for throwaway prototype. Project management in this step, is limitedly by seeing the team is on schedule. Furthermore the action in project management in this step is listed below, Do stand up meeting in every three day to solve and discuss about the problem that we face. Documenting the CRC as well as spike solution that strongly believe will become investment as knowledge base for the future. Making sure that release plan can be achieved by the time constraint.

There are two types of deployment, initial deployment, and final deployment. Initial deployment reaches in client every milestone in a release plan. Initial deployment is keep incremented from one iterative to another until the end of iteration that we called as final deployment. In this step we do project management listed below. Conduct project postmortems. In this step every release in the milestone we try to provide an opportunity for the team to reflect on how previous went. This step according to Kerth [2001] will help enhance future performance. Build training time after the deployment. In this step project manager try to make the team get little nap while in a nap, project manager give a short training and knowledge sharing. Plan contingency buffers. Sometime we face that the milestone is slip. In this case we try to plan buffers that consist of budget and schedules. This approach also known as management buffer. Plan maintenance model. This model is developed by project manager to make changes in a code when the bug is happen. This model provides information about the procedure when client find the bug until updating the system through staging server. This model is updated every iteration of the release plan.

CODING and TESTING

This step basically is parallel step with the design process. When the team creates CRC, they also build spike solution. Spike solution can be considered as coding sessions. Spike solution that provides functionality can be adopted as solution code. This solution code is proved by doing unit testing. Coding sessions is the longest session in one iterative, therefore project management create important role to make the team mental strong, even in tight schedule, a role like manager need to make the team always cheer up and focus. Technical strategist as a people who lead the project management doing two managerial things in this session, the first one is people management, and the second one is team leaderships. People management start by closely estimating the work that based on effort, not calendar time. This means that milestone and other stuff in project

ADOPTING with EXISTING SOFTWARE MANAGEMENT RESEARCH

All the descriptions in the former statements, give us more clear way to construct the management practices in Extreme Programming. The main mantra of simplicity that we found in Extreme Programming leads us to the concept called agile management. This concept lets software project managers and team alike adapt to changing, rather than try to impose rigid formal control, as in traditional linear software development method [Augustine, et al, 2005]. Product based development is different with tailor based software development. The lifecycle of product based

development cant be predicted precisely since the lifecycle of the product is depends on market lifecycle. In stakeholder view this means management become daily activities, and it will be and ideal move if we separated between management and Extreme Programming team. We found a limit in Technical Strategist role as a double agent in this project, since he must handle management, and also have to know technical deep about the product. However in small project size just like we face, the role double agent give some benefit too, the project estimation will become more precise in the term of technical vision, since the manager knows about the technical. Muller, and Padberg [2003] states that the stronger the market pressure, the more important to deliver and receive payment by the customer early, or simply we can said that our product has to reach the market to know the precisely its lifecycle. We think there a good idea to applying Extreme Programming, since Extreme Programming gives us more suitable for delivering incremental release of the product.
DISCUSSION AND FUTURE WORK

San Diego, California, USA. 6. 7. 8. Heldman, K. 2003. Project Management JumpStart. Sybex. USA. Highsmith, J. 2004. Agile Project Management: Creative Innovate Product. Addison-Wesley. USA. Keefe, K., AND Dick, M. 2004. Using Extreme Programming in a Capstone Project. Sixth Australasian Computing Education Conference. Dunedin, Australia. Kerth, N. L. 2001. Project Retrospectives: A Handbook for Team Reviews. Dorset House Publishing. New York

9.

10. McConnell, S. 2006. Software Estimation: Demystifying the Black Art. Microsoft Press. USA. 11. McConnell, Steve. 2004. Code Complete Second Edition. Microsoft Press. Washington. 12. Muller, M.M., AND Padger, F. 2003. On the Economic Evaluation of XP Projects. E SEC/FSE03, September 15, 2003, Helsinki, Finland. 13. Sliger, M., AND Broderick, S. 2008. The Software Project Manager's Bridge to Agility. Addison-Wesley. USA.

We present our experiences applying simple project management practices in extreme programming practices. In this paper we present our 12 simple practices regarding to management steps. These 12 practices are distributed in every step of software constructions, and we recommend adopting it in iterative manners. We also presented some of the current software management research that strongly valuable to us. Our initial experiences in using of the management practices is limitedly in small size product based software. There will be another management complexity that might be faced in tailor based software. Another challenge is adopting these practices in medium or large size software.
ACKNOWLEDGMENTS

We thanks to all student of Electrical Engineering UGM, as well as Microsoft Innovation Center team, who joined and participate in this product development.
REFERENCES

1.

Augustine, S., Payne, B., Scencidiver, F., AND Woodcock, S. 2005. Agile Project Management: Steering from The Edges. COMMUNICATIONSOF THE ACM December 2005/Vol. 48, No. 12. USA. Baca, M. C. 2007. Project Management for Mere Mortals: The Tools, Techniques, Teaming, and Politics of Project Management. Addison-Wesley. USA. Beck, K. 2001. Extreme Programming Explained. Addison-Wesley. Boston. Cockburn, A. 2006. Agile Software Development: The Cooperative Game, Second Edition. Addison-Wesley. USA. Coelho, R., Brasiliero, E., AND Staa Von, A. 2005. Bot So Extreme Programming: Agile Practices for R&D Projects. OOPSLA05, October 1620, 2005,

2.

3. 4.

5.