Agile project management

Abstract

” Agility means the ability to balance between flexibility and stability.” The 21st Century's market and business environment is more turbulent, unstable and full of tension than any other time and in view of investors unpredictable and dangerous. In this new century, the emergence and development of technological ideas and designs in the form of commercial products will not give you enough time to manage affairs and projects in a traditional way and you need to be more agile, in order to ensure the growth, development, continuation and survival of your business in competition with leading companies in various industries. Along with the evolution of various branches of industry and technology, project management as one of the most common ways of delivering products and doing services has undergone dramatic changes. Increasing pressures and stress caused, the speed of production of other companies, development and transfer of information, as well as increasing participation of customers and their more emphasis on various aspects of project outputs, have led project managers and custodians to seek more agile and aggressive approaches to project management. So that, in addition to obtaining customer’s satisfaction and other project stakeholders, they can make proper decisions and take actions as soon as possible . These developments have been so wide spread and universal in the last two decades that agile management has completely replaced traditional and waterfall approaches in managing many projects in industries and especially in Hi-Tech industries.

Agile is a way to manage projects which can be used for virtually anything, but it was founded in software development. Agile breaks down larger projects into small, manageable chunks called iterations. At the end of each iteration (which generally takes place over a consistent time interval) something of value is produced. The product produced during each iteration should be able to be put into the world to gain feedback from users or stakeholders. agile has designers, developers and business people working together simultaneously. .

Big idea

Agile project management, was first discussed in depth in the 1970s by Software developers is a style of project management that focuses on early delivery of business value, continuous improvement of the project’s product and processes, scope flexibility, team input, and delivering well tested products that reflect customer needs. Although agile approaches have roots in software development, you can use them for other types of products. In February 2001, a group of 17 software and project experts got together to discuss about their experiences, ideas and to suggest ways to improve the world of software development. This group created the Agile Manifesto which is an expression of core development values and 12 Principles behind it which help support the values in the Agile Manifesto and support agile project teams in implementing agile techniques and staying on track.

The text of the original 12 principles by the Agile Alliance is:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the Project.
5. Build projects around motivated individuals Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
11. The best architectures, requirements, and designs emerge from self-organizing Teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Therefore according to these 12 principles, agile methods focus on customer satisfaction, quality in every product, teamwork and project management.

Comparing historical project management with APM

Historical Project Management compare to Agile Project Management:

Since Agile approach is now being increasingly adopted by companies worldwide for software development, The traditional methods is rapidly losing its popularity.

Here is some differences between historical and agile approach to the project management task:

1. In agile project management we need to Create a product backlog as a simple list of requirements by priority . Quickly update the product backlog as requirements and priorities change overall the project in case in historical Project Management, a fully detailed project requirement document need to be created at the beginning of the project and trying to control requirement changes throughout the project.
2. In agile project management the development team meets quickly, at the start of each day, for no longer than 15 minutes, to coordinate and synchronize that day’s work and any roadblocks, in case in in historical Project Management weekly status meetings, conduct with all project stakeholders and developers. Send out detailed meeting notes and status reports after each meeting.
3. In agile project management, works is within sprints and identify only specific tasks for the active sprint, in case in historical Project Management a detailed project schedule with all tasks should be created at the beginning of the project and the project manager tries to keep the project tasks on schedule and Updates the schedule on a regular basis.
4. In agile project management, the development team should be Supported by helping remove impediments and distractions. In this approach, development teams define and pull their own tasks, in case in historical Project Management, tasks should be assigned to the development team.
5. Creating products is a long procedure and there are some factors lead up to have great products. Chang is one of the most important and valuable tools to reach these great products. Product users can be respond as soon as possible by project teams and the market are able to expand relevant, helpful products that people want to use. In agile project management, changes accommodate systematically. The flexibility of agile approaches is very useful and could increases project stability because changes in an agile project make it, predictable and manageable, by contrast, Unfortunately, in historical project management methods, change how they manage procedures and budget structures that can’t modify new product requirements make changes difficult. Therefore, sometimes we can see negative affects appear, for instance historical project teams often find themselves blindly following a plan and it can cause missing opportunities to construct more valuable products.

Application

Agile approaches are based on an empirical control method. This approach helps making decisions based on the realities observed in the project. In the context of software development methodologies, an empirical approach can be effective in both new product development and enhancement and upgrade projects. You can make immediate adjustments, by using frequent and firsthand inspection of the work to date, if necessary. Agile projects work in iterations (smaller segments of the whole project), to accommodate frequent inspection and immediate adaptation. This approach, involves the same type of work as in a traditional waterfall project: You create requirements and designs, develop the product, document it, and if necessary, integrate the product with other products. You test the product, fix any problems, and deploy it for use. However, instead of completing these steps for all product features at once, as in a waterfall project, you break the project into iterations, also called sprints. Since the creators of the Agile Manifesto worked in the IT industry, they originally focused on software development. . However, extension of agile project management techniques, has gone beyond software development and even outside computer related products. Today, agile approaches are used by project management to create products in a variety of industries, including manufacturing, biotech, engineering, marketing, aerospace, nonprofit work, and even building construction. If you want early empirical feedback on the product or service you’re providing, agile methods can help you.

Agile Planning

Planning happens at a number of points in an agile project. A great way to look at the planning activities in agile projects is with the Road map to Value. Following figure shows the roadmap as a whole.

Stages of agile planning and execution with the Roadmap to Value.. Adapted from

-In stage 1, the product owner identifies the product vision. The product vision is your project’s destination or end goal. The product vision includes the outer boundary of what your product will be, how the product is different from the competition, how the product will support your company or organization’s strategy, who will use the product, and why people will use the product. On longer projects, revisit the product vision at least once a year.

-In stage 2, the product owner creates a product road map. The product road map is a high-level view of the product requirements, with a general time frame for when you will develop those requirements. It also gives context to the vision by showing the tangible features that will be produced during the project. Identifying product requirements and then prioritizing and roughly estimating the effort for those requirements allow you to establish requirement themes and identify requirement gaps. The product owner, with support from the development team, should revise the product road map at least biannually.

-In stage 3, the product owner creates a release plan. The release plan identifies a high-level timetable for the release of working functionality to the customer. The release serves as a mid-term boundary against which the scrum team can mobilize. An agile project will have many releases, with the highest-priority features appearing first. You create a release plan at the beginning of each release, which is usually at least quarterly.

-In stage 4, the product owner, the development team, and the scrum master will plan iterations, also called sprints, and start creating the product functionality in those sprints. Sprint planning sessions take place at the start of each sprint. During sprint planning, the scrum team determines a sprint goal, which establishes the immediate boundary of work that the team forecasts to accomplish during the sprint, with requirements that support the goal and can be completed in the sprint. The scrum team also outlines how to complete those requirements.

-In stage 5, the development team has daily scrum meetings during each sprint to coordinate the day’s priorities. In the daily scrum meeting, you discuss what you completed yesterday, what you will work on today, and any roadblocks you have, so that you can address issues immediately.

-In stage 6, the scrum team holds a sprint review at the end of every sprint. In the sprint review, you demonstrate the working functionality to the product stakeholders.

-In stage 7, the scrum team holds a sprint retrospective. The sprint retrospective is a meeting where the scrum team discusses the completed sprint with regard to their processes and environment, and makes plans for process improvements in the next sprint. Like the sprint review for inspecting and adapting the product, a sprint retrospective is held at the end of every sprint to inspect and adapt your processes and environment. Each stage in the Road map to Value is repeatable, and each stage contains planning activities.

Control schedule in agile approach

In agile approach control schedule is concerned with:

• Determining the current status of the project schedule by comparing the total amount of work delivered and accepted against the estimates of work completed for the elapsed time cycle.
• Conducting retrospective reviews (scheduled reviews to record lessons learned) for correcting processes and improving, if required,
• Re-prioritizing the remaining work plan (backlog),
• Determining the rate at which the deliverable are produced, validated, and accepted (velocity) in given time per iteration (agreed work cycle duration, typically two weeks or one month),
• Determining that the project schedule has changed, and
• Managing the actual changes as they occur.

Common agile techniques

Common agile techniques used:

SCRUM

alt text

This model known for agile project management that uses fixed-length repetition of work, which is named sprints.

The four ceremonies of scrum that bring structure to each sprint are :

• Sprint Planning: It is a planning meeting that specify for a team what to do in the coming sprint.
• Sprint Demo: A meeting that team share what they've shipped in that sprint.
• Daily Stand-up: Also named stand-up is a definition for 15-minute mini-meeting for the software team to sync.
• Retrospective: A revising of what did and didn't go well with actions to help make the next sprint better..

Kanban

alt text

Kanban is a framework for agile project management that adjust the work to the team's capacity. It's concentrate on everything carry out as soon as possible, providing teams the ability to respond to change even faster than scrum.

The Kanban framework includes the following four components:

• List of work (or stories): List of work, or stories, are defined as issues or tasks that need to get done.
• Columns or lanes: Used on a Kanban board to specify tasks from different work streams, users, projects, etc.
• Work in Progress Limits (WIP): This is a rule to confine the amount of work to be done according to the team's capacity.
• Continuous Releases: The team works on the number of stories within the WIP limit and can release at any time.

DSDM

DSDM stands for Dynamic Systems Development Method, and it’s an Agile method. The DSDM Consortium published the first version of DSDM in 1994; around the same time as XP and Scrum. DSDM has been designed to be compatible with generic project management methods, especially PRINCE2®. That makes DSDM different from lightweight frameworks like Scrum. The DSDM Agile Project is a Framework that covers a large area of activities across the entire project lifecycle and contain strong foundations and governance, which separated from some other Agile methods. The DSDM Agile Project Framework is an iterative and incremental approach that accept principles of Agile development, including continuous user/customer involvement..

XP

XP is initial for Extreme Programming which is an agile software development method and its main goal is to produce higher quality software, and superior quality of life for the development team. XP is the most particular of the agile frameworks regarding sutible engineering practices for software development.. As Extreme Programming concentrate on customer satisfaction its mention as a successful method. Instead of delivering everything you could possibly want on some date far in the future this process delivers the software you need as you need it. Teamwork is one of the most emphasizing part of Extreme Programming. Managers, customers, and developers are all equal components in a cooperative team. Extreme Programming implements a simple, yet effective environment enabling teams to become highly productive. The team self-organizes around the problem to solve it as efficiently as possible..

Limitation

As we have learned about Agile project management in this article, it has strong advantages but it’s important to know the limitations and risks it brings: Lacking of enough documentation for the system cause that Agile methodologies consider as a not suitable system for maintenance and its one of the first limitation known for Agile methodology. In the other hand documentation is not the fact of matter for programmer and developer when they use Agile Methodology because the main goal for them is to write software. Every system needs users for being alive and like some other system Agile Methodology is heavily depend on the user involvement and this could mention as another limitation for system. And this is Krysta clear that collaboration and connection between users can provide the success of system. There is also another limitation for Agile Methodology, which is concentrate work quality on the skills and behaviors of the developers. Generally designing of modules and submodules are constructed by single developer because they concentrate on building system that solve a particular problem not the general one. Basically, for the small group between 3 and 9 members Agile Methodology can be the best choice but unfortunately it not works well for teams with large number of members. .

Annotated bibliography

1. Emerson Taymor. Agile Handbook. [ONLINE] Available at: "http://agilehandbook.com/agile-handbook.pdf: This handbook is a quick-starter and an overview of the framework for Agile Project.
2. Mark C. Layton and Steven J Ostermiller, "Agile Project Management For Dummies®, 2nd Edition", 2017 : This book beside an introduction to agile practices and methodologies help you also discover the steps to execute agile techniques on a project. The materials in this book, give you the tools and information you need to be successful with agile processes in the project management.
3. Project Management Institute,"A Guide to Project Management Body of Knowledge", (5th Edition),2013 : This book is a set of standard and guidelines for project management which can be used in different methodologies and tools (e.g., agile, waterfall, PRINCE2) to implement the project management framework.