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.

Big idea

I want to start my discussion with an example to make it much clear.:

Let’s say, you are working in a company and you have your own piece of software for your business as usual and you are earning money using it. There is a business section in your company as sales, marketing and IT department that adds new feature to the existing software and maybe creates new pieces of software or maintaining and something like that. One day, one of the staff from the business section comes to you and says that they need something new. They want to start a new project to create for example a mobile application to increase sales in a way. First you do not know exactly what they want and how you would proceed with it. What would you do? The commonest way for the technical and management staff is to start a conversation with the business people, to ask them questions about what they have in mind, the needs and something like that. We keep doing that until we have a complete understanding of their expectations and when we are sure that we know their expectations, then we consider a product that can meet those expectations. Now we have the product and we create a plan that can help us create that product. Then we start the project and throughout the project, our goal is to follow the plan. Because that is probably, the best way we can realize that product. You usually have some deviations that it is completely normal and is ok. you have to have a monitoring and controlling system to understand the deviations and remove them and get back on track. After a while you get to the end and create a product as it was planned and designed upfront. You will show it to the business people. in certain cases, in some projects, when you do that, you realize the expectations for something else that you could not understand the expectations before

It does not happen in every project. When you want to construct a building or when you want to build a bridge, you can understand the expectation from the beginning and then plan everything and create the product and everyone will be happy. But in some projects, such as IT development, it does not usually happen. Cases are different. As it is very common, how can we prevent it from happening? how can we solve this problem?. At the beginning of the project, you don’t know enough about the expectations of the customer. But instead of trying to make it precise in the beginning, you just go on with the project. In a short period of time you think about different ways of approaching the project and you pick one that seems to be the best, the one that you believe will bring those closest to the expectations as you know them. So, you run the project for a couple of weeks, create a small piece of product and show it to the customer. The fact is that you realize that maybe the only thing that is in common between technical people and business people is the product and that is the only way you can really understand each other. In this approach you will have multiple products during the project. So,you spend a few weeks and you create a very small piece of product. you show what you have worked on to the customer or the business side and receive their feedback. Using that feedback and new understanding you have from the way the business works within a small piece of product ,you have better understanding of the expectations. So you can take the next step, using the new understanding you will think about different alternatives, pick one that seems to be the best , create the second version of the product, show it to the customer again, receive more feedback and you go on like this,until you realize all the expectations. this approach is called adaptive,because you go on and let the environment help you adapt yourself and find your way through the project. So one common problem is that people think in adaptive approaches you just go on with the project and you don’t care about planning or designing or anything else. no, that is not the case. There is a special approach that helps you use the environment to find your way. So, this approach is what we call agile.

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. According to these12 principles, agile methods focus on customer satisfaction, quality in every product, teamwork and project management

In a comparison, we can see the differences between Agile Project Management and Historical Project Management :

1. In agile project management we need to create a product backlog in terms of priority and importance, quickly update the product backlog as requirements and priorities change, whereas in Historical Project Management we must create a complete list of project requirement document at the beginning of the project and all changes must be controlled.
2. In agile project management the development team convene quickly, at the start of each day, for no longer than 15 minutes, to coordinate and synchronize that day’s work and any obstacles, whereas in Historical Project Management weekly status meetings, conduct with all project stakeholders and developers. After each meeting, they send out detailed meeting notes and status reports.
3. In Historical Project Management, at the beginning of the project a detailed project schedule with all tasks should be created and the project manager tries to keep the project tasks on schedule and updates the schedule on a regular basis, whereas in agile project management, specific tasks identify for the active sprint.
4. In agile project management, the development team should be supported by helping it remove impediments. In this way, development teams define their own tasks, whereas in Historical Project Management, tasks should be assigned to the development team.
5. In order to produce products, we have to go through a long way. in this path there is some factors lead us to produce great products. Making Changes is one of the most important and valuable factors to achieve these great products. End-users can be provided by project teams and the market is able to supply relevant, useful products that people need. In agile project management, changes are adopted systematically. The flexibility of Agile system is very helpful and can increase project ability because ‘’’’’changes’’’’’ in an ‘’’’’agile project make’’’’’ it predictable and manageable. by contrast, Unfortunately, in Historical Project Management methods change the way they manage procedures and budget structures that can’t improve new product requirements. Therefore, sometimes we can see negative affects appear, for instance historical project teams see that they are following a plan automatically and blindly. it makes them lose opportunities to produce more valuable products.

Application

Decision making in Agile approaches, are based on an empirical control method and the real observation during the project. This method can affect project to improve and upgrade projects. In this method, project manager, by using frequent and inspection of the project to date, can make immediate adjustments, if necessary. In Agile projects, whole project should be divided in smaller segment called iterations to accommodate frequent inspection and immediate adjustments. This approach, involves the same type of work as in a traditional waterfall project: creating requirements and designs, improving the product, documenting it and if necessary, integrating the product with other products. After that, testing the product, solving any problems, and deploying it for use. But in Agile approachproject manager need to break these steps for all product features in the project into iterations, also called sprints, instead of completing these at once, as in a waterfall project. 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

The Roadmap To Value is a great approach to look at the planning tasks in Agile Projects, which occurs at a number of points.

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

-In stage 1, as we can see in the figure, the product vision which is the end goal and destination for your project, need to be identified by the product owner. The product vision can help you to indicate how your company or organization’s strategy will be supported with the product. The product vision needs to be revisited at least once a year.

-In stage 2, the product road map which is the holistic view of product requirements need to be created by the product owner. The product vision is created by showing the product features during the project. This stage should be revised the at least biannually by the product owner.

-In stage 3, the release plan which identifies a timetable for the release of specific product functionality to the customer, need to be created by the product owner. There are many releases with the highest-priority features in an agile project and at least quarterly, a release plan should be created at the beginning of each release.

-In stage 4, the sprint planning which is establishment of specific iteration goals and tasks in the sprint, need to be created by the product owner and the development team, at the start of each sprint.

-In stage 5, the scrum meetings are hold every day during each sprint by the development team. This is establishment and coordination priorities for the day and discussion about what you completed the day before, what you will work on today, and any barriers you meet in your planning, therefore you can solve these barriers immediately.

-In stage 6, the sprint review need to be done by product owner and development team at the end of each sprint to demonstrate the working functionality to the product stakeholders.

-In stage 7, the sprint retrospective need to be held by the scrum team at the end of each sprint. In this stage, the scrum team discusses about their processes and environment during the sprint . It can help them to improve their process for the next sprint.

The Roadmap To Value can be repeated with in each stage which contains planning activities.,.

Control schedule in agile approach

In agile approach, control schedule tries:

• To compare the total amount of work delivered with the amount of the work completed in the given time to assess the present status of the project schedule of the work completed.
• To improve the process by reviewing what has been learned
• To prioritize the rest of the work plan again
• To assess the velocity of producing a product in given time
• To assess how well the project schedule has changed and to control the actual changed as they occur

Common agile techniques

Common agile techniques used:

SCRUM

The Agile Scrum Framework at a glance] Available at ,

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

Kanban System Available at

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: 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 workstreams, users, projects, etc.
• Work in Progress Limits: 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 Framework Available at

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..

XP

Extreme Programming (XP) at a Glance] Available at

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 suitable 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 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 approaches consider as a not suitable system for maintenance and its one of the limitations known for this approaches. In the other hand documentation is not the fact of matter for programmer and developer when they use Agile approaches, because the main goal for them is to write software. Every system needs users for being alive and like some other system, Agile approaches is heavily depending 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. Basically, for the small group between 3 and 9 members Agile approaches can be the best choice but unfortunately it does not work 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.