Complete Agile Fundamentals: Scrum and Kanban

Lets discuss why waterfall approach may not work properly sometimes.

Not all project fit Agile approach. Lets find out which projects fits Agile properly.

10 000  feet Scrum overview before we dive into details of Scrum

What are the roles in Scrum and what these roles are responsible for.

What are some other roles that may be involved into Scrum project and how it works together

Scrum ceremonies or events described step by step - when to hold meeting, who joins particular meeting, what time limits are recommended. what techniques may be applied

Scrum Retrospective - the way to improve your team efficiency. But how?

Lets talk more about retrospective because I think this is the most confusing part of the scrum. You probably can imagine how to run sprint demo, sprint planning, daily scrum but retro is confusing.

If done right, retro can highlight opportunities for change, generate meaningful process improvements, and ultimately move the team in the right direction. If done poorly, a sprint retrospective can turn into a blame game.

Artifacts or objects of the Scrum - what they include and how to work with it.

We have looked at roles, Scrum events. Now let's take a look at Scrum artifacts.

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team. Simply it is just a to do list for a team with priorities.

The Product Backlog is the main artifact of Scrum, it contains all the requirements for the product in a prioritized form. In a prioritized form means the most important elements are at the top, the least important are at the bottom. Responsible for filling is Product Owner together with the scrum team. This is dynamic document that is constantly changing, some elements are added, some elements are removed or changed.

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

A sprint backlog is a piece of a large product backlog that a team takes into work for 1 sprint. All elements of the sprint backlog must have estimated to go through a full cycle of creation, that is, design, development, testing and deployment on a production server. This is your to do list for 1 sprint that you discuss with product owner on planning session and commit you will complete by the end of the sprint. Sometime for some reason you may not complete all sprint backlog element and that’s OK but most of the time you should complete all of them or something wrong with you planning approach.

Increment - everything that the team managed to complete during the sprint and everything that is ready to be delivered to the customer or user as a result of the sprint.

A work cannot be considered part of Increment if it is not ready for delivery in the full sense of the word - if the documentation is not completed or testing is not carried out.

Now you probably have a question - how to write a Scrum Backlog? What does it look like?

This is a template in which it is quite easy and simple to capture business requirements. The template looks like this. As a <persona or role>, I want to <state what is required>, So that <why you need it, state a reason for the feature>

Acceptance criteria is what really good teams do in order to have clear objectives and satisfied customer. Every Scrum User Story should have acceptance criteria that can be tested and demonstrated. It is desirable to have binary parameters, that is, PASS or NOT PASS. There should be several such parameters for each User Story. About 3-5 is recommended.

Definition of Done, Working Agreement and other important points of Scrum

How to estimate users stories or tasks in Scrum? How to compare? What techniques to use?

Lets talk about why it is important. First of all estimation provide you with estimated duration for the tasks of feature or project to be completed. Then you can use it for planning and moving forward.

The second important thing is that estimating helps to dive into clarification. When product owner states a requirement in order to estimate it you will have to ask quite a lot of questions to make sure that you understand everything clearly and can make precise estimate on complexity of the feature and what is more on duration. This is a very important part of the Scrum

Any project must be monitored somehow. But how to do it with Scrum project?

Now let's talk about estimating in Agile. How tasks are estimated. But before that, let's remember how tasks are evaluated in the waterfall management model. There is usually a task there, it is given to the developer or another team member and he responds after some time, task A will take me 5 days, and task B will take 11 days. Thus, the project schedule is built. Each change in task scoring can have a big impact on the project as a whole, especially if the task is on the project's critical path.

In Agile, estimation is relative. That is, we compare the sizes of tasks with each other.

What is kanban. Lets make it clear that Kanban is not a framework like Scrum and therefore does not have clearly defined roles, procedures and events. If you have seen sticker boards in the IT industry - in development or support, then it could very likely be kanban. It is absolutely not forbidden to use boards with tasks in Scrum. And its called Scumban but scrumban is not covered in this course because its kinda complex and sophisticated framework for experienced agile people.

Kanban is based on Lean philosophy, we'll talk about that in a minute. They say that kanban was created in Toyota in the production of cars. As Wikipedia says, this is a system for organizing production and supply, which allows you to implement the principle of "just in time". The word "kanban" in Japanese means "billboard, signboard." The goal of its use in Toyota was to minimize inventory and smooth the flow of production so that it becomes and predictable and easy to forecast. To do this, they used flags or pieces of paper with notes at each step of the pipeline, showing how much details is needed right now to complete the current plan.

Central to the definition of Kanban is the concept of flow. Flow is the movement of value through the product development system. Kanban optimizes flow by improving the overall efficiency, effectiveness, and predictability of the process. Flow optimization in the context of Scrum requires a definition of what flow is in Scrum. Scrum is based on empirical process management theory or empiricism. The key to experiential process control is the frequency of the transparency, inspection, and adaptation cycle, which we can also describe as Cycle time through the feedback loop. When Kanban practices are applied to Scrum, they focus on improving flow through the feedback loop; optimizing transparency and frequency of inspection and adaptation for both the product and the process.

From practical point of view Kanban is about board and stickers for tasks. It may be physical board in the office with stickers hanging on the appropriate column on the board or virtual one.

The easiest way to start using virtual board is Trello.com (написать). Its completely free and available online or as an app for your phone. Another good one is Jira, it has more features but it is not free.

So once you have board and tasks up and running its time for improvement. These are 4 Kanban practices which actually self explanatory.

•Visualization of the Workflow – which is board itself. Visualization using the Kanban board is the way the Team makes its Workflow transparent.
The board's configuration should prompt the right conversations at the right time and proactively suggest opportunities for improvement.

•Limiting Work in Progress (WIP) – as I said before – no more that 2 tasks at a time for 1 person. Depending on you environment you you may and should set up your own limits and policies in this regard.

•Active management of work items in progress – which is analyzing what’s going on. Do tasks get stuck in 1 stage for too long or is there too many tasks in a single stage. You have to analyze it, find the root and improve the flow.

• Making sure that work items are only pulled into the Workflow at about the same rate that they leave the Workflow.
• Ensuring work items aren't left to age unnecessarily.
• Responding quickly to blocked or queued work items as well those that are exceeding the team’s expected Cycle Time

•And finally - Inspecting and adapting the team’s Definition of Workflow – looks like retrospective on Scrum.

So to sum up

How proper Kanban look like and what properties does it have

•The flow moves evenly and smoothly

•On average, it takes about the same time from the start of a task to its completion. There are no variations from a couple of hours to several weeks;

•There are few tasks in the system at the time;

•No more than 2 tasks per person;

A person should not work on several tasks at the same time. It is allowed that he takes the second one, if the first one is waiting for something - checks, updates on the server, and so on. Remember that switching between tasks is a waste?