Gov.uk: basic aspects of agile methodology

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

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

A flexible development methodology can facilitate and simplify the 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 begin to work together in a new way.

Understand your users

Product features that are most important to the user should receive the highest priority - and be more important even than those changes that large and scary stakeholders want to see in the project, so you should start collecting user feedback as soon as possible and more often. Even if they tell you what you do not want to hear and with which you do not agree.

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

What do you want to do next Friday? What did you learn last week?

Stick to the principle of frequent small iterations. Create something that meets the most important needs of users, listen to their feedback and improve the product in accordance with them. Continue to work this way until you get something useful so that users can’t do without your product.

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

[Note perev .: we decided to turn to experts and find out - should the iteration duration change while working on a project depending on its size? How critical is it to stick to short iterations (weekly) when working on a project?]

Commented by Max Tenths (Creative Director of Redmadrobot):

If we are talking about web services, then the iteration 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 have time to test a hypothesis. If the service is small, then a week is a good speed of development steps, because there is a lot to do.

Longer iterations reduce the speed and are harmful to the business, because in a year as much as 52 weeks and only 12 months. Considering that not all steps will be correct, it is better to take more steps than less.

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

Commented by voldar Mikhail Korneev (CTO and tracker in #tceh):

Our #tceh is a large project, moreover, a multi-component one. We are both online and offline. There is a lot of development, especially the backend, and in parallel - managerial and organizational issues.

Our iteration is a week, and we established it empirically, through cones and thorns. Objectively, not all processes can be stacked per week, but even then they can be divided into sub-iterations. So now a typical week starts with a meeting of the whole team, where key tasks are defined: this applies to both development and operational, and marketing issues.

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

Therefore, since October we have been using similar mechanics when working with projects that are sitting in our coworking. These are traction rallies - weekly meetings where I help team leaders with setting goals and objectives that will quickly influence key metrics or get rid of the main bottlenecks in the project. Actually, I studied this approach, helping trackers of two previous FRII accelerators.

Commented by Junior Dmitry Zimin (product specialist at Kinohod):

About iterations - it definitely depends, and not only on the project. A kilogram of factors. Not only that, depending on the project, depends on the size of the company, depends on the market, depends on the specific iteration. We are very dependent on the movie premiere: interest in the Cinema Walk is increasing in large movie premieres. Therefore, we try to predict the release of versions for the premieres, including updating screenshots of the application. That is, even within the framework of one company / project, there is a dependence on the size of iteration due to the market. But with all this, in the normal mode, we try to keep one rhythm - it’s more convenient to manage the work.

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

• Constantly bring new value to the project for users and stakeholders;
• To speed up the process of receiving feedback - it (the process) in this case is shorter than when using the cascade model (within which you proceed to the new development phase only after all work at the current stage is completed);
• Understand which product features are most important at the current stage of development;
• Direct efforts to create a product that will really be used.

Use flashback meetings or a sprint review to analyze which decisions worked and what needs to be improved. Your team will continue to learn, going through continuous delivery cycles, and improve their skills in the process of working on the project.

Work with small, flexible teams

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

The members of a well-chosen team together have all the skills necessary for successful software development. Representatives of an effectively 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 are gaining popularity among users.
• The delivery manager (aka project manager or Scrum-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 group that creates user stories (“user stories”), realizes the vision of the product manager and is responsible for evaluating their own results and speed of work.

Strive for your team members to work in pairs, as working together is more beneficial. Two people working on one task will be:

• Implement more effective solutions as part of the creation of the product;
• Provide better quality control;
• Faster transfer of 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 build more accurate plans.

Make a mistake - the sooner the better

By regularly making small releases, you can:

• Improve the quality (code and work in general);
• 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:

• To release software releases regularly - this will allow you to collect feedback quickly and know what users think about the product: if the product is not liked by the audience, it will be easier for you to start working 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 run the risk of creating a service “too cumbersome to work well enough”, which may not be worth releasing, but the release of which can no longer fail.
• Track the progress in the work of your teams - if there is a “desync” between the teams in terms of speed even after 4-6 sprints, then something needs to be changed (be it previously unknown complications or an inadequate estimate of the required time costs).
• Use the principles of development through testing ( TDD , writing tests precedes the development of blocks that will need to be tested) in order to identify problems with an insufficient level of quality 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 to make mistakes correctly and create a culture within which you will learn from your own mistakes.

Constantly Planning

The statement that there is no need to plan in the framework of agile projects is a myth. The freedom of such projects is not in vain: you have to plan. It is simple (unlike other approaches) to do this in a special way and constantly.

Your planning as part of flexible approaches to software development 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 sure that it is feasible.

Your teams should plan work together, or at least work together on two levels:

• At the release level - to determine and prioritize those characteristics that your product should have or which it is desirable to implement before the deadline;
• At the iteration level, plan what new features to implement in order of priority (if the updates are too large to accurately estimate the amount of work on them or “roll out” them in one iteration, you need to break them down into a series of smaller sub-tasks).

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

• The results of the previous sprint;
• Any new facts and requirements.

Common situations to watch out for

If your team is not familiar with flexible development methodologies, it may encounter a number of well-known situations in which it will be necessary to act non-standard. These situations can have a negative continuation and put your project and its chances and success at risk. Among them are situations when:

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

2. You do not have allocated space for the whole team- Put the whole team in one room, preferably in your office, and give her the opportunity to use the space on the walls to organize cards and sticky notes with notes.

Re-equip your workspace or use more innovative solutions to improve the quality of the environment surrounding the team and increase its productivity - it may be necessary to change working 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 ability to continuously deploy and conduct automated tests.

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

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