History of modern project management
Project management has existed from times immemorial, from building the great wall of China to the Egyptian pyramids and the invention of the printing press or the advent of the internet. People have executed both large-scale and small-scale projects for a long time.
Project management as a formal discipline began only in the middle of the 20th century during World War II where researchers started building computers for the US military. During these times they followed a step-by-step manufacturing model since early computer-related projects were more hardware than software, almost filling up an entire room. This type of step-by-step project management used in the period of initial computers during the 1940s was known as the waterfall project management methodology.
The waterfall project management methodology was developed in 1970 by Winston Royce, a computer scientist and, he described the different phases of waterfall projects as follows
- Requirements
- Design
- Development
- Integration
- Testing
- Deployment
Where you move to the next phase of the software development life cycle only after finishing the preceding step, though Royce mentioned that iterations are necessary for the development and testing phase, organizations that adopted the waterfall project management methodology overlooked this advice.
Traditional waterfall project methodology failed miserably and, the results of the study conducted by a statistical company called the Standish Group demonstrated this fact.
The study establishes that billions of dollars are lost owing to poor project management techniques.
- Twenty-nine percent of traditional projects failed outright i.e., canceled before reaching the completion stage.
- Sixty percent of traditional projects had gaps between the expected and the actual project results in terms of time, cost, and quality.
- Only eleven percent of projects succeeded and delivered the expected output.
Over the past two decades, project managers and software developers have realized the redundancy in implementing traditional project management processes. Since they have less scope for changes or iterations and have a strict hierarchical based control.
The democratized use of computers and the lightning-speed advancements in computer software resulted in adopting a project development methodology called agile project management. The values of agile project management existed as early as 1930 but gained moment only in early 2000.
The Agile Manifesto
Development teams could not keep up with the booming dot com industry and the constant pressure to develop faster time-to-market solutions using traditional waterfall methodologies.
But the agile estimation methodology created a sea of change in the software industry through an agile manifesto created by agile methodology pioneers who met in February 2001 in Snowbird, Utah, to share their ideas and practices.
They created the agile manifesto, a powerful statement that expresses the agile methodology in less than 75 words.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work, we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Let us look at how the agile manifesto works in detail
Individuals and interactions over processes and tools:
Research reveals 50 times rise in performance rate when team members communicate effectively and, it is achieved by collocating a development team with an empowered product owner.
Working software over comprehensive documentation:
In agile projects, a development team’s focus should be on producing working functionality. Agile projects require bare minimum documentation such that it does not interfere with the process of delivering working software. If the team fails to deliver working software during a sprint, the same task requires 24 times more effort and cost in the subsequent sprints.
Customer collaboration over contract negotiation:
With regular communication with the customer regarding the latest updates and improvements required for a particular software, a product owner can effectively communicate these needs with the software developer. Aligning customer priorities with the developer team resulted in a four-fold increase in productivity.
Responding to change over following a plan:
Agile teams plan as extensively or even more than waterfall teams. However, agile teams take a just-in-time approach, planning just enough when needed. Agile teams believe in adapting and changing the plan to the changing realities of the project and hence delivering a product that provides 100% customer satisfaction.
Agile estimation, though developed mainly for the software and the IT industry, can be used across the board for different use cases from various industries including, biotech, manufacturing, aerospace, engineering, marketing, non-profit work, and even building
construction.
What are agile methodologies?
The agile manifesto isn’t alone enough to dive into project management. It is essential to adopt the right agile approach. The agile approach believes in adjusting your project goals based on experience with multiple iterations and not theory and development. Hence, it is an empirical and iterative approach, and any methodologies having this approach as their backbone are called agile methodologies.
The different agile methodologies are
- Scrum
- Kanban
- Extreme Programming (XP)
- Crystal
- Dynamic Systems Development Method
Scrum
Among the different agile methodologies available, scrum is the most popular one, which is an empirical process wherein a project is broken up into different short fixed-length sprints and at the end of each sprint the project is evaluated to determine if the process adopted is working or requires any changes.
Scrum does not have a definitive approach, instead, you can start with a fuzzy idea of your requirements and the solution and then progressively solve the project proceeds. Thus, scrum is process adaptive and solution adaptive.
Using the top-down approach, gross-level estimates are laid out on the total time required for the project or at the feature sets, so to speak.
A product backlog is created from the roadmap of the “top-down” estimation. The backlog would contain all the list of tasks and also contains short descriptions of all expected features and fixes. The pertinent items are shown at the top of the backlog giving the project team a clear vision of what needs to be prioritized. The prioritization of the backlog is entrusted to the ‘product owner’, who can get clean insight into the efforts required for each work item through a good estimation. The estimation thus would allow for effective sprint planning, by measuring the time that could be taken to complete each task.
In effect, a well-prioritized backlog makes iteration and planning straightforward and also relays all the items that the team would be working on, including internal work.
Thus, a thorough expectation could be set amongst the teams and with the stakeholders.
What is Agile Estimation?
The agile estimation process is a collaborative process having high levels of transparency that estimates the time required to complete a task listed in the product backlog. Around two to four weeks are allotted to complete a product backlog and, these time-boxed intervals are called sprints.
Every task in the product log is called a story to which a story point is assigned by the developer based on the time required to complete the story and a value point assigned by the customer based on the value attached to a particular story.
The team can then start working on a story that is highly valued by the stakeholders, thus agile estimation helps the teams deliver value early.
The different agile estimation techniques used are
- Planning Poker
- T-Shirt Sizes
- Dot Voting
- The Bucket System
- Large/ Uncertain/ Small
- Affinity Mapping
- Ordering Method
- Planning Poker
It is a consensus-based agile estimation technique that works for a small team of 5 to 8 members required to estimate a relatively small number of items.
Once the product backlog is created the employees are huddled together to discuss the estimate for different story points. Each team member selects poker cards in the range of, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89 or a variation of these numbers to represent his/her estimate, if the estimated value is the same all across the team, then that value is considered as the final estimate otherwise the process is repeated after further discussions. These poker sessions are conducted throughout the project.
2. T-Shirt Sizes
It is an easy and simple estimation technique very similar to planning poker but, instead of using poker cards, they use cards with T-shirt sizes XS, S, M, L, and XL to arrive at the estimate for a story point. It is an informal technique used to arrive at rough estimation when there are a large number of items in the product backlog and is done usually at the beginning of a project.
3. Dot Voting
Dot Voting works for a small number of stories where all the stories are written for team members to see, dots are then placed next to each story, either manually or using a whiteboard tool. Dot Voting helps determine the complexity of the project. The higher the dots the more complex is the story. To avoid the team members being influenced by the number of dots next to a product backlog, the dot voting can be done by hiding the number of votes using a particular software.
4. The Bucket System
The Bucket System is the preferred method for remote teams and is used when a large number of stories has to be estimated by a large number of team members.
Buckets are created, which are nothing but cards arranged in the following sequence 0,1,2,3,4,5,8,13,20,30,50,100, 200 or more. The first few stories written on cards are picked at random and then placed in a bucket after discussion with the team members. The remaining stories are divided among the team members who can place them on any scale on the bucket without discussing them with each other. Finally, a sanity check is done where each item on the scale is reviewed and bucket numbers are written on the story cards to record the estimate.
5. Large/ Uncertain/ Small
Large/uncertain/small is for conducting rough estimation speedily by dividing the stories into three categories, large, uncertain, and small. It is a simplified version of the Bucket system where the participants place the user stories in large and small categories first and then tackle the complex stories from the uncertain category later.
With this system, the large and the small stories are out of the way and, the team members can concentrate on focussing on areas where the team lacks content and direction, this method is suitable for discussing a large number of stories among small or medium-sized groups.
6. Affinity Mapping
Affinity Mapping works best with a small group of people and a relatively small number of user stories where the team members are asked to group similar stories from the product backlog and, the groups of similar items are then ordered visually in ascending order.
It is used to arrive at a rough estimate in the early stages of a project where there is a large backlog. Once you find a story point for a product backlog, the next step is to find another backlog that has roughly the same story point and then sequence them according to the priorities of the project.
7. Ordering Method
This method is used when the team is small and, there is a large product backlog. In this method, the stories are placed on a random scale labelled large and small. The team members move each story one step up or down the scale or, they pass the turn and, this process continues until no further ordering is required. Unlike affinity estimation, where similar stories are grouped, in the ordering method, the stories are grouped relative to one another providing a rough estimate at the start of a project.
What happens when a team cannot arrive at an estimate for a few product backlogs?
There are instances during a project where team members are unsure if they can complete a story and they cannot even put a figure on the estimate for that particular story.
At this juncture, the product owner considers using spikes which gives some time to the team to understand why a particular story cannot be completed, if it needs further research or integrations with third parties or if it requires prototypes before going to the customer.
With the team being prepared beforehand with the help of spikes, when the story comes to a sprint, the team knows exactly how to handle the story.
There are two types of spikes, functional and technical.
Technical spikes: Used when the team has to identify the impact of introducing new technologies.
Functional spikes: Used when the development team has to evaluate the impact of new functionalities introduced for a particular solution.
Spikes are estimated the same as sprint tasks during sprint planning, but the time is invested to research and develop software prototypes, documentation, workflow, etc.
Spikes are not stories; they are stepping stones created to gather information or find partial solutions that help arrive at the final solution.
Conclusion
The agile approach is the best way to carry out a software development project and different agile estimation techniques can be used to arrive at the right estimate to complete a story.
The best part about the agile approach is that it is not set in stone like other traditional project management methodologies, it is fluid, flexible, adaptable to change. A developer is not bogged down by documentation or other mundane work and can instead focus all his/her energies on crea
You keep your softwares always up-to-date, right? Be informed about the IT & Remote work news and click on the link: https://email.rolloutit.net
