17 Best Methodology Practices for Embracing Agile | Hygger.io

Project Management

17 Best Methodology Practices for Embracing Agile

17 Best Methodology Practices for Embracing Agile

In the recent years the agile development has increased its popularity. First it appeared in the software engineering, but it disseminated to other fields as well. This methodology is important for managing of different project types, so we are exposing here some good agile practices.

The most important Agile practices are:

1. Iterative Development

The software developed during one unit of time, which is usually from 1 to 4 weeks, is called iteration. Each iteration is a complete software project, including requirements, design, coding, testing and documentation. Iteration may not have enough functionality, but the aim is to have available release without bugs, at the end of each iteration. After each iteration the team does re-evaluation of the project.

2. Customer Collaboration

The client of the software product is always informed about the progress of the project and he decides (together with the team) what should be done in the next sprint. This permanent interaction between the team and the client, will ensure that the client will get all the required functionalities.

3. Time-boxed

The term Sprint represents the period lasting from 15 to 30 days (the length is determined by the team), in which the team creates software product (increment). There are also time-stiffed Scrum meetings, with duration about 10-15 minutes each day.

4. Product Backlog

It is a list of features and properties expected by the final product. Features in the list are arranged in order of priority from most important to least important. The project can be defined to implement big tasks that are divided into several smaller ones. The project team determines how much work is needed to be done for the application. Further on you need to identify priorities based on business needs of the client. The main features are elements will be written in the first practice.

5. Value Stream analysis

You should perform value stream analysis, since you need to define the product based on user stories, which are based on the business analysis. As a next step we’ll define the dependencies between the business and technical functionality.

6. User Stories

Based on the duration of the task, (and therefore the duration of the implementation of each completed units), you select the user stories, which will enter into a sprint. It is advisable to prepare more stories, which could potentially be done, if Sprint is completed ahead of schedule; however, you are not bound by their implementation. If the user stories are too complex, they can be broken up into smaller pieces, so as a whole would be processed within a few sprints.

7. User Stories sizing

The size of the User story is expressed in points (Story Points). Each story gets a certain value on the basis of estimated weight at the team level. It is recommended the use of Fibonacci numbers to assess the story size.

8. Continuous integration

In the agile development – programmers often commute their code several times a day, asking frequent builds of it, additional configuration and testing environments. To achieve this, there are some basic practices that you should adopt: code automation, continuous integration, continuous delivery, continuous assessment (continuous testing), and monitoring. You can apply different automation tools (DevOps, Puppet labs, etc.).

9. SCRUM meetings

Daily Scrum meetings are short morning meetings, lasting about 10-15 minutes. The whole team is present and led by the Scrum master. During these meetings you talk about three main issues: to re-visit what was done yesterday, to define the goals for today, and to check to see if there are any obstacles to peaceful work. Additionally, in the case when you program in pairs, you need to define who is who in the hand.

10. Automated Tests

A very common practice in today’s teams is to push the source control system automatically start the build-defined environment (QA / UAT – Units Automated Testing, etc). Before each session – you should create automated unit tests, together by starting adaptive code tests. In the later stage you will develop code specific to the user stories. This approach is updated daily – at the Scrum meetings.

11. Test-driven development

To ensure that the needs of the customer are the main driver of development, first write test scenarios, then the code necessary to pass this test, as a way of forcing the client to specify requirements, which can be tested and verified. In extreme programming there are two types of tests. The first type is functional test specified by the client, and carried out by the project team and users. Other types of tests are the unit tests that are written and executed by the development team. Unit tests are written both before and after the coding, to verify that each module deployment works as expected.

12. Programming in pairs

There is a difference between the opinion by which the software engineering is art, and the other – that it is a science. Pair programming deals with the artistic side of software development, recognizing that the metaphor of a master-apprentice is useful in the phase when the new programmers learn how to develop a master’s instinct. Using a single keyboard, two programmers who work in pairs can develop a system based on the specification and design. One person is responsible for coding, but work in pairs has the flexibility, because a developer may have more partners in the same day. They have consultations, exchange of ideas, etc.

13. Sprint demo meeting

When you have finished the functionality, you should carry out a short meeting in the sprint, so you can explain the functionality and how it works to the client. On this way the client will confirm that they accept a feature and that it was made in accordance with their expectations.

14. Burn-down charts

These charts show the sprint tracking – do things really go according to plan and calendar of programming. They precisely describe the work schedule and time. Also, well-designed charts show the amount of user stories per unit of time, below or above our plan.

15. Retrospective meeting

This meeting should be done as a finite of the iterative development (1-hour meeting, for 2-week duration sprints). The meeting should be attended by all of our team, and the client may also participate. The topic of the meeting is how to improve the process, tools used, quality of our work, lessons learned, training, etc. You can use the matrix with the division into sections: stop, start and continue.

16. Shippable Code

At the end, you have the complete code. You have to ensure that the code is bug-free and it’s functioning. Since the client is involved in the entire incremental process (delivery piece-by-piece) – they will get the expected business value in appropriate time.

17. Release management

You must follow a clear schedule of what software functionality will be released in which time. The incremental development defines the new software releases. It also enables to correct the code if each version provides automated testing, and integration with other components.

No Comments

Leave a Comment

Please be polite. We appreciate that.
Your email address will not be published and required fields are marked


Share via
Send this to a friend