Extreme project management

Extreme project management (XPM) refers to a method of managing very complex and very uncertain projects.
Extreme project management differs from traditional project management mainly in its open, elastic and undeterministic approach. The main focus of XPM is on the human side of project management (e.g. managing project stakeholders), rather than on intricate scheduling techniques and heavy formalism.
Extreme project management corresponds to extreme programming.
Advanced approaches to extreme project management utilize the principles of human interaction management to deal with the complexities of human collaboration.

Contents

[hide]

Introduction

Software project management is a sub-discipline of project management in which software projects are planned, monitored and controlled. Extreme Project Management (XPM) is an agile approach for managing project where the focus is on incremental planning instead of traditional one-time planning. It consists of a series of practices which help managers to control project schedules, assign work tasks, and assure that work is done efficiently and correctly.
XPM is based on agile software development model called Extreme Programming (XP). XP was developed fairly recently in response to problems that plagued other software development processes.

Extreme Programming and Agile

Agile software development is a set of methodologies based on iterative development approach where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. XP is one of the methodologies from the agile methods. Although developed fairly recently, XP has already attracted a large following of software developers, managers and customers. Its appeal for them: it works better than traditional software delivery methods.
XP is team-oriented and customer-focused, where teams range in size from small to medium with the customer as an integral part of the team. It insures that the customer’s need are addressed through out the development process and XP practices help the team determine and deliver exactly what the customer wants, even if the requirements change over time. Main features of XP are simplicity, communication, feedback, gradual development and commitment.

XPM Practices

Since project management deals with planning as well as with monitoring and control, XPM follows suit. XPM practices can be divided into two types: planning practices and control practices. Planning practices consist of the Release Plan, Weekly Plan, and Stories. The rest of the practices focus on quality control and are used daily.

XPM Planning

Simplicity is one major feature of XP, and in XPM it is the biggest concern. XPM planning practices are simple. There is no need for critical path methods or project management software. Everything can be done by using very common software for example text editors and spread sheets.
Main activities of XPM planning are as follow:
  • Create a Release Plan
  • Create Weekly Plan based on the Release Plan (weekly plans)
  • Allocate Daily Tasks based on the Weekly Plan

Release Plan

Release Plan is the first artefact for XPM. It describes all the work to be done for the current project phase. It is usually created by the project manager, aided by team members, before work begins. Each work phase have a separate Release Plan for example release plan for schematics, design development, contract documents, etc.
XPM Release Plan contains the following activities:
  • Identify all the tasks required to complete the work.
  • For each task, write a brief description on an index card.
  • Estimate the time required to complete a task and add it to the card.
Release plan is a stack of all the index cards. When all the tasks are written on the index cards and time estimation is done, the release plan is ready for use. The major concern is identifying tasks and estimating time for each task. Since this model is based on simplicity and follows the agile approach. Therefore the tasks should be defined in a way that no task should be more than 3 days long and time estimation should be done in ideal hours, number of hours to complete the task without interruption. Longer tasks should be divided into smaller tasks and insuring that all tasks are correct and complete. Description for the task should also be brief and it should focus on what to do instead of how to do it.
The Release Plan can and probably will change during the course of the project. Time estimates are not fixed either. They probably will be modified by the team members during weekly planning meetings.

Weekly Planning Meeting

The Weekly Planning Meeting is an integral part of the XPM planning process. The purpose of the meeting is to assign the week's tasks. All team members attend. It is important that the time interval between meetings be consistent. Meetings should be held weekly, at the same day, time, and place each week.
Prior to the meeting, the project manager selects tasks for the week. Task cards for work remaining are usually arranged on a table in stacks, by priority or by weeks. The PM goes through the stacks, chooses the highest priority tasks, and brings them into the meeting. The number of tasks selected should be based on the prior week's work efforts that are known as velocity in XPM.

Stakeholder Management

Stakeholders have an important role in XPM. Each stakeholder see different side of the project, so it is necessary to brought them together in order to understand the complete view of the project. Similar to Rapid Application Development (RAD), XPM applies a concept called Rapid Planning (RAP) for producing project plans.
The aim of RAP sessions is to identify the requirements and other important issues needed for the project. Stakeholders will be invited by the project manager for the RAP sessions to progress through a sequence of steps that includes planning the project in an intensive and participative process. RAP provides the mechanism where the conflict between stakeholders can be recognized and resolved before the project continues. The RAP session helps the stakeholders to put forth the disagreements on the table for further discussion. Project Manager supposed to finalize the goals and it is important to agree upon the scope and goals of the project among the stakeholders.
XPM applies five tools during RAP process. This helps to bring transparency and ownership for the stakeholders. Normally RAP process must have full participation by stakeholders. The tools are
  • Success sliders: This technique identifies the expectations of the stakeholders. Meeting stakeholder expectations will be satisfying different criteria which includes making the stakeholders satisfied, Achieving functional requirements, meeting budget and deadlines, ensuring value and quality and making the team members satisfied.
  • The O3 model: This techniques helps to model and realize benefits for projects. The model is based on three elements: objectives, outputs and outcomes, which create the project value chain.
  • Quality agreements: The process of software quality planning is about finding out what the required quality is and what processes are to be present during the development process to ensure this quality.
  • Project or partnership agreements: The risks which will delay the project need to be identified at early stages. To be able to foresee these events to happen, the project manager should prepare a document stating the services required by stakeholders and related project managers.
  • Event/real-time planning: This includes identifying major events and scenarios that could be involved in delivering the project. The important issue to remember when doing this kind of planning is that only the tasks involved in achieving the specific event are detailed and scheduled.

Velocity

Velocity is the number of points (ideal hours) completed by the team per week. The idea behind velocity is simple: If a team did “X” hours last week, it will do “X” hours this week as well. The idea of velocity is important to control and monitor the performance of the team. However there are some challenges involved in it. Estimating the time for a task should be consistent and should consider the difficulty of tasks for a real estimation. If the velocity remains constant through out the project, it reflects that the team is performing in ideal situation. If this is not the case then there might be a problem with time estimations, task allocation of team efforts. Therefore velocity helps finding the problem area and to resolve it.

Weekly Tasks

Weekly tasks will be allocated in weekly meetings. Manager will select the tasks from the Release plan based on their priority and/or their dependency on other relevant task. Manager should have enough tasks for the whole team for a week. Each card is discussed within the team, time estimates are revised and tasks are reorganized. Tasks are further divided into sub task so that no task should be more than 8 hours work efforts. Requirements are clarified. After that each person from the team selects the task and signs the index card against ones name. When the task is complete, time estimate will be updated and the card is put to the “Done” pile of release plan.

Stand-Up Meetings

Stand up meetings are held frequently to facilitate communication and keep team members informed.
  • Daily Stand-Ups: Start each day with a short stand-up meeting. Each team member describes work on current task, identifies potential problems.
  • Ad-Hoc Stand Ups: Anyone can call for a stand-up to discuss a pressing issue.

Stories

A user story is a sub set of functionality (also known as feature) that is of value to the customer. It provides a simple way for developers and customers to chop up what the system needs to do so the system can be delivered in pieces.
The emphasis on the word simple is essential. Since it is an agile approach so there is no need for a detailed requirement engineering process, however some of the RE practices can be adopted. XP looks for the simplest approach that could possibly work. A story actually describes the functionality required by the customer. It might refer to a change in the existing functionality, additional requirement or extended requirements.

Testing

Testing in XPM is different from traditional test plans and practices. In XPM testing is an essential part of process and one have to test everything that probably could break. Each task is tested and verified and tests should be automated so that it can be performed later if there is a change. Testing is usually performed with two aspects, correctness and completeness of the task. Both aspects assure that all the tasks work properly and the system has all the functionality required by the customer. Project tests are created by the manager and assisted by the team to assure that the goals of the project are met. In XP, tests are written first and then the code is written to pass the test. Peer reviews are common to verify the correctness and completeness of the tasks.

A “coach” for extreme team is a really good idea

The manager’s role is one of great importance and responsibility in software projects. With the advent of Agile methodologies, this role has undergone drastic changes. XP has the Coach; other mixed methods and home-rolled versions of Agile have different definitions of the manager’s role
First and foremost, in principle, project management is usually divided up in project planning for projects which are not started yet and project controlling and management, respectively, for running projects.
Naturally, project management can just be as good as the person who is responsible for it, i.e. the project manager. However, a project manager of an XP project is not simply a project coordinator and supervisor in the well-known context. On the one hand he or she must be less than that, as responsibility is largely shifted to the team members: on the other hand he or she must be more than that, namely an excellent moderator.
Project Manager has to support the programmers in a way that problems can be solved by themselves, i.e. by team work. Though the Project Manager has a strategic position within the project he or she also gives know-how to the project members. However, know-how in this context equally means strategic, technical and application know-how. The larger the project the less likely it is that the moderator will program himself and therefore has not to be a good programmer. The Project Manager in XPM must be like an obstetrician so that complex ideas can be born, formulated, cut into components for the subprojects and realized. Finally, he or she takes care that the potential of each project member can be exhausted in an optimal way. Altogether, the Project Manager supports the team in questions of method, motivation, communication, and cooperation. The project manager would typically sign up for tracking, the status and report.

Managing extreme environment

Give the Team a Dedicated Open Work Space

Communication is very important to an Extreme Programming (XP) team. Putting computers in a central area that no one owns makes pair programming easier and encourages people to work together with feelings of equal value and contributions. Putting a few desks around the perimeter gives people a place to work alone without becoming disconnected from the rest of the team.
Including a large area for daily stand up meetings keeps people from missing the meeting. Adding a conference table gives the group a home for group discussions that occur spontaneously throughout the day. Being able to see the discussions encourages people to listen in or join the discussion when they have a stake in the out come.
Adding white boards for design sketches and important notes or blank walls where user story cards can be taped adds even more channels for communication. Posting a couple large charts targeting process improvement or project progress informs the team without management hounding them about progress.

Set a Sustainable, Measurable, Predictable Pace

To set pace extreme project manager needs to take iteration ends seriously. Manager wants the most completed, tested, integrated, production ready software. If it looks like manager will not be able to get everything finished by iteration end have an iteration planning meeting and re-scope the iteration to maximize project velocity.
Working overtime delimits the spirit and motivation out of team. When team becomes tired and demoralized they will get less work done, not more, no matter how many hours are worked. Becoming over worked today steals development progress from the future. Realistic plans can't make when team does more.
Becoming over worked today steals development progress from the future. Manager can not make realistic plans when team does more work this month and less next month. Instead of pushing people to do more than humanly possible use a release planning meeting to change the project scope or timing.
Adding more people is also a bad idea when a project is already late. The contribution made by many new people is usually negative. Instead ramp up development team slowly well in advance, as soon as you predict a release will be too late.
A sustainable pace helps manager to plan releases and iterations and keeps from getting into a death march. Manager needs to find his or her team's perfect velocity that will remain consistent for the entire project. Every team is different. Demanding this team increase velocity to match that team will actually lower their velocity long term. So what ever team's velocity is manager just accepts it, guards it, and uses it to make realistic plans

Daily Stand Up Meeting

At a typical project meeting most attendees do not contribute, but attend just to hear the outcome. A large amount of developer time is wasted to gain a trivial amount of communication. Having many people attend every meeting drains resources from the project and also creates a scheduling nightmare.
Communication among the entire team is the purpose of the stand up meeting. A stand up meeting every morning is used to communicate problems, solutions, and promote team focus. Everyone stands up in a circle to avoid long discussions. It is more efficient to have one short meeting that every one is required to attend than many meetings with a few developers each.
When you have daily stand up meetings any other meeting's attendance can be based on who will actually be needed and will contribute. Now it is possible to avoid even scheduling most meetings. With limited attendance most meetings can take place spontaneously in front of a computer, where code can be browsed and ideas actually tried out.
During a stand up meeting developers report at least three things; what was accomplished yesterday, what will be attempted today, and what problems are causing delays. The daily stand up meeting is not another meeting to waste people's time. It will replace many other meetings giving a net savings several times its own length.

Project Velocity

The project velocity (or just velocity) is a measure of how much work is getting done on project. To measure the project velocity manager simply add up the estimates of the user stories that were finished during the iteration. Manager also total up the estimates for the tasks finished during the iteration. Both of these measurements are used for iteration planning.
During the iteration planning meeting customers are allowed to choose the same number of user stories equal to the project velocity measured in the previous iteration. Those stories are broken down into technical tasks and the team is allowed to sign up for the same number of tasks equal to the previous iteration's project velocity.
This simple mechanism allows developers to recover and clean up after a difficult iteration and averages out estimates. Project velocity goes up by allowing developers to ask the customers for another story when their work is completed early and no clean up tasks remain.
A few ups and downs in project velocity are expected. Manager should use a release planning meeting to re-estimate and re-negotiate the release plan if project velocity changes dramatically for more than one iteration. Expect the project velocity to change again when the system is put into production due to maintenance tasks.
Project velocity is about as detailed a measure as project manager can make that will be accurate. Managers don't need dividing the project velocity by the length of the iteration or the number of people. This number isn't any good to compare two project's productivity. Each project team will have a different bias to estimating stories and tasks, some estimate high, some estimate low. It doesn't matter in the long run. Tracking the total amount of work done during each iteration is the key to keeping the project moving at a steady predictable pace.
The problem with any project is the initial estimate. Collecting lots of details does not make your initial estimate anything other than a guess. Worry about estimating the overall scope of the project and get that right instead of creating large documents. Consider spending the time you would have invested into creating a detailed specification on actually doing a couple iterations of development. Measure the project velocity during these initial explorations and make a much better guess at the project's total size.

Move People Around

Move people around to avoid serious knowledge loss and coding bottle necks. If only one person on a team can work in a given area and that person leaves or just has too much to do, manager will find the project's progress reduced to a crawl.
Cross training is often an important consideration in companies trying to avoid islands of knowledge, which are so susceptible to loss. Moving people around the code base in combination with pair programming does cross training for team. Instead of one person who knows everything about a given section of code, everyone on the team knows much of the code in each section.
A team is much more flexible if everyone knows enough about every part of the system to work on it. Instead of having a few people overloaded with work while other team members have little to do, the whole team can be productive. Any number of developers can be assigned to the hottest part of the system. Flexible load balancing of this type is a manager's dream come true.
Mangers need to compose the team to have everyone they need to be successful. Cross functional teams can be left alone to become self organizing and self disciplined. If some specialized expertise is needed add a specialist to the team for a week and let many of your team members interact with the specialist.
Simply encourage everyone to try working on a new section of the system at least part of each iteration. Pair programming makes it possible without losing productivity and ensures continuity of thought. One person from a pair can be swapped out while the other continues with a new partner if desired.

Extreme Project and Risk

The development of software systems is a risky endeavor that usually encompasses constraints of schedule and budget. Several methodologies are proposed to remedy the problems encountered in traditional development methodologies used in software engineering. Currently, extreme programming is considered as the most famous and prominent agile methodology which is based on twelve best practices of which the following are core practices: Customer On Site, Planning Game, collective Code Ownership, Simple Design. The risk factors that might occur if the Customer is not On Site include changing requirements, cost of communication, decisions not forthcoming, difficulty in communication and incomplete requirements. Similarly, the risk factors that might occur if the Planning Game is not applied include changing priority and bad fit to schedule. The risk elements that might occur if the Code Ownership practice is not applied include architectural degeneration. Also, the risk factors that might occur if the Simple Design practice is not applied include changing requirements.

Risk Management

The success of project is based on stakeholder satisfaction, schedule, scope, quality, budget, return on investment and team satisfaction. And Risk management does follow two rules on these areas: (1) Recognize the real need and (2) Respond appropriately. In sum, recognizing the real need would have been to:
  • Place Stakeholder Satisfaction as a "Must Meet" condition. Everything would have been in vain if Stakeholder Satisfaction were not met at some predefined measure of success. Put another way, if all other conditions were met and Stakeholder Satisfaction was not, the project would be considered as having woefully missed the mark.
  • Optimize Schedule to respond to risk appropriately
  • Keep Resources, Scope, Quality, ROI, and Team Satisfaction within acceptable tolerances. (In absence of Schedule, they appeared to be optimizing Scope and/or Quality.)

Books

  • Ajani, Shaun H. Extreme Project Management: Unique Methodologies - Resolute Principles - Astounding Results.
  • Doug DeCarlo eXtreme Project Management: Using Leadership and Tools to Deliver Value in the Face of Volatility
  • Craig Larman Agile and Iterative Development: A Manager's Guide
  • Ken Schwaber Agile Project Management with Scrum (Microsoft Professional)
  • Ken Schwaber, Mike Beedle Agile Software Development with SCRUM
  • Mary Poppendieck, Tom Poppendieck Lean Software Development: An Agile Toolkit for Software Development Managers
  • Mike Cohn Agile Estimating and Planning (Robert C. Martin Series
  • Highsmith, Jim. Agile Project Management: Creating Innovative Products.
  • Thomsett, Rob. Radical Project Management.
  • Wysocki, Robert K., Rudd McGary. Effective Project Management: Traditional, Adaptive, Extreme
  • Harrison-Broninski, Keith. Human Interactions: The Heart and Soul of Business Process Management.

Literature

  • Bernhard Rumpe and Peter Scholz (2003). Scaling The Management Of Extreme Programming Projects. Projects & Profits. Special Issue on Management of Extreme Programming Projects, Vol. III (8), pp. 11-18. ICFAI Press, Hyderabat. 
  • Rashina Hoda, James Noble, Stuart Marshall. Exploring the Role of the Manager in Agile Projects. 
  • Houda Zouari Ounaies1, Yassine Jamoussi2, Mohamed Ben Ahmed3 (2006). Project Management Improvement in Extreme Programming. RPM-AEMES, VOL. 3, No 1. 
  • Orit Hazzan and Yael Dubinsky. Clashes between Culture and Software Development Methods: The Case of the Israeli Hi-Tech Industry and Extreme Programming. 
Orit Hazzan and Jim Tomayko. Human Aspects of Software Engineering: The Case of Extreme Programming.

Share this post!

Bookmark and Share

0 comments:

Post a Comment