The Agile project management methodology has been used by software engineers and IT professionals for the past sixteen years. It has recently gained acceptance by a wide number of professions, industries, and organizations.
The reason for this surge in popularity is quite understandable, the majority of projects benefit when managed using lean concepts promoted by Agile project management methodology.
Until recently some academics and Project Management Institute (PMI) considered Agile method, not a serious contender in project management due to the fact that is very hard to set a due date for project’s completion in the Agile method.
But the tide is turning and Agile project management is gaining wide acceptance as a valid process for most projects.
History of Agile project management
In the late twenty century, many software engineering researchers in academia were studying the disturbing fact that most software and IT projects finish late or fail to finish at all.
The bigger the project’s scope and its feature set were, there was more likely that the project either finished late (in most cases very late) or never finished and was discarded with a huge cost in money, resources and opportunity cost.
In one such study by Robert D. Austin and Richard L. Nolan from Harvard University, the research team published the following findings:
- The assumption that it is possible to plan for very large software projects is a myth.
- The assumption that it is possible to avoid or ignore late changes in requirements in large projects is wrong and never holds.
- The assumption that the features and functionality of large project could be locked in from the project’s inception is totally unrealistic and fails time and time again.
The above three assumptions are the foundation and bedrock how the traditional project management methodology was planned. No wonder so many projects were failing.
The conclusion was reached by the research team that an incremental approach to software development works better.
The team creates a working prototype quickly and then incrementally improves the software both in terms of functionality and quality.
This works much better for most large projects.
In 2001 a group of software engineers and scientists in IT industry got together and wrote Agile Manifesto. The idea was to find a better way to manage projects in the software industry and get a better handle on schedule and cost overruns.
It was obvious to the group that iterative and incremental development based on lean principles is the best way to develop software applications.
In this new approach, the experience and knowledge gained from previous iterations could be applied to subsequent development phases.
The gradual and incremental improvement is the foundation of Agile project management method. Based on this fundamental understanding the group came up with the four core values of the Agile project management method.
These core values are listed below:
- Emphasizing individuals and collaboration (interaction) between team members above process and tools.
- Working software even with limited functionality at the expense of excessive documentation.
- Customer collaboration over rigorous contract negotiation.
- Expecting responding to requirements changes even late in the project life cycle instead of sticking to the plan and delivering a product nobody wants or needs.
Base on above core values, the group published the twelve principles of agile project management methodology.
Agile was adopted by the software industry soon after the Agile Manifesto was written. Today the majority of projects in IT industry use variants of the Agile method like Scrum, Kanban or Extreme programming to manage projects.
Before starting a project or choosing a project management method to manage it, you need to consider the following issues and come up with answers for each one of them:
Project size as defined by the amount of work needed to finish the work should be one factor in deciding what project management method you should use.
How do you determine the size of a project? Does complexity affect the size of a project?
If the technology is known and there is no research and discovery needed to complete the project, it could be considered as a small project.
On the other hand, a project which depends on discovery or a new way of implementing an existing technology on a new novel way should be considered a large project.
Small projects need minimal planning and supervision. In contrast to large projects which need more level of planning, documentation, and supervision.
How much planning do you need before the start of a development? Too much planning in an environment where all details are not known is a recipe for wasted time and resources.
No planning, on the other hand, could also cause grave risks to the project and even may cause the project to fail.
The answer to the degree of desired planning is in somewhere in the middle of above two extremes when using the Agile method to manage projects.
In the Agile method, the project manager needs to be flexible and quick on making decisions. Project managers who tend to adhere strictly to the methodology have a harder time managing Agile teams.
A manager with great interpersonal skills and a good knowledge of the technology used in the projects always has a better grasp of the project’s actual status versus the plan.
In the Agile method, it is well understood that requirements most probably will change during the project life cycle and the team should be able to handle these changes with ease.
A lot of project managers put the project plan ahead of what is good for the product.
What counts at the end of projects is the product and its quality and not sticking with the plan. Think of a plan as a map, during your journey you will encounter new challenges and the plan needs to change accordingly.
How do you come up with project estimation in Agile world? If all requirements are not before the project starts, how do you provide the client or the project sponsor and schedule as to when the product will be shipped?
Project estimation is hard not only in Agile but traditional methods as well. Most rigorous planning and estimation in the traditional project management method don’t make for on time delivery in 90% of project cases.
Estimation is valid if the type of work has been done by the team before and is well understood. Estimation for short run projects is always more accurate than for long projects.
Due to the incremental and iterative nature of Agile, the project is divided into smaller phases or iterations.
This makes the job or estimation for each delivery much more accurate. Since Agile forces that both the scope and time in each project’s iteration (Sprint) to be bonded, the process of estimation and scheduling is much easier than waterfall.
So in the Agile method, the customer asks what functionality I can get for the money and the planned time I can afford to have my product in the market.
It is the job of the product owner to set the expectations right and don’t over promise. I wrote Planned time in the above paragraph because, in the knowledge work and projects involving discovery, it is very hard to predict the end date accurately.
After running a few iterations and gaining confidence in the team’s ability to deliver the product, the team can set more accurate deadlines.
Agile project management workflow
What is the ideal team size for the Agile projects? Although the project size defined as the amount of work needed to complete work has the direct effect the size of the team needed, very large teams have an inverse effect on productivity.
Small teams are always more productive than large teams. The ideal team size for the core developers in Agile is around 7-10 engineers. They could be supported by craftsman, manufacturing and logistic people as needed.
Any Agile team larger than 20 will have substantial coordination and communication issues. The whole point of the Agile method is to have highly skilled professionals who are experts in their fields and can accomplish amazing results in a short time.
By the way, this is one of the shortcomings of Agile too. Very large multidisciplinary projects don’t fit Agile project management method well.
12 principles of Agile project management
In the Agile Manifesto, twelve principles are established and as are listed here:
The idea here is quite simple. Instead of lengthy contract negotiation and specification, create the first prototype and show it to the customer.
Based on the customer feedback make improvements on the second iteration. Keep doing this for each iteration and the customer is happy with the result.
In Agile contract negotiations and huge specifications are replaced with collaboration and continuous communication. This reduces misunderstanding and created a good feeling for both the developer and the customer.
2-Expecting requirement changes
For long projects, a lot of things can change while the product is developed. The market may change, the competition may have something new and totally unexpected.
The political changes and society’s task and expectation may evolve.
So assuming the specification is fixed and can’t be changed is a losing proposition. The Agile process assumes that change might happen at any point during project’s life cycle.
The team is flexible and has contingency plans for any change during any time in the project’s development.
3-Delivering the product often and in short intervals
The great thing about delivering the product in short intervals and often is that any issue is detected quickly and could be fixed before it is too late.
The customer and the product sponsors have the chance to see the product before it is finished and flag any problem before the product is shipped.
Each iteration should be in weeks and not in months. From my experience four to six weeks sprint duration is ideal.
The Agile team and the project’s sponsor should be able to maintain a constant paste for development, testing, and release.
The heroic dash to the finish line is replaced with constant and sustainable development. This is a healthier environment for everyone and produces much better results in the long run.
At the beginning of the project, everyone knows they need to work at the same paste as the project’s end.
This is easier said than done in practice. When the deadline is months away as in traditional methods, the sense of urgency is lacking.
But due to the short duration of each iteration, the deadline is at most weeks away. After a while, Agile teams learn to keep constant effort for development.
5-Constant collaborationist between business unit and development
In a traditional company setting, the relationship between the business unit and the development team is of adversary nature.
Each team complains about the other and has no trust in them. On the other hand, Agile method changes this adversarial atmosphere to one which promotes collaboration and respect for each other.
Teams which can collaborate effectively can produce amazing products. I would like to emphasize that collaboration does not mean lack of healthy dose of competition.
The competition here changes to make the best one possibly can and have pride in the outcome.
6-Trust in developers
Traditionally the management has shown little trust in developers. This creates an atmosphere which is not collaborative and supportive.
When there is trust between management and those who do the development, the information hiding, self-protection and white lies are eliminated.
Everybody in the team knows the real status of the project at any given time. Research studies have shown that in traditional project management it takes months before problems known to most of the team is reached to the upper management.
Agile helps to foster an environment of trust and accountability across the project.
7-Face to face communication
There is nothing more effective than face to face communication when people collaborate with each other. Agile promotes collocation and frequent communication between the team members and sponsors.
The new technology like video chat is a nice enable when people are not in the same room to talk, but should not replace face to face communication if that option is available.
When we communicate in person, our body language conveys real important information to the person we are talking with.
8-The product itself is the only measure of progress
Think of it, what is the most important thing in the project? If not the product or service you are working to complete, then what else?
To measure the progress you need to check where the product stands at any given moment. Completing the specification, test spec and design documents are all good.
But the only thing that matters at the end of the day is the successful release of a new product to the market.
By keeping your eyes on the status of the product daily, you never lose focus as what needs to be done next in the project.
9-Continuous improvements in process and design
Even nature is using Agile project management
This is very close to my heart. I have always believed the only way forward is by continuous improvement in the product and the processes used to bring the product to the market.
Amazingly nature works. Everything in nature is constantly is improved to face new phalanges or become more efficient.
You may think this concept only works in software development and IT industry and not in industries like car production or manufacturing.
You are absolutely wrong in this assumption. I don’t know if Elon Musk is using the Agile method in producing cars for Tesla. But I hope he does.
By improving the product at a fast paste and testing every new improvement with users, Tesla can get a huge lead over the competition.
From what I have seen so far with Tesla product releases, it seems they are using some sort of Agile method.
10-Keep it simple
In project management like in life when you keep things simple you achieve more. The reason there is complicated stuff out there is that nobody has taken the time to figure out the problem and come up with the right solution.
Keeping it simple not only applies to design and development but also to the group organization and that way the team is managed.
Overloaded structure and bureaucracy have a tendency of sucking out productivity from any team.
This concept is really important the way the customer interacts with the product. In the market place easy to use and intuitive products always win and complex and hard to use products always loose.
11-Motivated self-organizing teams work best
Some managers have a hard time accepting this concept. They think a group needs direction and guidelines from a manager to be really productive. I am not arguing that a team does not need a leader, far from it.
The basic principle is that teams whose members have a stake in the outcome of the result and are professional mature enough will need less management and are more productive.
12-Continuous self-assessment and improvements by the team
After each sprint or iteration, the team needs to not only evaluate the product they have made but the processes they used to get there.
Is there a better way of doing what we just did? Is there anything we can improve in the next iteration? Does any member of the team needs training on any subject?
Do you collaborate effectively? Is everybody in the team is heard and his or her ideas are given the time it needs?
The answer to these questions will help the team get more productive and better at doing tasks than before.
Continuous self-assessment by the team and the individuals in the team is greatest resource for improving productivity and a happier workforce.
Golasory of Agile terms you need to be familiar with
Agile Roadmap to value
- Product vision: Product owner defines product vision. What the product is and how it helps the company’s financial objectives? Who is the customer and how it benefits the user of the product?
- Product Roadmap: The high-level description of the product requirements created by the product owner. After the product requirements are established, the details are prioritized and a rough estimate is created. The project plan should be reviewed at least twice a year (preferably four times a year) for longer projects.
- Release Plan: The release plan is created by product owner with the help of other technical people in the project. A high-level time frame for product releases is created. The release plan should define 3-6 sprints before the development can starts.
- Sprint Planning: Here product owner, scrum master and the team members plan each iteration which is called sprint.
- Daily Meetings: During the product development, the team has a short 15 minute standing only meeting called daily Scrum. In these meetings, the work is done in the previous day, the plan work for today and if the team or any member is facing challenges is discussed. If further discussion is needed for hash out issues, a sub group will have separate meetings to tackle issued raised in daily scrum.
- Sprint Review: At the end of each sprint, the product is showcased to all stakeholders in the project.
- Sprint Retrospective: A review meeting is conducted by the team at the end of each sprint to evaluate the progress made compared to the plan and document lessons learned which could be applied to the future sprints.
Agile project management Roles
- Product development: The group that does the development of the project to create the product. This includes engineers, programmers, designers, testers or anybody who works on a piece of the product.
- Product Owner: The manager responsible with interfacing with customer, upper management, and the team. Product owner has business responsibility for the project and is an expert in the product and the user base the product will serve. This role is similar to program manager’s role in traditional project management.
- Scrum master: Or project facilitator responsible to keep the Agile team running smoothly, clearing up organizational hurdles and making sure Agile process is followed. The Scrum Master is the organizer of the daily scrum and is the one who makes a summary of the daily meeting and reports them to product owner and management.
- Project Stakeholders: Anybody with a vested interest in the outcome of the project, like a customer, company’s management, and other sources.
- Project’s Agile Mentor: Someone with previous Agile project management experience who can share the experience with the team and guide them when they need help.
Agile project management Artifacts
- Product Vision statement: A short write up about the goals and objective of the project and the benefits of the product. Similar to startup’s elevator pitch
- Product Backlog: A prioritized list of everything that needed to be done in the project to finish the product and ship it to the market. The product backlog is derived from the requirement document.
- Product Roadmap: The high-level definition of the project plan with estimated time frame as for when the project will be finished.
- Release Plan: A timetable for the release of the product into the market.
- Sprint Backlog: The objective and tasks needed to finish a given sprint.
- Increment: The functionality definition for the product at the end of each sprint.
- Project Planning: Initial planning for the project which produces the product vision statement and product roadmap.
- Release planning: Planning the next set of feature which will go into the next release. The lunch date or internal or external release is set. Only one release at a time is allowed in Agile project management.
- Sprint: The development time for each release. This time frame should be a short few weeks typically 2-8 weeks for each sprint. It is best to keep the length of sprints the same throughout the project.
- Sprint Planning: A meeting is held at the beginning of each sprint so the Agile team agrees and commit on the sprint goals. The team also identifies the requirements which are needed to reach the Sprint’s goal.
- Daily Scrum: A short daily meeting usually around 15 minutes, but never longer than 30 minutes. It is best to keep these meetings no seat, standing only meeting.
- Sprint Review: At the end of each sprint the product owner organizes a meeting involving all project stake holder. In this meeting, the development team will demonstrate the new version of the product completed in that sprint.
- Sprint retrospective: A meeting at the end of each sprint to review how the sprint was concluded. What went right, what did not work and if they need to change any process or design assumptions in the next sprint.
Popular Agile project management types in use today
- Scrum-By far the most popular Agile project management method. Scrum and Kanban are used by the majority of Agile projects.
- Kanban- Another popular Agile method. Most none technical teams prefer Kanban over other methods due to its graphic nature.
- Dynamic system development method-Could be used by non-software disciplines.
- Adaptive Software Development (ASD)- Only applicable to software and IT projects.
- Lean Software Development (LSD)- Another Agile method only used in software and IT industry.
- Extreme programming- Another software only project management method
- Rapid Application development (RAD)- Used in software industry only
Do you need a Certificate to manage Agile projects?
There is nothing wrong with getting one of many certificates offered for project management in general and Agile positions like Scrum master or product owner in particular.
But having a certificate is not a must. The concepts behind Agile project management are simple enough and the wealth of information on the internet about this subject so huge, that anybody can learn to become an Agile master.
There is a huge industry dedicated to convincing people they need a certificate to be able to do the job right and that is not true in most cases.
Advantages and disadvantages of Agile project management
Like any other process or method, Agile has its strong points but might not be for every project. Here is a list of the pros and cons of Agile project management method.
Advantages of Agile project management:
- More Scope flexibility- Since the time and resources are fixed, the only thing that can change in the project is scope (features). This gives the team a better tool to prioritize features.
- Transparency and accountability- In Agile everything are known to everybody, no place to hide. This improves transparency and accountability in the project.
- Feedback is received very fast- Due to short time frame of sprints, user feedback is received constantly
- The team is a lot more motivated- Highly professional organized in small teams responsible for delivery of a product, tend to be more motivated than others.
- The final product better matches the market expectation- Since the project sponsor or the customer is highly involved with the development, results in fewer surprises and misunderstandings.
- Better collaboration among team members and project sponsors- Collaboration is the fundamental cornerstone of the Agile method.
- Great for knowledge work and projects which involve research and discovery
Disadvantages of the Agile method:
- Feature creep due to constant feedback- When the customers play with the product while finished they have more tendency of changing their mind.
- Documentation is neglected or forgotten- Nobody has time for documentation.
- Extreme pressure on the team and sponsors- There is pressure on each member to do the best and daily standing meetings take their toll.
- No real due date- The customer or the project sponsor does not have the luxury of knowing when the project will be completed.
- Not a good fit for very large teams.
When should you use the Agile method?
Now that you have a firm understanding of traditional and Agile project management method, the question is which projects are good candidates for Agile?
- Projects which involve research and discovery.
- Projects which the requirements have a high probability of change at any time during the project life cycle.
- Small teams with high degree competence in the area of expertise. Agile does not scale well when the team gets too big.
- Projects with very aggressive deadlines.
- Small to medium projects.
Agile project management method is a potent tool in the arsenal of any project manager.
When evaluating project’s requirements the product owner/manager needs to decide which project management method best fits the project, the company culture and the team which will develop the product.
Not all projects are suitable for the Agile method, the same way that not all projects are suitable for traditional project management method.
A new project management method called Hybrid method is gaining acceptance for projects which both Agile and waterfall doesn’t fit well. Hybrid method uses the best part of Waterfall and Agile methods.
It fits better the need of projects in which both agile and traditional methods fall short. The subject of how to select the best project management method for your project is the subject of an upcoming article which will be in Collaboration Corner soon.
Binfire is built from grounds up to support any project management method, this includes Agile, Waterfall and Hybrid project management.
If you decide to use Agile project management method in in your next project, try Binfire for free and we will help you get Agile project management right from the get go.