Enterprise: Agile Project Management Abstract In the study of new ways or methodologies to develop software and manage each

of these projects we encounter various trends, the most important thing to take into account is that we should not apply an specific strategy to each and every project without knowing all the variables that may come with it, including an overall view of the client's preferences, ideas, values, risks, desired results, budget, etc. As seen in the past projects fail all the time but most importantly, are we sure we used the right approach? Project management is the discipline of planning, organizing, securing and managing resources to bring about the successful completion of specific engineering project goals and objectives. It is sometimes conflated with program management, however technically that is actually a higher level construction: a group of related and somehow interdependent engineering projects. A project is a temporary endeavor, having a defined beginning and end (usually constrained by date, but can be by funding or deliverables), undertaken to meet unique goals and objectives, usually to bring about beneficial change or added value. The temporary nature of projects stands in contrast to business as usual (or operations), which are repetitive, permanent or semi-permanent functional work to produce products or services. In practice, the management of these two systems is often found to be quite different, and as such requires the development of distinct technical skills and the adoption of separate management. The primary challenge of project management is to achieve all of the engineering project goals and objectives while honoring the preconceived project constraints. Typical constraints are scope, time, and budget. The secondaryand more ambitiouschallenge is to optimize the allocation and integration of inputs necessary to meet pre-defined objectives. Agile project management takes the ideas from Agile software development and applies them to project management. Agile methodologies generally promote a project management process that encourages stakeholder involvement, feedback, objective metrics and effective controls. Businesses all over continue to struggle implementing the PMBOK or PRINCE2 as a whole or parts of them claiming that they are too complex, too involved and take from the time it takes to produce the project deliverables. Adaptive Project Framework (APF) comes to the rescue by adapting to the ever changing business environments. APF is an iterative and adaptive approach designed to deliver maximum business value to clients within the limits of their time and cost constraints where the always variable scope is adjusted on each iteration. The client decides what constitutes maximum business value and, at the end of each iteration, the client has an opportunity to change the direction of the project based on what was learned from all previous iterations, therefore, embracing and managing change, not avoiding it. APF is defined in five phases: (Adaptive Project Framework: Managing Complexity in the Face of Uncertainty, Wiley
Publishing, 2009)

1. Version Scope Develop the Conditions Of Satisfaction (COS) to define what is needed and what will be done to meet that need. Develop the Project Overview Statement (POS) which summarizes the problem/opportunity, what will be addressed and how, the business value, and risks, assumptions and obstacles to success. Prioritize functional requirements; this list may change but currently reflects the best information available. Develop mid-level Work Breakdown Structure showing goal, major functions, and sub-functions. Prioritize scope triangle (consisting of time, cost, resources, scope, and quality, customer satisfaction was left out).

Andrea Alvarado Uribe

2. Cycle Plan (iterative) Extract from the WBS those activities that define the functionality to be built in this cycle. Decompose the extracted WBS down to the task level. Establish the dependencies among these tasks. Partition the tasks into meaningful groups and assign teams to each group. Each team develops a micro-level schedule with resource allocations for the completion of their tasks within the established cycle timeline and budget constraints.

3. Cycle Build (iterative) Conduct detailed planning for producing the functionality assigned to this cycle. Begin cycle work. Monitor and adjust cycle build. This cycle ends when its time has expired. Any functionality not completed during this cycle is reconsidered as part of the functionality in the next cycle. Create a Scope Bank to record all change requests and ideas for improvements. Create an Issues Log to record all problems and track the status of their resolution. 4. Client Checkpoint (iterative) Client and project team perform a quality review of the functionality produced in the just completed cycle against the overall goal of maximum business value, and adjustments are made to the high-level plan and next cycle work if needed. The sequence Cycle Plan / Cycle Build / Client Checkpoint is repeated until the time and cost budgets for this version have been expended. 5. Post-Version Review Determine if the expected business outcome was realized. Determine what was learned that can be used to improve the solution. Determine what was learned that can be used to improve the effectiveness of APF. The nice thing about Agile Project Management is the prescriptive nature. It serves as a guidebook for how you operate and continually improve your business. Few of us are born with the intrinsic knowledge of how to steer a business, whether a law firm or software company, so a set of rails to follow greatly helps. It's used by thousands of software companies, large and small, internationally, and is supported by books, consultants, conferences, and training events. In the upcoming section of the article it will be described how an specific project can be made through an agile process with all the steps that should be taken into account. Its a Maximum Security Project that will develop software for car theft avoidance and control, which will be compared during all the main features of Agile with its own implementation and how it aligns with the strategy We will go through several key points all the way from management through development and finally to resources and environmental factors. Agile Management Agile Project Management begins with the premise that software projects are unpredictable and that market uncertainty is going to drive change. Market uncertainty implies that requirements will need to change over the life of the project, and the more uncertain the project is, the more the organization should plan to adapt. For these reasons, uncertainty makes scope an inadequate starting point to begin assessing project performance characteristics. Instead, agile development projects elevate time and cost as the primary constraints, which are often established before the scope is dened. Rather than beginning to schedule development with an assessment of project scope, the project stakeholders assess the time and money they are willing to invest to bring a product to market. Agile project requirements are written as thin vertical slices of the overall system and constructed in

Andrea Alvarado Uribe

such a way that they are mostly independent, which allows them to be prioritized and implemented in any order. One of the first mistakes managers make is trying to emulate our development team, who has practiced agile for years and had been working together as a team for a lot longer than we had. We figure that if it works for them, it should work for us. As we mature as a team, we are able to incorporate a lot of their best practices, but it is just too much to bite off all at once. You need to build a solid agile foundation first. The next mistake is trying to use our own tool to manage our projects. We have no problem messaging to prospects that a tool shouldnt magically make them agile, but we arent following a well organized procedure. We get hung up on all the bells and whistles of the tool before having a good handle on the basic agile principles. We have to take a step back, and use whiteboards and sticky notes to manage our first few iterations. We also make the mistake of trying to plan too much into our iterations. We are already behind on almost every project, and we assume that agile methods will immediately make the team more productive. Even though we know better, we dont take into account the drop in productivity that inevitably happens when you change the way you work. When we dont close out most of our stories in an iteration, were setting ourselves to false conclusions. Writing requirements in smaller, stand-alone increments is critical to varying scope with minimal impact to the project team. Agile teams begin to measure how fast they are able to complete thin vertical slices of functionality and therefore understand how much of the requirements can be delivered within the project time and cost constraints. Agile Management Components There are several key elements that provide the basis for APM. These techniques can also be used in traditional software development methods to improve project performance. (Kathleen Hass, The Blending of Traditional and
Agile Project Management)

They are: 1. Visual control. This is a "cards-on-the-wall" method of planning to assist a team in organizing the work of the project. For example, one successful Agile project team placed different color groups of cards that represented the features of the solution on the wall. The features that were designed, developed, tested and in production were one color, the features that were designed, built, tested but not yet put in production (but ready to go) were another color. The team was able to see at a glance where they were with each feature set. Visual control ensures that every member of the team views the project the same way. 2. Co-located high-performing teams. In Agile development, all the key team members are co-located, including the customer/end-user, preferably in a work room. This approach greatly increases the quality of co-ordination and communication. However, this may represent a significant cultural change for IT developers. Since project managers are responsible for building a high performing team, they need to ensure that they have been assigned developers who truly can work in this collaborative manner. 3. Test-driven development. In cases when the customer is having a difficult time articulating requirements, Agile teams often use test-driven development. This requires more iteration between requirements, design, development and test. Agile teams almost always develop test plans at the same time they define requirements; if a requirement isn't testable, then it is not yet fully developed. This is a best practice that can be used in traditional development to ensure requirements are complete, accurate and testable. 4. Adaptive control. Everyone on the team is constantly adapting. Because of this dynamic environment, the project manager needs to be seen as a leader, not a taskmaster. Instead of setting rigid instructions for the team to follow, the project manager facilitates the team in establishing working relationships,

Andrea Alvarado Uribe

setting ground rules and fostering collaboration. Agile team members continuously adapt to improve their methods as they incorporate lessons learned from the previous cycle into the next iteration, also a best practice for any project. 5. Collaborative development. APM relies on collaboration among all team members to deliver results, capture candid feedback and implement lessons learned in the next iteration of the solution. This is one of the strengths of APM constant feedback and improvement. The project manager completes the initial planning and the business analyst defines and prioritizes the solution features in collaboration with the customer and technology representatives. Then the Agile project teams collaborate on the design, development, testing and reworking of each incremental build. It is this constant collaboration with the customer that promotes project success. 6. Feature-driven development. This practice greatly reduces complexity and allows the team to focus on one feature at a time. For example, one team is working on Feature #4 and that's the team's only focus. They don't concern themselves about Features #1-3. It is the business analyst and project manager who ensure the next feature in the backlog is truly the next priority, based on business value and risk. Typically, high-risk components or core infrastructure pieces are built first, and then everything else is prioritized based on business value. The goal is to build the feature-driven components with only a oneway dependency to the core system; therefore, specialized components are independent of each other and can be created in any order or even in parallel. 7. Leadership and collaboration rather than command and control. "The principles of APM are timeless and links closely to leadership. It addresses a lot of the steps that facilitate leadership much more than traditional management," says Sanjiv Augustine, Managing Director of the Lean-Agile Consulting Practice at CC Pace Systems in Fairfax, VA. The project manager works with the client management, the IT management and the key stakeholders to ensure they know the project's status. Additionally, the project manager removes any barriers hindering the core Agile teams. 8. Move focus from C (cost) to R (revenue). Features are prioritized based on value, such as increased revenue or market share. It's the business analyst's role to ensure the Agile project team is not investing too much into the development of the new solution. If so they will have eroded the business case and the project will cost more than the organization will gain. While the project manager focuses on project costs, the business analyst focuses on the total cost of ownership that includes not only the development or acquisition costs of the new solution, but also the cost of operating the system after it is deployed. 9. Lessons learned. After each cycle, the team holds a lessons learned session to determine what they can do better on the next iteration. As the team learns, it adapts how the members are working together to continuously improve team performance. Development The Agile approach consists of many rapid iterative planning and development cycles, allowing a project team to constantly evaluate the evolving product and obtain immediate feedback from users or stakeholders. The team learns and improves the product, as well as their working methods, from each successive cycle. After a streamlined planning, requirements definition and solution design phase is completed to get the project underway, iterations of more detailed planning, requirements, design, build and test take place in waves. This approach allows for immediate modifications of the product as requirements come into view.

Andrea Alvarado Uribe

In our project we used these iterations by dividing the user stories into modules which will be iteration by themselves. Each module has several number of user stories which will be completed by the team members for an established period of time and complete each sprint after a three week period. Ahead you can observe the modules or iterations in the work breakdown structure of our maximum security project:

Andrea Alvarado Uribe

Resources A key agile principle, "individuals and interactions over processes and tools," emphasizes communication and collaboration of project team members. Instead of defining the roles of team members, more importance is given to how well they can perform tasks as a team and create a working version of software. Teamwork cannot be overstated in agile processes, as each member can play the part of the end-user, leader, and engineer. To be truly successful, project managers should allow team members to wear cross-functional hats, communicate freely, and focus on team goals instead of individual, or role-based-functions. Roles and resource play a very important part in agile development. Thye guarantee full availability in every iteration with constant support to the development process. Its indispensable to take in qccount that our resources have agile skills or should develop them. We will need to have security and logistic specialists throughout the project lifecycle as part of our team. This will ensure well develop reauirements and availability to test, evaluate and implement all features needed in the project. The resources used in the Project ar aligned with the concept of small self organized groups as follow: Position Analyst Programmer: in charge of analysis, design, development and testing. Security Specialist: Knows the know-how of the business and vehicular security and logistic details required for the project. We can identify how each of the nine key elements mentioned above used in our project, for example: The team develops the user stories that will be followed during each iteration, these stories will be posted on a wall for the availability of the whole team an as a reminder of the activities to come. Visual control gives the team, a standard idea of what the project is about. Each story will develop a prototype which will be functional so tests are developed prior to each iteration as a metric to establish what sprints should give us at the end of its efforts. This team is constituted by four analysts- programmers which have depth experience in agile programming and a 100% available security expert for the logistic experience part of the project. Even though user stories are already defined we took into account that changes in requirements are almost positive to occur so these stories can and will change and the team is prepared for this. In the image below you can observe how all the team is 100% committed to each story and has to collaborate on the totality of its development, and how modules are divided by each of the features that have to be developed for the project completion. And finally we have lessons learned which are discussed at the end of each sprint and then summarized at the end of the project. 1 8 4 amount 8 hours

Andrea Alvarado Uribe

There are two elements hard to notice in the planning of the project and that can only be measured after part of the development, these are leadership and collaboration instead of command and control (features that can only be noticed during the execution of the project and that will guarantee the failure of it, if not implemented correctly), and moving focus from cost to revenue (its hard to convince stakeholders of this particular element because all business are majorly driven by cost estimations but experience in past projects developed with agile demonstrate how revenues tend to rise in this specific software development methodology). Other important process of agile development is risk management. Risk management is an activity directed towards assessing, mitigating and monitoring of risks. Many Agilists believe that the process of risk management for Agile projects is not significantly different from the traditional projects. Though the process might be a bit lighter in Agile, however, the steps of finding, sifting, sorting and creating resolution plans for risks remains close to traditional projects. According to Mike Cottmeyer author of Agile methodologies are better, Agile is so effective at managing risk because risk management processes are built into the very fabric of how we run the project. There is an implicit understanding that risk is everywhere on a project. Risk cannot be contained in a risk list. Risk cannot be mitigated in a team meeting or a periodic risk review session. Dealing with risk has to be an

Andrea Alvarado Uribe

obsession. Our mitigation strategies dont live outside the project, but influence the very nature of how we structure and plan our work. If we take this idea and visualize it in our project, right on we will notice how sprints give us the opportunity to constantly look up for risks, or manage them throughout each situation without losing track of them. We can classify them into three categories: Business Risk Deals with delivery of the project with the promised business value. Technical Risk Deals with the feasibility of a technical solution within the time and cost constraints. Logistical Risk Deals with assumptions regarding people and infrastructure.

Conclusions The lack of guidance for project managers of agile development projects has been a gaping hole in the software development community over the past several years. The contrast between the world of agile software development and traditional project management has left many managers wondering what their role should be. By viewing the agile development team as a complex adaptive system and the manager as an integral part of that system, we have begun to develop a framework for managers. This framework of practices is meant to overlay the practices of existing agile methodologies such as XP, and provide clear guidelines for the visionary leadership of projects that use them. These key practices of agile project management do not provide a sure-fire recipe for success. Building and nurturing a successful team is much more like cooking chili than baking a cake it requires creativity, flexibility, and attentiveness to the unique qualities and interactions of the ingredients. However, we believe that by following these basic practices and adapting them to your own style over time, managers will not only find that they add tremendous value to projects but also that they will enjoy not only the achievement of success but the journey along the way. In each of these instances, the action of each manager is very important to the success of the project. All of these actions required intelligence and initiative. However, some are natural responses to project events made visible by Agile. Some of the best experiences we can gain from Agile are that exciting product visions guides us to reliable innovations. Also the comparison from project managers that bring out the best in their team rather than managers that bring out the worst in Gantt charts, demonstrate the belief that people are more important than the process. In our project example we noticed how difficult its to ensemble a team of agile driven members and how planning is also exhausting and thorough which gives us the foundations to develop an outstanding project when

Andrea Alvarado Uribe

all the elements are taken into account, revised and balanced. We are sure that this example can guide you through a much easier path for a well implemented Agile Software Development Project. Bibliography http://www.projectsmart.co.uk/the-blending-of-traditional-and-agile-project-management.html http://en.wikipedia.org/wiki/Agile_Project_Management ExecutiveBrief, Which Life Cycle Is Best For Your Project?, PM Hut. Accessed 23. Oct 2009. Jim Highsmith, Agile Project Management: Creating Innovative Products (2nd Edition) Ken Sqchwaber, Agile Project Management with Scrum Sanjiv Augustine, Managing Agile Projects Agile Project Leadership Network (APLN) Agile Project Leadership Network}'s [http://pmdoi.org/ Declaration of Interdependence Agile Manifesto

Andrea Alvarado Uribe