Agile and Non-Agile Project Management

Ready to learn Big Data? Browse Big Data Training and Certification Courses developed by industry thought leaders and Experfy in Harvard Innovation Lab.

Software project management is the practice of planning and executing software projects. Its concepts need to be understood by every team member to ensure a smooth project flow. There are different methodologies that can be mainly divided into structured and flexible approaches. The most common approach, which gained a lot of popularity in recent years, is called “Agile”. This is a flexible approach based on delivering requirements iteratively and incrementally throughout the project life cycle. This post will give you a gentle introduction to agile and non-agile project management approaches with the focus on the Scrum Methodology.

The Waterfall Methodology

The Waterfall Methodology is one of the oldest and most traditional methods to manage the development of software applications. It splits the Software Development Lifecycle (SDLC) into 6 different stages. Waterfall is a linear approach, where you can only proceed to the next stage if the current stage is completely finished. Because of that, it is called the Waterfall Methodology. If you would want to go back to a previous stage, for example, if you want to change the design during the deployment phase, you would need to go through every stage again that comes after the design stage.

Although the Agile approach is more commonly applied in the industry than the Waterfall Methodology, it is still used because implementing a Waterfall model is a straightforward process, due to its step by step nature.

You can see the six stages below:

I. Requirement Analysis

Here, the requirements for the application are analyzed and documented. These documents are the baseline for creating the software and the requirements are split into functional- and un-functional requirements. Like at every of those 6 stages, the stage gets reviewed & signed off before proceeding to the next phase.

II. System Design

At this stage, the design team creates a blueprint for the software, using the requirement documents of stage one. They are creating high- and low-level design documents, which also get revised and signed off before proceeding to the next phase.

III. Implementation

In the implementation stage, developers convert the designs into actual software. This stage will result in a working software program.

IV. Testing

Here, the software gets tested to ensure that all requirements are fulfilled and that it is working flawlessly. In addition, this helps to identify errors or missing requirements in contrary to the actual requirements from stage 1. Testing, also provides stakeholders with information about the quality of the software.

V. Deployment

In this stage, the software gets transformed into a real world application. Software deployment is all of the activities that make a software system available for use. This involves preparing the application to run and operate in a specific environment, making it scaleable and optimize its performance. This can be done either manually or through automated systems. Because every software is unique, this is more a general process that has to be customized according to the specific requirements and characteristics.

VI. Maintenance

In the Maintenance stage, the software gets passed to the maintenance team, which regularly updates it and fixes issues. They also develop new functionality enhancements to the system, to further improve performance or other attributes.

This is how the Waterfall Model works. Like I said, the problem with the Waterfall Methodology is that if any requirements change, the team would have to move back to the requirement analysis stage & has to go through all stages again. The same would happen if the design or somethings else would change. This makes it difficult and inconvenient to make changes afterwards. The design and development processes are not sequential most of the time, because new requirements can surface at any point necessitating changes in design, which in turn results in new development tasks. Another disadvantage is that no working software is produced till the mid/late stages. This is a problem because if the investors decide to shut down the project, you would have achieved 60% of the whole project but you would not even have a single line of code. This would be different with the agile approach, which will be discussed in the next section. Because of these issues, Waterfall can be a risky and uncertain approach, depending on the project. Therefore it is not well suited for large and complex projects.

Its advantages are that it is easy to understand and implement, that it’s phases don’t overlap, that it works good for relatively small projects and that it is easy to manage.

Agile Software Development

What is Agile Development?

The term „Agile“ comprises different software development methods that work all very similar and concurrent to the Agile manifesto. Note that Agile and its corresponding methods are not as prescriptive as it may appear. Most of the time, the individual teams figure out what works for them and adjust the Agile system accordingly. Teams that are working Agile, are cross-functional, self organized and take working software as their measure of progress.

Agile methods are all iterative approaches that build software incrementally, instead of trying to deliver all at once near the end. Agile works by breaking down project requirements into little bits of user-functionalities, which are called user stories. These are then prioritized and delivered continuously in short cycles which are called iterations. To receive the highest customer satisfaction, working agile means to set a focus on quality. In agile teams, development team members have the responsibility to solve problems, organize and assign tasks and create a code architecture that is modular, flexible, extensible and suits the nature of team.

The Agile Manifesto

In 2001, software and development experts created a statement of values for successful software projects, which is known as the agile manifesto. Agile methods are all based on the four main values of this Manifesto, which you can see below.

We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to the 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.

The people who have written the Agile Manifesto, also created twelve principles of Agile software development, which support the manifestos values. These make the practical implementation of Scrum within a company easier to manage.

The Scrum Methodology

Scrum is one of the most used and well known agile frameworks out there. At its foundation, Scrum can be applied to nearly any project.

First of all, in Scrum the project team is separated into three different roles. These are the following: The product Owner, who is responsible for the product that will be created. The Scrum Master, who is responsible for the implementation and compliance of the Scrum rules and processes within the company. And lastly, the Development Team, which are the actual programmers and experts that create the product.

Secondly, Scrum has 5 events that ensure transparency, inspection and adaption. These events are: The Sprint, which is at the heart of scrum. A sprint is a cycle that should always be equally long and should not take longer than four weeks. Every sprint has clear goals about what should be accomplished during its timeframe and the sprints progress is tracked at the scrum board. This board is split into „To Do“, „Build“, „Test“ and „Done“, where the tasks are placed as a sticker and moved from „Todo“ on till it reaches „Done“. You can see such a board below.

At the end of every sprint, a new functionality for the final product should be finished and delivered to the customer. Then there is the Sprint Planning, where the goals for every sprint are set. This is of course done before a sprint starts. There is also the daily Scrum, where the last 24 hours are discussed an the next 24hours are planned. This takes about 15 minutes. There is also the sprint review, in which the last sprint gets evaluated and the developed functionality (product increment) gets tested. This happens at the end of every sprint. Lastly, there is the sprint retrospective, which is also done after every sprint, which has the goal of improving the sprints in general.

To be more clearly, here is the general procedure of a sprint:

Each sprint starts with a Sprint Planning, which is facilitated by the Scrum Master and attended by the Product Owner and the Development Team and (optionally) other stakeholders. They sit down together and select high priority items from the Product Backlog that the Development Team can commit to a single delivery in a single sprint. The selected items are known as the Sprint Backlog. The Development Team works on the items in the Sprint Backlog only for the duration of the Sprint. New issues usually must wait for the next sprint. The Daily Scrum is a short standup meeting attended by the Scrum Master, the Product Owner and the Development Team. A review of the sprint often includes a demo to stakeholders. An examination of what went well, what could be improved, etc. The goal is to make each Sprint more efficient and effective than the last. At the end of the Sprint, completed items are packaged for the release. (Note that some teams release more often than this.) Any incomplete items are returned to the Product Backlog.

Team Roles

1.) Product Owner

The Product Owner is always a single person, which is fully responsible for the product. He writes the requirements that the final product has to fulfill into the so called „Product Backlog“, which we will discuss later on.

The Product Owner basically represent to some degree the customers of the product and therefore represents their needs. But this is only one part of his role. He also represents the bridge between the actual customer and the development team. Therefore, he is responsible for quality assurance of the final product. He is also responsible for considering the needs and ideas of the development team, so that everyone feels comfortable and knows the his opinion is taken into account in regards to the Product Backlog.

2.) Scrum Master

It is the job of the Scrum Master to help the Product Owner and the Development Team to develop and maintain good habits, that are inline with the Scrum Methodology.

The Scrum Master is responsible for the implementation and compliance of the Scrum rules and processes within the company. This involves making sure that every person understands the Scrum framework and works inline with it. Basically, he improves the overall understanding of Scrum within the company. If the companies people understand Scrum 100% correctly, he would be nearly unnecessary. The Scrum Master is also acting as a bridge between the scrum team and the stakeholders. He isn’t part of any hierarchy within the company and has therefore a good general overview. He also helps the product owner with planning and executing of scrum events. On top of that, he can help the development team with the so called „Sprint Backlog“, which we will discuss later on. He also moderates the Sprint Planning, which is also attended by the Product Owner and the development team. He also moderates the daily scrum meeting.

3.) The Development Team

The Development Team consists of the developers and technical experts who are responsible for creating the product increment of a sprint (we will also discuss this later on). Like I said, in Agile and therefore also in Scrum, the teams are self organized. The Development Team is also responsible for creating the „Sprint Backlog and updating it daily. During a sprint, the development is constantly working at achieving the goals for the current sprint. The team meets daily for the so called „Daily Scrum“, where the last 24 hours are discussed an the next 24hours are planned. This takes about 15 minutes. It belong also to the responsibility of the Development Team to present the new product increment during a „Sprint Review“. If an expectation is not fulfilled, which only the Product Owner can decide, the whole team is responsible for it. The Development Team is also part of the Sprint Retrospective.

Scrum is based on empirical process management, which has three main parts. These are the following:

Transparency: Everyone involved in an agile project knows what is going on at the moment & the how the overall progress is going. E.g. Everyone is completely transparent about what he is doing.

Inspection: Everyone involved in the project should frequently evaluate the product. For example, the team openly and transparently shows the product at the end of each sprint.

Adaption: This means having the ability to adapt based on the results of the inspection.

Scrum Artifacts

Now we will discuss the three different Artifacts of Scrum. An Artifact is a tangible by-product produced during the product development.

1.) Product Backlog

The Product Backlog is an ordered list of all the possible requirements for the product. The Product Owner is responsible for the Product Backlog, for its access, its content, the order of its contents and for the prioritization. Note that every product has only one product backlog and only one Product Owner, even if there are many development teams. It is important to understand that a product backlog can never be „complete“, since it is constantly evolving along with the product. Typical entries for it are, description, order and priority of a functionality and the value that a functionality provides for the product. Since the markets and technology in general are constantly evolving, the requirements for the product and therefore the product backlog are constantly changing. The Scrum Team (Product Owner & Development Team) are improving the Backlog constantly together, which is of course a continuous process.

The priority of a product requirement within the Product Backlog plays an important role, because the higher it is, the more clearly and detailedly the requirement is formulated. This is because these are the ones that will soon move to the sprint backlog and therefore need to be clear enough.

2.) Sprint Backlog

The Sprint Backlog consists of the Product Backlog entries with the highest priority in regards to the currently available capacities within the company.

It is the plan of which functionalities are included in the next product increment. It is basically the goal plan of the things that the development team needs to achieve within the next sprint. Therefore it includes the required tasks that need to be done and the criteria the functionalities need to fulfill. Its goal is also to be so clearly to make the teams progress visible during the daily scrum meeting. Therefore it is also constantly evolving and gets regularly updated. The members of the development team are the only ones who are allowed to work on the sprint backlog, which is done during their normal work. During the sprint review, the sprint backlog is used to verify the goals.

3.) Product Increment

At the end of every sprint review, the product increment gets evaluated. It has to fulfill all the requirements from all previous sprints, which means it has to be compatible with them. This is because every product increment is just one part of the whole final product and therefore has to match to the other parts. It is like a puzzle, where a product increment represents one of the different pieces.

If it would not be like this, the whole product would may not work anymore. Also every Product increment, which is a new updated version of the product, must be fully functional at the end of the sprint so that the product owner can deliver it at any time to the customers. Note that a product increment doesn’t have to be delivered but it has to be ready to be delivered.

Summary

In this post you’ve learned about the traditional Waterfall Methodology, its advantages & disadvantages and why it sometimes can be a risky and uncertain approach, depending on the project. Furthermore, we’ve discussed what the term Agile means and looked at the Agile Manifesto, which is at the core of every Agile framework. You now know that Agile frameworks take working software as their measure of progress and you are familiar with the general procedure of a sprint. Lastly, we took a detailed look at the Scrum Methodology, including the different Roles of the project team, the three main parts of empirical process management and the three artifacts of Scrum.