One minute to learn. The whole life to cultivate yourself!
This Agile cheat sheet was created to revise the various principles and practices in the Agile world, including Agile itself, Scrum, Extreme Programming, and Kanban. I tried to make the document succinct, keeping its avail. Don`t consider this text as a textbook. Use it for revisions! 😊
The word “Scrum” is taken from rugby and denotes a team game method that allows you to take possession of the ball and lead it further across the field, and this requires coherence, unity of intent and a clear understanding of the goal.
Most people in your company do their best doing their job. They want their colleagues and leaders to see that they are well performing their tasks. When someone reaches a certain level of comfort at work and knows it thoroughly, the last thing they would like is for someone to come and make them work differently. — Andrew Stellman "Applied Software Project Management"
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
- That is, while there is value in the items on the right, we value the items on the left more.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential. Keep it simple, stupid. You aren`t gonna need it. The simpler, the better.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
A Pig and a Chicken are walking down the road. The Chicken says: "Hey Pig, I was thinking we should open a restaurant!" Pig replies: "Hm, maybe, what would we call it?" The Chicken responds: "How about 'ham-n-eggs'?" The Pig thinks for a moment and says: "No thanks. I'd be committed, but you'd only be involved."
- Commitment. Members personally commit to achieving the goals of the team.
- Respect. Members respect each other to be capable, independent people.
- Focus. Everyone focuses on the work.
- Openness. A team agrees to be open about the work and challenges.
- Courage. A team has courage to do right things and point at problems.
- Scrum blames not the player, but the system that became source of the error, and corrects it. Changing team productivity gives a much greater effect than the productivity of individual employees.
- Maximum efficiency. Try to figure out how to bring the most value in the shortest time with the least effort.
- Product`s concept. This is what you can offer, sell and what you really want to do.
- Immediate value. The list of tasks is endless, therefore, tasks should be selected according to the following scenario:
- Of the greatest importance to the progress of the project.
- Most important for the customer or future consumer.
- Bring the maximum income.
- The easiest way to implement.
- Feedback rocks. Sophisticated adaptive systems focus on the environment.
- Do not flatter yourself with your plan. All shit, and it can't be worse. Make decisions at the last responsible moment.
- PDCA cycle (Plan-Do-Check-Act). Plan. Follow the plan. Compare the result with expectations. Adjust the plan and method of work based on errors. Repeat.
- OODA cycle (Observation-Orientation-Decision-Action). Determine where you are, be aware of the options available, make a choice and act!
- Elimination of losses is the first goal of management and business. Any loss in the workflow is the crime
- Consistency. Work is faster and better if you do one thing at a time.
- Finish what you started. Half done does not bring value. It is more rational to take a particular task and bring it to the end.
- Get the result the first time. Work should performed efficiently right away. Test driven development and pair programming to help.
- Hard work creates additional work. There is a limit to the number of reasonable decisions a person has per day. Tired employees are ineffective. The optimal work week is a little less than 40 hours.
- Absurdity. Unattainable goals only cause depression.
- No heroism. If heroism is needed to meet deadlines, then there is a mistake in planning.
- Overload. Avoid illogical tasks, unnecessary reporting, meaningless meetings.
- No assholes. The atmosphere in the team must be healthy. If the team has a toxic asshole, then you need to do something with it.
- The Great Team. Multifunctional, autonomous, open, free to make decisions in order to improve its capabilities.
- Team size. From 3 to 9 people. If it is difficult to understand who is doing what, then the speed of work is lost.
- Product Owner (PO). The main member of the team. Possesses high credentials in the company. He has managerial competencies and is versed in the product. And:
- Responsible for setting strategic goals.
- Identifies the main needs for the product and broadcasts them to a team.
- Understands what functionality the team could potentially deliver.
- Finds out which functionality is most valuable to customer, and which one is secondary.
- Works with a team to understand which functionality is easier to create, and which is harder.
- Uses the concept of value, uncertainty, complexity and more to help the team choose the right features for creating a product in every sprint.
- Shares product information with other company employees to help the team prepare the next version of the product.
- Scrum master. Leads the team to process improvement. Does not blame, does not punish, but collects facts and supports. Eliminates losses and provides everything necessary for working in the sprint.
- Member of a team. Together with teammates decides how to accomplish tasks. Responsible for product value. Abuses to the hallway testing, follows the principles of Extreme Programming.
- The shorter the better. Always the same size. From a week to a month.
- Customer Expectations. At the beginning of the sprint, you need to work on forming the correct expectations for the client from the next sprint.
- Stories. Story is customer expectations. It must be worded correctly: “Like X, I want Y, for to Z”.
- Backlog. List of all product stories and tasks ordered by importance.
- Scope. List of stories and tasks for the sprint from the backlog. Scope is locked. No one changes the requirements and expands the list. Intervention slows down the work.
- Definition of Ready. Each story must comply with the principles of INVEST before taking it to sprint. PO writes DoR. Example.
- Definition of Done. A list of criteria that a task must meet in order to be considered completed. DoD is written by the team in the second part of sprint planning. Example.
- Assessment of tasks. Use poker planning with the Fibonacci sequence to evaluate tasks.
- PO is responsible for the volume of a sprint. If any team member understands that the sprint is in danger, the team will immediately notify the PO. He communicates with customers - and adjusts scope. If the team understands that it will finish the sprint before the end of the sprint, then you can expand the scope from the backlog.
- Watch the dynamics. Every team should know how much work it does per sprint.
- Dynamics x time = result. Having learned the dynamics of the team, we can assume the end of the project.
- How to carry out an effective planning:
- The team answers two questions:
- What the team will deliver to the customer in this sprint?
- How the team will finish its work?
- The team follows the rules:
- Starting with backlog means starting with users.
- Be realistic in evaluating what you can deliver to customer.
- Change the plan if necessary. Plans are worthless, but planning is necessary.
- Make everyone talk about product value.
- The team follows the rules:
- The meeting is divided into two parts, up to four hours each for a monthly sprint.
- PO prioritizes backlog.
- In the first part, the PO with the team selects the stories that will be delivered at the end of the sprint, based on their significance and estimation of the amount of work. Estimation is based on poker planning with the Fibonacci sequence. For each story DoR is formulated.
- The team captures Scope and promises to show the product at the end of the sprint, including the entire Scope.
- In the second part, the team splits stories into individual tasks that will actually be performed. For each task, DoD is formulated.
- The team starts to work. No tasks distributed at the start of the sprint. Each person independently takes the next task as soon as he finishes the previous one.
- Linus`s law. With enough eyes, every errors lie on the surface.
- Rules. Performed standing. At the same time in the morning. At the scrum board. No more than 15 minutes. The whole team must be present. The presence of users and stakeholders is encouraged, but they should not interfere.
- Principles. The team must follow the following principles:
- Take the example from the Pig.
- Lead a discussion about the tasks live.
- Alternate the right to direct the work of the team. Choose a host.
- Do not take it as a ritual.
- Everybody participates.
- Do not treat this as a status-meeting.
- Check every task.
- Change the plan, if necessary, with the participation of PO.
- Questions. Scrum-master sets the following the questions:
- What did you do yesterday to help the team complete the sprint?
- What will you do today to help the team complete the sprint?
- What are the barriers to the team?
- Changes. Next, the team updates the scrum board and graphics. If questions arise that require discussion, an additional meeting is immediately organized.
- Demonstration. At the end of the sprint, the team demonstrates working product and listen to criticism. So team understands what has been done wrong and what the client wants.
- Done. No tasks are considered to be completed without endorsement of software and customers.
- Changes. If changes are necessary, they are taken into account when planning the next sprint.
- Friendliness. No one should take defensive position.
- Sprint questions. It is not a product that is being discussed, but how the team worked. Therefore, each answers the following questions:
- How to improve collaboration in the next sprint?
- What obstacles were in this sprint?
- Why are we not progressing as fast as we want?
- Index of happiness. If you carefully monitor the index of happiness, then you can immediately note the future discord in the team and quickly fix it. Therefore, each participant must answer several questions on which you can schedule a team satisfaction:
- Rate your role in the company on a scale from one to five?
- Rate the company in general from one to five?
- Why do you think so?
- What is the thing that will make you happier in the next sprint?
- Non-functional backlog. Scrum-master notes all the improvements that have occurred since the last sprint. All requests for process improvement should be made out as non-functional backlog elements.
- Scrum board.
- Burn down chart. It can be built for both the sprint and the entire project.
- Happiness chart. Based on the results of questions during retrospectives, you can build a chart of the index of happiness.
This is the essence of programming. The actual question is, are you really sure that the code you just wrote works?
- Communication. Each team member knows what the rest are doing.
- Simplicity. Developers try to create the simplest and most direct solution.
- Feedback. Continuous testing and feedback.
- Courage. Each member of the group aimed at choosing the best solutions for the project, even if it means abandoning unsuccessful decisions or requires some kind of approach.
- Humanism. Remember that software is created by people and there is a balance between the needs of each team member and the project itself.
- Economy. There is always someone who pays for the development of software, and everyone should consider the size of the budget.
- Mutual benefit. Look for practices that benefit the individual programmer, team, and client at the same time.
- Similarity. Monthly, weekly and daily cycles are built according to one pattern.
- Improvement. Perform today's task as well as possible and think about how to make tomorrow work even better.
- Diversity. Combine different opinions and views to get the best result.
- Reflection. During the development of software, good teams constantly discuss the correctness of their actions to implement the project.
- Flow. Continuous delivery means the continuous delivery of developer work results, not divided into stages.
- Opportunity. Every problem facing the team is a chance to learn something new about software development.
- Redundancy. Although at first glance this may seem wasteful, redundancy avoids serious quality problems.
- Failure. Failures can teach a lot. There is nothing wrong with trying approaches that don't work.
- Quality. It is impossible to ensure the speed of delivery by reducing the quality of the product.
- Acceptance of responsibility. If someone takes responsibility, then he must have the authority to fulfill the promise.
- Small steps. It is better to take small steps in the right direction than to make grandiose changes when introducing new methods.
- Test Driven Development.
- Pair Programming.
- 10 minute build. The team creates an automated assembly for the entire code base, which lasts 10 minutes. This assembly includes the automatic launch of all tests and the generation of reports on them.
- An adjusted CI/CD.
- Weekly development cycle. Same as Scrum Sprint.
- Quarterly cycle. Same as Scrum retrospective, only every 3 months. Some XP teams just do retrospectives at the end of every second week.
- Temporary stock. The team adds small, lower priority stories to each weekly cycle. During planning, they are divided into tasks, but they are not started until the end of the sprint. And then, if a team encounters unexpected problems, it excludes these “spare stories” from the iteration and still delivers a working product at the end of the sprint.
- Coallocation. The team is located in the same room, since developers are required high social activity.
- Informative workspace. The team’s work environment is designed so that important project information is shared with all participants. The use of a large task board and a burn down chart that hang so that everyone can see them.
- Osmotic communication. Discussions take place in a common workspace, and not in closed conference rooms. As a result, others involuntarily hear them and absorb information about what is happening.
- Get rid of a smelly code. Correction of technical debt through ruthless refactoring.
- Incremental architecture. This is an architecture created from the work of small independent modules. The adoption of architectural decisions at the last responsible moment makes it possible to avoid trying to create everything at once. Thus, any team member is convinced that it is faster to create a small unconnected part of the system today and entrust the team with making corrections in the future. Closely bordered by TDD and the pursuit of simplicity.
- Energetic work. This is the creation of an environment in which each team member has enough time and freedom to do their job. This maintains their mental state in which they are able to develop and use good habits leading to better, naturally replaceable code. In this state, they can produce much more code and deliver more valuable features to consumers in less time.
- One team. Overcoming obstacles and making decisions that affect the direction of the project are taken jointly. All team members learn to trust each other and determine which decisions can be made independently and which decisions can be made by the team as a whole.
If stupid enters the room, you have a moral duty to shoot it, no matter who's escorting it. — Keoki Andrus, Beautiful Teams
- Eliminate losses. Identify the work that do not create value, and get rid of it.
- Strengthen training. Use feedback to improve your work.
- Make your decision as late as possible. Make all the important decisions about the project, having a maximum of information about it - that is, at the last responsible moment.
- Deliver value as early as possible. Analyze the real cost of delays and minimize it with pull systems and queues.
- Unleash your team. Create a focused and efficient work environment and bring together energetic people.
- Achieve integrity. Create a product that is intuitive for users and works according to their expectations.
- Watch the big picture. Try to thoroughly understand the work that your project is doing. Use the correct measurement methods to make sure that you really see even the smallest details.
Leaders tend to demand commitment, and teams often overstate them. Backlog elements can be perceived by the team as obligations because they were discussed during sprint planning. But these are not obligations, but options. We know this because PO can remove them from the sprint. It is necessary to separate the true commitment (delivery of a valuable working product) from the optional variants (providing specific functionality by a certain date). Thus, several variants for the implementation of the functional can exist on the board, which gives the team more flexibility.
- Partially done work.
- Additional processes.
- Extra features.
- Switch between tasks.
- Expectation.
- Extra movements.
- Defects.
Use the five “whys” method to get to the root of the problem.
5. Pull system.
A way to execute a project or process that uses queues to remove obstacles.
Kanban is not a project management system. This is a method to improve the development process: the steps that the team takes to improve the creation and delivery of the product.
Search for recurring problems, find out their commonality and create correction tools.
Each team has a production strategy to create a product. It is chaotic and often changes. Define it and begin evolution.
This is a unit of work at Kanban. This is usually a story from Scrum.
The speed with which work items move around the system. When a team finds the optimal pace for delivery combined with convenient feedback, it maximizes flow. Reducing uneven work and congestion, the ability to complete one task and only then move on to the next increases the flow.
- Start with what you are doing now, respect your roles, responsibilities and job descriptions.
- Agree on evolutionary development.
- Encourage leadership at all levels.
- Visualize.
- Limit the number of tasks in work (WIP).
- Control the flow.
- Make the rules explicit.
- Enter feedback loops.
- Develop together and experiment (use modeling or a scientific approach).
- Kanban board. A tool that a team uses to visualize a workflow. It must be conducted according to the following principles:
- Adaptation. Form it for your product delivery strategy.
- Content. Kanban-board contains only stories and does not show tasks.
- WIP limits. For each column, a workload limit can be set.
- More details. All about how to run a kanban board.
- Cumulative Flow Diagram (CFD). What is it and how to use it?