Agile methodology has become very popular lately. Originating in software development, it has spread to many industries. Since it’s a methodology project managers need to be familiar with, here are some of the best practices. (If you’re not familiar please see the Wikipedia article here.)

Agile Best Practices

  • 1st: Customer Collaboration

Agile should always inform the client of the progress and inform the team about what will be done in the sprint. Remember that through constant communication with the team, we can be sure that the customer will be provided all the functionality required by him.

  • 2nd: Product Backlog

Well, it gets interesting. We already have a project that we need to develop. Now it’s time to take scissors and cut the pieces to specification The full project can be selected to implement the cuts and big tasks are divided into several smaller ones. Then the team determines how much work is needed to take a piece of the application. The next step is to identify priorities based on business needs of the client. The main features are elements that are written in the first practice.

  • 3rd: Iterative Development

For Agile-based teams, the amount of work possible to be done is selected on the basis of the available hour’s team. Simultaneously, the team itself can decide what it is able to do based on their capabilities and experience from the previous iteration.

  • 4th: Time-Boxed.

The duration of the sprint is stiff and takes place within a specified timeframe, which ranges from two weeks to a month. SCRUM meetings, which last about 10-15 minutes each day, are also stiff.

  • 5th: Value Stream Analysis

This is done again on two principles. First, we define the product based on user stories, which are based on his analysis of the business. Then we define dependencies between the business and technical functionality.

  • 6th: User Stories

First, we begin by describing the functionality of communication with our beloved client and then describe the product’s position in a very specific way (as … I want to … because …). They contain mostly three main sections: description, acceptance criteria, and estimation of the time, based on complexity. If the User Stories are too complex, they are broken up into smaller pieces, so as a whole would be processed within a few sprints.

  • 7th: Specified By User Stories Examples

Again we are dealing with User Stories from the previous point. Here they are enriched with examples showing all the options of the given function and how it affects others.

  • 8th: SCRUM meetings

Here we speak of short morning meetings, lasting about 10 minutes. The whole team is present and led by the SCRUM Master. In general, during these meetings we talk about three main issues: to remember what was done yesterday, to define the goals for today, and check to see if there are any obstacles to peaceful work. Additionally, in the case when you program in pairs, we need to define who is who in the hand.

  • 9th: Continuous Integration

Continuous integration of code allows you to keep the code up to date. All code was written which shall be verified before it is connected with the old code. This solution simplifies the testing of new user stories. After the junction of the new codes from the old, unit tests are performed to check for errors. The next day, a regression test is executed, whose task is to verify that new functionality does not adversely affect the rest of the code.

  • 10th: Automated Tests

Each regression test is run automatically before starting work to ensure that the code changes are acceptable. This allows you to get quick information about which of the functionality is not working as planned.

  • 11th: Programming in Pairs

This is a very interesting question because really any good computer scientist is an individualist. It involves the implementation of user stories in pairs (primary and secondary developer). Here, an expert is working with the novice, and most importantly, there is one owner of the user story, the other programmer only provides support and can rotate. Produces two programming sessions, because once one of the developers, the second time becomes the owner of user stories. Even the code reviews are carried out in pairs. In order to assess team performance, group performance and frequency work together to apply the matrix pairs. Logically applied programming in pairs yields results far superior to two developers working separately.

  • 12th: Test-Driven Development

All sessions begin by writing programming adaptive tests that are preceded by unit tests. Only later write code specific to the user stories. This approach is updated daily at SCRUM meetings.

  • 13th: Burndown charts

Firing charts show whether things really go according to plan and calendar of programming. They show precisely the work schedule and time. In addition, well-designed charts show the amount of user stories per unit of time, below or above our plan.

  • 14th: Sprint Demo Meeting

We are ready with the functionality, and now it’s time for a short meeting carried out in the sprint, where we explain the functionality and how it works to the client. This way the customer can confirm that he accepts a feature and that it was made in accordance with his expectations.

  • 15th: Retrospective Meeting

This concept describes a meeting of the finite iterative development. It should be compulsorily attended by all of our team, but the client may also participate. Let’s talk then about the possibility of improving the process, the quality of our work, tools used, lessons learned, training, etc. Let us apply the matrix with the division into sections: stop, start and continue.

  • 16th: Shippable Code

Finally, we have a package code. We just make sure that it is definitely a working code. With the frequent release of the package with the code, our client is assured that in a short time he will get the expected business value.

  • 17th: Release Planning

Calendar of releases must always give a clear message to all concerned, when you can expect new software functionality. Additionally, it helps to correct the code if each version supports automated testing, and integration with other components.

The Agile Manifesto

It is very important that each iteration is performed in close collaboration with the client, so to date, you can modify the assumptions and requirements of the project, correct errors caused by misunderstandings and control the course of the process. Adaptive management software is based on the number of rules and principles, and I hope that after this series you will know them all. One of the advantages of our approach to software development is to provide the customer on a continuous basis (after each iteration), the next product version. This allows you to constantly confront the intentions and expectations of the customer (often evolving) from the real product and modify it, even in late stages of product development. Agile allows you to quickly carry out such changes and reduces costs to a minimum. If you stop the project for various reasons, the customer is with the operating system with greater or lesser functionality to measure the amount invested.

Commonly used procedures in IT companies create situations where the client, after consultation with the functional scope of the software for months, loses control over its development. After examining the effects of the work of programmers, it often turns out that the functionality is different from the expectations of the client or his views on some issues have changed.

The methodology used in the Agile Customer assumes constant insight in the progress of work at each stage of application development. It does so first of all in regular meetings to gather as many comments and jointly solve problems as they occur. They respond quickly to save you valuable time, which can then be spent on testing applications. An increased number of tests give in turn more stability and higher product quality.

Adrian Stolarski is a researcher for InfoSec Institute.