Gov.uk: basic aspects of the agile methodology

Note translation: We continue to publish a series of translations of materials prepared by the creators of the British state portal Gov UK. These materials can be useful from a practical point of view (of course, not only for creating large-scale state services).

We started with a block dedicated to flexible design methodologies, talked about its important part - creating the so-called user-centered design, and now we turn to flexible development methodologies.

A flexible development methodology can facilitate and simplify workflow. This does not mean that you need to forget all your skills and knowledge.
')
It only means that your team, users and stakeholders will start working together in a new way.

Understand your users

The product characteristics that are most important to the user should receive the highest priority - and even the changes that the big and scary stakeholders want to see in the project should be more important, so you should start collecting feedback from users as soon as possible. Even if they tell you what you don’t want to hear and what you don’t agree with.

If possible, use data from real users who work with your product: let them influence the choice of your development direction. Constantly put users first.

What do you want to do by next Friday? What have you learned over the past week?

Adhere to the principle of frequent small iterations. Create something that provides the most important needs of users, listen to their feedback and improve the product in accordance with them. Continue to work in this way until you get something that is so useful that users will not be able to do without your product.

This may sound like an oversimplification of a complex software development and project management process, but flexible development methodologies are built primarily around the question: “What do you want to do by next Friday?”.

[Approx. Perev .: We decided to turn to the experts and find out - should the duration of the iteration be changed when working on a project depending on its size? How critical is it to follow short iterations (weekly duration) when working on a project?]

Comments on Max Tenth (creative director Redmadrobot):

If we are talking about web services, then the iterations should really be as short as possible, but not shorter than the period during which you can understand something from the results of the changes. If the service is large and with a large user base, then a week is a good time to test a hypothesis. If the service is small, then a week is a good speed of development steps, because a lot of things have to be done in time.

Longer iterations reduce speed and are detrimental to business, because there are 52 weeks in a year and only 12 months. If we consider that not all steps will be correct, then it is better to take more steps than less.

Unfortunately, in mobile applications there are nuances that leave their imprint on the length of the iterations. There 4-6 weeks per step are considered a good pace.

Voldar Mikhail Korneev comments (CTO and tracker in #tceh):

Our #tceh is a big project, more than that - a multi-part one. We are both online and offline. There is a lot of development, especially backend, and in parallel - management and organizational issues.

Our iteration is a week, and we have established it empirically, through bumps and thorns. Objectively, not all processes can be put in a week, but even then they can be broken down into sub-iterations. So now a typical week begins with a meeting of the whole team, where key tasks are defined: this concerns both development and operational, and marketing issues.

It helps: prioritize: everyone understands why this is and what he must do; quickly test or test new hypotheses and products; it happens that once and for all abandon the "Wishlist". And, as a result, fit into the plan of growth and the economy, which we have defined for ourselves and for the investor.

Therefore, from October we use the same mechanics when working with projects that we sit in co-working. These are traction rallies — weekly meetings where I help team leaders with setting goals and objectives that will quickly affect key metrics or get rid of the main bottlenecks in the project. Actually, I studied this approach by helping the trackers of the two previous FRIA accelerators.

Junior Dmitry Zimin comments on the product (product specialist at the Kinohod):

About iterations - definitely depends, and not only on the project. Kilogram of factors. Not only does the project depend on the size of the company, depends on the market, depends on a specific iteration. We have a strong dependence on film premieres: interest in the film film is growing towards large film premieres. Therefore, we try to adjust the outputs of the versions to the premieres, including updating the screenshots of the application. That is, even within the framework of one company / project, there is a dependence of the size of the iteration due to the market. But with all this, in the usual mode, we try to keep one rhythm - it is more convenient to manage the work.

The step-by-step process of creating a product, from the first version ready for distribution and use, allows your team to:

• Constantly introduce new value for users and stakeholders into the project;
• Accelerate the process of receiving feedback - it (the process) in this case is shorter than using the cascade model (in which you move to a new development phase only after all the work at the current stage has been completed);
• Understand which product characteristics are most important at the current development stage;
• To direct efforts to create a product that really will be used.

Use retrospective meetings or a review of the results of the sprint to analyze what decisions worked and what needs to be improved. Your team will continue to educate itself through continuous supply cycles and improve their skills while working on the project.

Work in small, flexible teams.

Small teams (from 5 to 10 people) often work more productively and predictably than larger teams. Forget about one-on-one people (the amount of work performed by an average employee per day) and start thinking of the team as a whole.

Members of a well-chosen team together possess all the skills necessary to successfully create software. Representatives of a well-functioning team are divided into 3 main groups:

• The product manager (this role is most likely taken by the service manager ) is responsible for ensuring the return on investment by creating products that become popular with users.
• The delivery manager (he is the project manager or Skram-master) - an expert in the field of flexible development methodologies, responsible for eliminating distractions, also acts as a facilitator during team meetings.
• The team is a self-organizing multidisciplinary team that creates user stories (“user wishes”), realizes the vision of the product manager and is responsible for evaluating their own results and speed of work.

Strive to ensure that your team members work in pairs, as working together brings more benefits. Two people working on the same task will be:

• Implement more efficient solutions within the framework of product creation;
• Provide better quality control;
• Faster transfer knowledge to other team members.

A good team means that you are able to effectively and consistently evaluate the likely results of your work or its speed. And thanks to this, you can make more accurate plans.

Make a mistake - the sooner the better

By regularly making small releases, you can:

• Improve quality (code and work as a whole);
• Increase the transparency of all processes;
• Reduce market entry costs.

Flexible methodologies do not guarantee you success - you will continue to make mistakes! But these techniques will allow you to find problem areas as early as possible and work on them. You can solve problems or make sure that they do not arise if you:

• Release software releases regularly - this will allow you to collect feedback quickly and know what users think about the product: if the product does not like the audience, it will be easier for you to begin work in a new direction step by step.
• Show the value of your work to the sponsor using the same regular releases - if your software is rarely updated, you risk creating a service “too cumbersome to not work well enough”, which may not be worth releasing, but the release of which can no longer take place.
• Monitor the progress of your teams' work - if there is a “dissint” in speed between teams, even after 4-6 sprints, it means you need to change something (be it previously unknown complications or an inadequate estimate of the time required).
• Use the principles of development through testing ( TDD , writing tests precedes the development of the blocks that need to be tested) in order to identify problems with insufficient quality level as early as possible (find them, determine the necessary metrics and monitor the values ​​for them throughout the project).

Do not be afraid to make mistakes or experiment. Learn how to make mistakes correctly and form a culture within which you will learn from your mistakes.

Constantly work on planning.

The statement that it is not necessary to plan in the framework of agile projects is a myth. Freedom of such projects is not a gift: you have to plan. It is just (unlike other approaches) that needs to be done in a special way and constantly.

Your planning within the framework of flexible software development approaches should be based on verifiable data collected over a sufficiently long period of time, and not on theories or opinions. Your plan must constantly demonstrate the accuracy of the estimates: all members of your project must be confident that it will be implemented.

Your teams should plan their work together or, at a minimum, work together on two levels:

• At the release level - to identify and prioritize those characteristics that your product should have or that it is desirable to implement before the deadline;
• At the iteration level, plan what new characteristics to implement in order of priority (if updates are too large to accurately estimate the amount of work on them or roll them out in one iteration, then they need to be broken down into a number of smaller subtasks).

Review your plans after each sprint and update them based on:

• Previous sprint results;
• Any new facts and requirements.

Frequently encountered situations that need attention

If your team is not familiar with flexible development methodologies, it may encounter a number of well-known situations in which you will have to act outside the box. These situations can have a negative sequel and put your project and its chances of jeopardizing success. Among them are situations where:

1. Your core team does not work full-time or is involved in several projects: your team is a central element in the process of product delivery and you need its 100% return. Report it to the managers and stakeholders and give a negative assessment of the situation.

2. You do not have allocated space for the whole team to work - place the whole team in one room, preferably in your office, and give it the opportunity to use the space on the walls to organize cards and adhesive sheets with records.

Refit your workspace or use more innovative solutions to improve the quality of the environment surrounding the team and increase its productivity - you may need to change the work practices that have become familiar for a long time, but it's worth it.

3. You do not have an environment for continuous integration / development - if your team did not insist on it from the very beginning, it may not be ready for such work. Iterative software development is largely dependent on the possibility of continuous deployment and automated tests.

4. Your company has an independent quality control department. If your team demonstrates the results of its work to an independent quality control department, its employees may misinterpret the results of the work - introduce a culture of quality assurance within your own team so as not to resort to the services of outside groups.

This is certainly not a complete list, but the listed points are the most common.