"So, I want to tell you about Agile and Scrum."
"At the beginning of the 21st century, the way people thought about programing was turned upside down."
"Everyone was convinced that long-term planning wasn't working, so they decided to abandon it altogether."
"How did they do that?"
"Here's how."
"They invented the most flexible project management approach possible."
Here are the main ideas behind agile development:"
- people and communication are more important than processes and tools;
- a working product is more important than exhaustive documentation;
- collaborating with the customer is more important than meeting the terms of a contract;
- willingness to change is more important than sticking to the original plan.
Here are principles of rapid development:
- satisfy the customer by supplying valuable software early and continuously;
- welcome changes in requirements even at the end of development (this can increase the competitiveness of the end product);
- deliver working software frequently (every month or week or more often);
- close daily communication between customer and developers throughout the entire project;
- the project is worked on by motivated individuals who are provided with the necessary work conditions, support, and trust;
- the preferred method for communicating information is a personal (face to face) conversation;
- working software is the best measure of progress;
- sponsors, developers, and users should be able to maintain a constant pace for an indefinite period;
- constant focus on improving technical excellence and user-friendly design;
- simplicity is the art of not doing superfluous work;
- the best technical requirements, design, and architecture come from a self-organized team;
- constant adaptation to changing circumstances.
"The main problem with software development was that at any stage none of the participants had complete information about what to do."
"The customer can tell you how he envisions the program, but he'll leave something out or take something for granted."
"The manager generally has to translate requirements from programming jargon to the language of the customer and back again."
"There is too much uncertainty."
"Often the customer's requirements are like this: do it in some manner, then show me — if I don't like it, then you can redo it."
"Uh... that's awful."
"According to the new paradigm, programmers are no longer developing a product or program. Instead, they are implementing the functionality the customer needs."
"What's the difference?"
"Well, suppose that program development used to take a year. And six months had to pass before there was anything to look at. It's like building a large house: first, you dig a pit for the foundation, then pour the foundation, the build the walls, roof, trim, etc."
"But now programmers try to release the needed functionality as soon as possible. This would be like first building a hut, then a mobile home, then a small house, and only then a large house—by installments."
"Considering that the customer likely doesn't exactly know what he wants, then this is a very reasonable approach."
"Suppose the customer wants a big hunting lodge."
"The developers build him a little one. He lives in it for a winter. Then he decides that he doesn't like wooden homes. Let's make one made of brick."
"He lives near the lake for a summer, but the mosquitoes eat him alive. He had heard somewhere that lakes are cool, and so he fancied having one. But now he doesn't want a lake. And it will be easier to build the house this way: no lake means no threat of floods, and you can build the house on the ground instead of on stilts, which will be 25% faster."
"An interesting analogy. Do customers really change their requirements that often?"
"Yes, but the problem isn't the customer."
"First, it's very difficult to imagine how things will turn out in the future. Managers, testers, and programmers all do this as well. They also change their minds depending on how things play out."
"Second, aren't the customer's requirements what matters most? After all, the point of all of this work is to create what the customer needs, not what he initially said to create."
"Indeed, it used to work like this: business analysts would make a list of all of the requirements. They would include this list in a contract, sign it, and work only according to the list."
"If the list was missing something that the customer really needed but had forgotten, no one would do anything about it."
"I see. It's easier to follow a plan, but not everything can be done according to a plan!"
"Exactly."
"That's why agile development methods were invented."
"And today I'm going to tell you about Scrum — the most popular among them.
"The primary feature of Scrum is the division of project development into small iterations — usually 2-4 weeks long. Each iteration is called a sprint."
"At the beginning of a sprint, a sprint planning meeting is held. It lasts 3-4 hours."
"At the end, there is a demonstration of all the fully completed tasks."
"Here's how everything usually works:"
"Before the very first sprint, the customer (or a representative of the customer) forms a list of requirements, i.e. the set of things that the program should be able to do. These requirements are usually called user stories, and the customer is usually called the product owner."
"He's called the product owner, because the product is written for him. He, and he alone, defines the list of requirements — what, when, and in what order."
"Additionally, the product owner usually assigns task priorities. Tasks with the highest priority will be implemented first. The entire list of requirements is also called the product backlog."
"When a sprint begins, everyone gathers for a meeting. The scrum master, typically a member of the team, usually leads the meeting. The meeting's goal is to select the tasks (user story) for the current sprint (iteration of development)."
"First, the team assigns each task a rough estimate in abstract man-days, also known as story points. Then the team decides how many tasks they will have time to complete during the sprint."
"Again, it is the team itself that decide how many tasks they will have time to complete during the sprint."
"Let's say the product owner expected the team to select the first 7 tasks but it selected only 5, then tasks 6 and 7 are postponed to the next sprint. If that doesn't suit the product owner, he can raise the priority of tasks 6 and 7 to ensure that they are selected, but then some of the other tasks will drop out of the sprint."
"The scrum master can also propose to break some of the tasks into smaller ones and set different priorities for them to make the product owner as happy as possible."
"That's the point of the meeting: tasks can be changed and split up, priorities can be changed, etc. This is the work that wasn't visible at the outset, but which brings a lot of value."
"Got it. It's like driving a car. Even if you initially believe you just need to go straight, the reality is that you need to constantly avoid potholes, steer right and left, and pass others or let them pass you."
"Yeah, something like that."
"The list of tasks chosen for the sprint is called the sprint backlog."
"The programmers decide who will do what, and only then do they get to work. "To improve efficiency, Scrum suggests that a 5-15 minute meeting be held every day where everyone can tell each other what they did yesterday and what they are going to do today."
"Teamwork. I can respect that!"
"To make things easier to visualize, it's usually recommended to display the current sprint status on a special board:"
"Note the three columns on the left."
"Abbreviated task names are written on sticky notes. And the sticky notes are placed in different columns depending on their status (planned, in progress, done)."
"On the right, you can see a burndown chart. For each day, this chart lists the tasks that still remain undone. Ideally, the number of incomplete tasks drops to zero during the sprint."
"When the sprint is over, the scrum-master gives a demo to show the list of everything that has been completely finished."
"Then he holds a sprint retrospective meeting, which also lasts a couple of hours. During this meeting, participants usually try to figure out what went well and what (and how) things could have been done better."
"Usually after 2-3 sprints, you can identify and eliminate the main problems keeping the team from working more efficiently. This leads to greater productivity without increasing the team's workload. This wasn't possible before the era of agile methodologies."
"Sometimes a grooming meeting is also held during the sprint. It's purpose is to plan the next sprint. Participants usually clarify task priorities in this meeting. They can also split some tasks into parts and/or add new tasks to the product backlog."
"Well, that's basically all I have. This is just an overview. It's impossible to explain it all in just a few words, but you can read a good article on the subject here:"
GO TO FULL VERSION