Agile

Just about Agile: awesome summary by ebookhike

86 / 100

Author: Mark Layton, Steven Ostermiller

Agile Project Management For Dummies Mark Layton, Steven Ostermiller 2012

Agile
Just about Agile: awesome summary by ebookhike

Authors: Mark Layton, Steven Ostermiller 

History and basic postulates of Agile (Agile)

Agile (from the English word – dexterous, agile) is a general term covering various project management and work organization methods based on flexible principles as opposed to traditional rigid principles. Such methods and techniques of work were developed in the 1990s among programmers, and in 2001 a group of software developers (software) compiled the Agile Manifesto. Later, the principles indicated in it turned out to be useful in other areas, such as marketing, service delivery, the production of high-tech devices, the development of new niches, and the management of individual workgroups in large corporations.

To better understand the principles of Agile, it is worth briefly describing the old approach to which they are opposed. 

The old software development model was called the cascade or waterfall (waterfall) model. According to this model, developers move from one stage to another strictly in order and only after the previous stage is fully completed:

1. Definition of requirements.
2. Drawing up a plan.
3. Creation.
4. Testing.
5. Implementation.
6. Support.

This model was convenient in that it guaranteed the quality of the product and its compliance with previously known requirements. It also fitted in well with twentieth-century industrial management practices, with their emphasis on hierarchy, standardization, and accountability. 

But over time, the shortcomings of the model became noticeable. The software has become more complex and the business environment has become more unpredictable. The technical requirements declared at the beginning of the development could become outdated or change by the end of the process, and in the course of work new, previously unforeseen requirements and circumstances arose. It was often too late to consider them, and the developers preferred not to release the product at all, losing money and time. In addition, customers rarely used some features of the finished product (up to 60% of the functionality) or did not use them at all, and after all, time and resources were spent on their development. Under such conditions, the advantage was given to companies that were the first to release, albeit not quite “licked”, but more or less working versions of the products demanded by users.


Agile values

So what has helped these agile companies and development teams stay ahead of the competition? The Manifesto postulates four core values:

• People and interaction are more important than processes and tools.
• A working product is more important than comprehensive documentation.
• Cooperation with the customer is more important than agreement on the terms of the contract.
• Readiness for change is more important than following the original plan.

The authors add: “While not denying the importance of what is on the right, we still value what is on the left more.”


12 principles of Agile

In addition to the values, the authors of the Manifesto listed 12 principles on which the work and management of the project should be based:

1. Satisfy customer needs through early and regular delivery of valuable software.

2. Changes are welcome even at a late stage of development.

3. Release a working product as often as possible, from a couple of weeks to a couple of months.

4. Developers and business representatives must collaborate on a daily basis.

5. Motivated and comfortable developers should work on the project.

6. The most effective way to share information is face-to-face communication.

7. The main indicator of progress is a working product.

8. The process must be sustainable, have a constant rhythm, and ideally continue indefinitely.

9. Attention to technical excellence and quality must be constant.

10. The main thing is simplicity, that is, the art of minimizing and rejecting the superfluous.

11. The best solutions come from self-organizing teams.

12. The team should regularly review their work, correcting it as necessary.

In addition to these principles, the authors of the book list three Platinum principles adopted by their Platinum Edge organization:

• Resist formality.
• Think like a team.
• Visualization is better than text.

The Manifesto did not specify any specific methods of work and management, so the general principles of Agile were reflected in various practical methods and techniques, among which are extreme programming (XP), lean product development (lean product development, based on the production system of a Japanese company Toyota) and Scrum. The authors of the book describe the Scrum method first, supplementing it with techniques from other methods and their own developments.

What is Scrum and how does it work

Core Principles of Scrum

Initially, Scrum 1  meant the methodology of flexible software development, which later transferred to the organization of work in other areas. The term Scrum itself is borrowed from rugby – this is a clash of players before the ball is served.

The essence of the method is that the product is not developed sequentially, one part after another, according to a rigid plan drawn up in advance, but in cycles, at the end of each of which a relatively working result is obtained. Such a result (release) can even be released to the market while continuing to be brought to mind in subsequent cycles. 

Development cycles are called sprints. Because of the cyclic nature of this method, it is also called iterative (from the word “iteration” – repetition). 

The goal of the method is to release not an ideal, according to the developers, product, but a version that largely meets the requirements of customers justifies most of the expectations of customers, and allows you to get a reasonable benefit.

The Scrum method is characterized by specific roles in the team, artifacts (the use of physical or virtual objects in the work), and events (actions performed in a certain order).


Scrum team and roles in it

The actual Scrum team consists of developers, a product owner, and a Scrum master. Within the Scrum team, a development team is singled out, and it itself can be part of the project team, which also includes interested parties (stakeholders) – these can be customers of a commercial project or administrators of the company commissioned by the project. 

There are three main roles in a Scrum team:

1. Developers are specialists who have interests not only in their narrow field, but also in related fields, and therefore are ready to help each other and understand the peculiarities of the work of their colleagues.

For example, it can be programmers, debuggers, testers, designers, and artists. 

Agile

Developers, with the assistance of other members of the Scrum team, determine their own tasks and find the best ways to complete them.

The size of the development team is from three to nine people. 

Statistically, teams of six are faster, but teams of four or five are cheaper. 

Agile

If the team size is larger, different factions and interest groups will inevitably appear, which slows down the work and makes it difficult to manage the project. A smaller size is also inappropriate because, during the sprint, all team members must work on the same tasks from different angles (someone writes the code, and someone does the design). 

2. The product owner is the person who liaises the team with customers and business representatives. In addition, he serves as an intermediary between the team and other parts of the organization such as marketing and sales, legal, and support. It is his responsibility to take into account the interests of various parties in the project, including potential users and clients. In traditional management, he would be called a project manager, but there is no vertical hierarchy in a Scrum team.

3. Scrum Master – A person who leads meetings, enforces Scrum principles, manages inventory and facilities, resolves conflicts within the team, and shields the team from distractions. He also cannot be called a manager in the traditional sense, since he does not give any orders to the developers and does not define their tasks.

For well-coordinated work, it is important for all team members to be in one place (room, hall, compartment) – this is the so-called collocation, which corresponds to the values ​​and principles of Agile. 

All communication should be done face-to-face whenever possible. If this is not possible, then with the participation of visual means of communication, such situations should be avoided. Many issues are resolved much faster with direct verbal communication than, say, by e-mail. 

Also, nothing should distract team members from working on the project – no extraneous orders, useless official meetings, extraneous noise, and filling out a pile of unnecessary papers. The Scrum Master should oversee this.

In addition to the Scrum Master, the team may also have an Agile mentor – and external Agile specialist, especially at the initial stages of mastering the methodology. 


Artifacts and tools

The tools used in project management should be as simple and intuitive as possible. The use of whiteboards is encouraged, and the information on which is available to everyone in accordance with the principle of openness. Work tools (such as computers) should also be as mobile as possible so that members of the same team can easily exchange information.

The main Scrum artifacts are:

• Backlog (magazine) of the product. List of complete product requirements and expected features. It is compiled at the beginning of the first sprint by the product owner, taking into account the wishes of customers and other stakeholders. Throughout the work, the backlog changes as new requirements, factors, obstacles, and opportunities become clear in the course of work. The product owner prioritizes the requirements, and their order can also change.

• Backlog (magazine) of the sprint. A list of tasks for the next sprint, determined by the Scrum team-based on priority requirements and tasks in the product backlog. Only developers can change it. They, with the assistance of the Scrum Master, determine the relative value of each task, and formulate stories and criteria for their readiness.

•  Product increment. A tangible result of the work of one sprint (for example, the introduction of a new feature on the site). It is shown to customers and other interested parties in order to evaluate the work done and receive feedback.


Scrum Events

• Sprint. A development cycle, within which other events take place, and the final product with potential functionality is created. The duration of the sprint is fixed – from a week to a month. 

The shorter the sprint, the greater the flexibility of development, the faster releases come out and the feedback from consumers arrives. The longer the sprint, the fewer distractions. 

Agile

It is important to adhere to the set duration of sprints and not change it in the course of working on a particular project because this is the only way to evaluate the speed and effectiveness of work.

• Sprint planning. Held at the beginning of each sprint. At this meeting, the team defines the goal of the sprint, formulates tasks for itself, and draws up the sprint backlog.

• Daily meeting (Scrum). It is carried out at the beginning of each day, mostly standing, and lasts no more than 15 minutes. On it, the developers talk about what the team has done over the past day, what they have planned for today, and what obstacles can interfere with their work.

• Overview of the results of the sprint (demonstration). The team demonstrates the product incrementally to all interested parties and listens to their feedback and wishes. Unfinished features are not allowed to be shown. The demonstration should be strictly functional, without any decorations and unnecessary slide presentations, preferably in a working environment (for example, on a smartphone screen, if it is a smartphone application). Lasts no more than one? four hours (depending on the length of the sprints).

• Sprint retrospective. The final meeting of the Scrum team, where all team members express their opinion about the past sprint, fix successful solutions, and suggest ways to solve problems. Here new requirements for a product can be defined. Sprint planning and retrospectives may be attended by others besides Scrum team members, and this is even encouraged due to the principle of openness, but they do not have the right to vote. Lasts no more than 45 minutes? three hours (depending on the length of the sprints).

How do projects work using the Scrum method?

The authors of the book at their company Platinum Edge developed a Roadmap to Value plan that covers the entire work on the project from conception to the creation of a satisfactory product (it is not called the final product because you can continue to work on it, as well as support it after launch). 

This plan has seven stages:

1. Creation of the product concept. 2. Create a product roadmap. 3. Release planning. 4. Sprint planning. 5. Sprint with daily meetings. 6. Overview of the results of the sprint (demonstration). 7. Sprint retrospective. 

Stages 3-7 are repeated until a satisfactory product is presented or the project is stopped. Let’s look at some of these stages in more detail.


Product concept

Product concept? this is a brief description that does not include detailed functional requirements. It answers questions such as: “Who will use this product?” “In what situations will it be used?” etc. The concept is created by the product owner in discussion with customers and other stakeholders. For large projects, it should be updated at least once a year.


Product Roadmap

A roadmap is a more detailed description of the project, listing all the requirements for it and its intended functions, which is also compiled by the product owner. User stories can be included in the roadmap. Here you should also outline the most general deadlines for fulfilling each requirement since they will still change in the course of work. 

It is recommended to update the roadmap at least twice a year. 

Agile

Requirements and features are listed in order of priority, indicating risks and dependencies on other features or projects; they can also be categorized into more general groups, themes, or “epic stories”. 

When compiling a roadmap, you need to consult not only with customers but also with all interested persons or departments that may have something to do with the project or depend on it (marketing, sales, accounting, legal department, customer support, etc.) .). Based on the roadmap, the product owner creates a product backlog.


Release planning

This is an optional stage because some Scrum teams work without releases and simply showcase the product incrementally at the end of each sprint. But if product releases are released, on the basis of which data on a user reaction is collected, then some sprints maybe release sprints and differ in that their main goal is to prepare for the release demonstration. 


Sprint planning 

Before the start of each sprint, the Scrum team holds a sprint planning meeting.

The recommended duration for such a meeting is no more than two hours if the sprint lasts one week (four hours if it lasts two weeks, etc.).

Agile

At this stage of planning, the role of decomposition increases, that is, the specification of requirements and their comparison with specific tasks. Developers play a key role in this. From the product backlog, they select priority requirements and discuss how they can be implemented as product features or features. Further, the functions are divided into tasks – elements. It is believed that in the ideal case, one element should be completed in one day, a maximum of 12 hours. 

One effective format for detailing requirements and breaking them down into elements is user stories. Let’s consider it in more detail. 

A user story is a description of a product feature from the user’s point of view. For clarity, it is useful to imagine typical users of the product in the form of fictional characters.

For example: Jason ? a young user with a technical background, interested in personal services; Carol? owner of a small business, interested in business services, etc.; you can even use small photographs for visualization. 

Agile

The story itself can be represented as a card, which describes the action of a certain user and the result of this action. In addition, the name of the story, its complexity (score in points), the card number, the name of the person who made it, and the readiness criteria (on the back) can be indicated.

User Story for Mobile Banking App:  
Name: “Inter-Card Transfer”
As: Regular user (Jason)
I want to: Transfer funds between my cards
To: Each card has the amount I need
Points: 5    
Author: Jennifer

Agile


Readiness criteria

Difficulty scoring is important not only for setting priorities but also for the subsequent analysis of the work done and determining the speed of the sprint. 

The score is given in conditional and abstract history points. Outside of the story format, estimates can be given to any product features and elements scheduled for the sprint. Each story or task receives a score based on its complexity (labor intensity, time to complete in working hours, etc.). A story with a score of 5 will take more time and effort than a story with a score of 2 or 1. 

The scoring of stories or features takes place in a process known as planning poker.

planning poker. Each developer is given a deck of cards with numbers. The authors of the book prefer to use cards with numbers from the Fibonacci series: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, etc. 

In the Fibonacci series, each subsequent number is equal to the sum of the previous two; so tasks and stories are not divided into equal parts, which could be perceived as the sum of smaller equal tasks. 

Agile

In addition to these cards, there is a card with a question, which means that the developer does not understand the essence of the problem. Next, the following steps are performed:

1. The Product Owner selects a (priority) item from the Product Backlog and reads its description to the team.
2. Developers discuss the element and ask clarifying questions.
3. Each developer secretly evaluates the item.
4. All developers simultaneously show cards with their scores.
5. If everyone has the same scores, the agreement is reached and the element receives a score.
6. If the scores are different, then the element is discussed; First, those who put the highest and lowest marks speak out.
7. Developers rate again.
8. If there is no general agreement after three rounds, the ScrumMaster helps the developers to achieve it or suggests breaking down the task into smaller elements.

Each element is not recommended to assign a score of more than eight points. 

It is important to keep in mind that the glasses do not correspond to something real. This is just a subjective assessment of the developers of a particular team. 

Points cannot be used to determine the effectiveness of different teams (“While you’re chilling here, the other team scored 40 points!”). 

You can’t fit your activity into glasses in order to create the appearance of work. Agreed items are added to the sprint backlog. Afterward, it cannot be changed. 

If a new idea comes up during the sprint, the developers report it to the product owner, who decides whether to put it in the product backlog or the next sprint backlog or discuss its usefulness with customers.

The sprint velocity is the sum of all user stories/items completed in a sprint.

If in the first sprint the team completed work on six stories with a score of 8, 5, 5, 3, 2, 1, then its speed is 24, and developers should focus on this number when planning the second sprint. In the third and subsequent sprints, the speed may be adjusted. That is why it is so important to maintain a set sprint length and a steady pace of work, as well as to avoid rush jobs and burnouts. Without this, more or less objective analysis and planning of sprints is impossible. 

Agile

After the first four sprints, as a rule, the speed levels off and it becomes possible to more accurately calculate the duration of work on the project. To do this, the product owner multiplies the average speed by the total sum of the estimates of the remaining tasks in the backlog. 

If the average velocity is 20 and the remaining product backlog contains 800 points, then the project will take another 800/20 = 40 sprints, i.e. 40 weeks for 1-week sprints and 80 weeks for 2-week sprints.

Agile


Sprint

After planning the sprint, work begins within the sprint with daily short meetings (scrums) lasting no more than 15 minutes per day. While working, the Scrum team can use various ways to visualize the workflow. Among them it is worth noting the following:

• Kanban boards. They allow you to track the development of the tasks listed in the sprint backlog. Each task is presented as a card or sticker that can be moved through the To Do, In Development, Accept, and Passed columns. (The number of columns may vary depending on the style of the team, for example, there may be a “Testing” column.) The product owner analyzes the finished items and converts them to the “Passed” category.

• Combustion diagram. Shows completed and the remaining amount of work in story points and hours, allows you to compare the pace of work with the ideal. To build it, the days of the sprint are marked horizontally, the number of working hours (of all developers) is marked vertically on the left, and the number of points is marked vertically on the right. 

The ideal schedule (plan) connects the point of available work hours and points at the beginning of the sprint to the zero point at the end of the sprint. If the actual schedule rises above the ideal, it means that the team is behind schedule. If the real schedule falls below the ideal one? the team is ahead of schedule. In any case, this is an occasion to think about how correctly she set herself the scope of tasks. If the schedule ends too quickly, it is worth adding the elements of the next sprint and focusing next time on a larger number.

Particular attention should be paid to product testing. In the waterfall model, a finished product is tested at a stage when it is often too late to work on bugs. In Agile models, testing should be done at the same time as development.

When it comes to software, it is recommended to conduct automatic testing, for example, to run the program at night after the end of the day’s work. To improve reliability, it is recommended to use methods such as pair coding, when one developer writes the program, and the other immediately analyzes it and gives advice. 

While working on one element, one should not spray and jump to other elements or extraneous work. The method, when all team members work simultaneously on one story, is called “swarming” (from the English word swarm – swarm, horde).

Two tricky moments when using Scrum

Ideally, only one team should work on a small to medium project. “More” does not mean “better” here. When several Scrum teams are mobilized to work on very large and complex projects, alignment issues arise because different teams may have different speeds and work styles, but at certain intervals, you need to demonstrate a common work increment.

One of the matching methods is the so-called vertical slicing. Product requirements are divided into topics or groups and assigned to different teams that work in synchronous sprints. A separate integration Scrum team oversees the integration of elements from different teams. After the daily Scrum meeting of the teams, a “Scrum Scrum” is held, in which representatives of all teams are present. The product owner of the integration team creates a single project backlog. In a very complex and large-scale project, teams can be combined into fives, and a “meta scrum” is held with the participation of project owners and Scrum masters of these fives. Accordingly, after individual reviews, general reviews with retrospectives are also held.

Difficulties also arise when a company moves to the Scrum model. Many of the problems are related to the fact that the company is trying to combine traditional waterfall methods with Agile methods, which is not recommended. The pilot project should not be critical but should be of value to the company. 

When forming a Scrum team, you need to involve active specialists and choose the right roles according to their competence. An Agile manager with experience in Agile projects helps with the transition. There are various organizations that offer assistance with the transition to the Scrum model, provide training, and issue certificates.

Top 10 Thoughts

1. Agile is a general term for various project management and work organization methods based on the principles of self-organization, readiness for change, simplicity, cooperation, and openness. 

2. The main thing in Agile is not rigid adherence to the plan and not the ideal end product, but the creation of a workable product, as soon as possible.

3. One of the Agile methods is the Scrum method, which is based on repetitive work cycles of the same length – sprints, each of which lasts from one to four weeks.

4. The main roles of the Scrum team: are developers, product owners,s and Scrum masters. The optimal number of developers is from three to nine. Customers and other stakeholders are actively collaborating with the Scrum team throughout the process.

5. The product owner compiles a product backlog (magazine) – a list of product requirements indicating their approximate priority; During sprint planning, developers create a sprint backlog, a list of features and elements that need to be implemented throughout the sprint.

6. Every day there is a short meeting (Scrum), after which the team works together on the elements while testing them. The Scrum Master enforces the Scrum rules and eliminates distractions.

7. In their work, the Scrum team uses tools such as user stories, kanban boards, and burndown charts. The sprint speed in story points helps to determine the effectiveness of the entire process and analyze the work on the project.

8. At the end of each sprint, the Scrum team demonstrates, if possible in a working environment, the result of their work – an increment, a release, or product elements, ideally ready for implementation. After listening to the comments and suggestions, the team conducts a retrospective of the sprint – an analysis of their actions.

9. Additional requirements arising in the process of work and testing, the product owner enters into the product backlog. Then the cycle is repeated until a satisfactory product is obtained according to the jointly established criteria.

10. Do not combine Agile and traditional waterfall project management methods. The pilot project should not be critical but should be of value to the company. 

1 . Read the summary  “Scrum: How to work half as much while doing twice as much”  and  “Scrum: a stunningly concise guide and an introduction to Agile”

Next Post

86 / 100

Leave a Reply

Your email address will not be published.

Related Posts

Begin typing your search term above and press enter to search. Press ESC to cancel.

Back To Top