I decided to read the “Head First Agile” book written by Andrew Stellman and Jennifer Greene because I have been interested in learning more about Scrum, Lean and Kanban. The book introduces all of those and XP (Extreme Programming), but I’m not going to discuss XP as I am looking at the topic from the point of view of teamwork in business sector.

Mr Stellman and Ms Greene introduce Agile by explaining that agile is not a solution that suits all teams because it requires a certain mindset. Agile teams perform great because they use a set of methods and methodologies that help them deal with problems they encounter while keeping the workflow simple and straightforward. The first thing that Agile methodologies aim at is to bring the right product to customers with the use of incremental and frequent delivery of improvements and updates. The second is that work is done by small self-organising teams. The third is that since the product is frequently or constantly delivered to customers that allows the teams to receive feedback on the product and correct the course of development as needed.

Why agile can be better than waterfall

Let’s first begin by defining what is waterfall management process. According to Mr Stellman and Ms Greene it has a more rigid planning process where not only goals but also all steps that need to be taken to reach the goals are defined at the start of a project. This means that it is harder to update the project plan when new information arises after the planning phase, it is also harder to find flaws in the product as quality control is done in a late phase and the end result might not be what the client wanted. The fore-mentioned factors make waterfall a more expensive management approach to use than Agile. Why is that? It is because Agile is a team-based approach with high customer involvement where the product is delivered in iterations. This difference in approaches means that the projects are divided into Sprints which are phases where the team works for two to four weeks and then showcases the product to the customer and gains feedback. They can then take the feedback into account when planning the next Sprint and adapt their work to better meet the requirements of customers. Please see Image 1 to see a comparison of Waterfall Model and Agile.

Image 1. Comparison of Waterfall Model and Agile. © Lotz, M. Segue Technologies.

As you can see the arrows in Waterfall Model only point down from step to step it is used to illustrate how you need to complete the plan step by step and it is hard to return to a previous step. On the Agile side you can see all the steps being connected to each other with multiple lines which illustrates that each step can affect others and that you can move from step to step as needed instead of following them linearly.

Agile is best suited for projects where there is no clear and specific definition of what the project should produce as a result because in that kind of project there will be many adjustments and iterations. This kind of project also requires higher customer involvement and receiving feedback often. The first project of our team Avanteam was one where we would have benefitted from using Agile for managing the project simply because when we begun the project we did not quite know what were the full requirements of us and how the result would look like. Thankfully our client was committed to the project and was ready to give us feedback often and help us reach a great result.

What is Scrum and how could you use it in Proakatemia teams

Scrum is the most common approach to Agile and the only one that deals purely with project management. Scrum has three roles: Scrum Master, Product Owner and Development Team. Scrum Master’s task is to help the Product Owner, the Development Team and the rest of the company to understand Scrum and do it correctly. Scrum Masters usually spend all their time helping others for example they can help Product Owner manage the backlog, help Development Team to understand Scum events and removing roadblocks hindering work. Product Owner’s task is to help the team to understand what items are in the Product Backlog and why they are important to users, to liaise with customer and to accept items as “done”. The Development Team’s task is to create the product that the customer wants. It is important to note that people in Development Team can have different titles and roles but from Scrum’s perspective those roles do not exist, and they just make up the Development Team.

Scrum has a set of five values that aim to facilitate better teamwork. These values are Openness, Respect, Courage, Focus and Commitment as stated by Mr Stellman and Ms Greene. Openness is an important value because team members need to be comfortable with others knowing what they are working on and know what each other are working on so that if anyone encounters problems, they can discuss it with the team. Respect is important because it builds trust in the team and allows everyone to listen to each other and disagree with each other instead of avoiding conflict.  Courage as a value means that the teams have the courage to take on challenges and that individuals dare to stand up for their projects. Courage also allows the team to say no to external pressures on timetables or goals. Focus is an important value because it emphasises the need for all team members to be focused on the Sprint Goal and reminds them that all tasks in the Sprint Backlog should be done one at a time. Last value in the set is Commitment and it is important because every team member must be committed to delivering the most valuable product they can, but it also means that the rest of the company needs to be committed too. The company must respect and support the team’s commitment to the Sprint Goal and rules of Scrum. And give them authority to make decisions autonomously on features and what will be developed during the Sprint.

Scrum projects consist of Sprints that often are from 14 days to 90 days long with 14 days being the most common length. The Sprints consist of Sprint Planning, Daily Scrums, Sprint Review and Sprint Retrospective. The lengths of some of the meetings and sessions depend on the length of the Sprint, so Sprint Planning can be eight hours long if the Sprint is 30 days or four hours if it is 14 days. Daily Scrums are always the same length (15 minutes). Sprint Reviews are four hours long if the Sprint is 30 days long and two hours long if 14 days. And the Sprint Retrospectives are three hours if the Sprint is 30 days or 1.5 hours if it is 14 days.

Sprint Planning

Sprint Planning is a session where the whole team (including Product Owner and Scrum Master) meet to decide what can be done in the Sprint. They decide the Sprint Goal, meaning what do they want to accomplish in this Sprint. Then they move items from Product Backlog to Sprint Backlog in order to have a list of everything they will build during the Sprint. Product Backlog is a list of all features that customers would like to have, and it most likely has more features than what the team has time for in one Sprint. After the selection is done then the team will decide how the work will be done and all items from Sprint Backlog are decomposed or broken into tasks that should take a day or less to complete.

Daily Scrums

Daily Scrums are 15 minutes long meetings which are hold at the same time every workday. The whole team (including Product Owner and Scrum Master) participates in these meetings and everyone answers the following three questions: “What have I done since the last Daily Scrum to meet the Sprint Goal?”, “What will I do between now and the next Daily Scrum?” and “What roadblocks are in my way?”.  The aim of these meetings is to keep all members updated on what everyone is doing, share findings, be honest and transparent and to promote trust within the team.

Sprint Review

Sprint Review is a meeting where the team will meet users and stakeholders, demonstrate the product of the Sprint to them and receive feedback. They will then discuss the Product Backlog and what probably will be in the next Sprint.

Sprint Retrospective

Sprint Retrospective meetings are used by teams to find out what went well and what needs to be improved. Everyone must participate in this meeting so that the findings have everyone’s input. These meetings should produce specific improvements that the team can implement to perform better in the next Sprint.

Mr Stellman and Ms Greene explain that Scrum teams do not try to answer every project question in the beginning of the project or in the beginning of a Sprint. Instead decisions are made based on real information as soon as it is identified. The main reasons why Scrum teams have this kind on attitude is that they recognise that many traditionally planned projects do not finish within planned schedule and force people to work in crunch mode. So Scrum teams embrace the fact that many important decisions depend on information that will not be known until partway through the project or Sprint. This also enables Scrum teams to make changes that deliver value at any time which would not be possible with traditional Waterfall model (it would ruin the timings of the plan).

Mr Stellman and Ms Greene introduce three pillars of Scrum that function as a cycle of transparency, inspection and adaption. If the cycle is thought from the point of view of a Daily Scrum, then transparency is the fact that all work done by the team is visible to every member all the time. Inspection happens when team discusses and inspects each item that is being worked on. Inspection also allows teammates to notice if someone is doing something that does not quite make sense. Usually they will arrange another meeting for the same day and discuss it then. Adaptation happens when the team finds information that requires them to change what they plan to do next, this could be adding or removing items from the Sprint Backlog).

How could Proakatemia teams use Scrum? In my opinion it comes down to the type of project. Scrum works the best with teams of three to nine people so it would be best suited for project teams and not for whole co-operatives. Teams might find Scrum useful in projects where the client is not completely sure on what they want or when the information from the client comes in parts throughout the project or when other information is found later that affects how the work is done. Scrum allows you to adapt faster than traditional project management models and with less documentation. I see this as beneficial for the student co-operatives as it allows them to respond fast, be agile and keep costs lower. As a more tangible example a client contacts you for help in marketing and the only goals they have in mind are increasing sales and visibility. The team and client decide that what would best help the client is a new marketing plan. With agile you can begin working on the project immediately by holding a Sprint Planning meeting where you define what should be completed in this Sprint and how the completed forms look like, or what is the “done” state of those. The team will break the marketing plan into features, such as overview of the company’s advertising and marketing goals, description of their current position in marketing, define key performance indicators (KPIs), describe the company’s target market and their customers’ needs and create a timeline within which the company will implement the plan in. Those features are then broken down, or decomposed, into tasks that the Development Team pull from the Sprint Backlog and work on. About halfway through the project the customer realises that what they need is not a marketing plan but a marketing campaign plan. As the team is using Scrum and not the Waterfall model the Product Owner will go through the Sprint Backlog again and update the features as needed. He or she then discusses with the Scrum Master and Development Team what of the already done work can be used for changed needs of the client and the work continues.

Can you use Lean and Kanban outside software development?

Short answer is yes, and longer answer is yes, when applicable. The most important thing to know is that most teams that use Lean or Kanban often combine it with Scrum. According to Mr Stellman and Ms Greene, a common way is to use Kanban board along a task board because it helps to visualise workflow and can help a team to focus on getting more and higher quality work done in Sprints.

We looked at Scrum before which has values (a mindset component) and practices (a method component), Lean does not have practices and is purely a mindset based. Mr Stellman and Ms Greene describe the aim of Lean as making sure that the process the team uses is helping them build valuable products for their customers. What that means is that Lean asks teams to look at the way they are working, find out where they are running into trouble and how to correct those problems. Lean does not give teams ready answers on how to solve problems but tools that they can use. The most interesting difference between Lean teams and others is that Lean teams see all the planned work as options and not commitments. Mr Stellman and Ms Greene explain that the team is committed to the objective but not the plan which allows them to focus on meeting the objective and change the plan when they find better ways to reach the goal.

Kanban has the same aim as Lean to improve the way a team works today but it focuses on understanding how work flows through the system and encourages to experiment with small changes and work-in-progress (WIP) limits in order to eliminate wasted time and effort. The most known part of Kanban are the Kanban boards that both Lean and Kanban teams use to visualise workflow. What separate a Kanban board and a task board is not only the aim but the way the items on the board are described. Task boards have more detailed task description whereas Kanban boards have feature level descriptions. The difference is because task boards can show who is working on what task, but a Kanban board shows how much work is in progress in each state of the process. According to Mr Stellman and Ms Greene Kanban is a method for process improvement that shows the team’s actual process visually.

As both Lean and Kanban are centred on process development, they can be used outside of software industry because all industries have processes that could be improved. Mr Lombardi introduces four manufacturers who use Lean methodology in their business in his article “Good Examples of Companies that Use Lean Manufacturing”. The first of the fours is Toyota that was the first company to adopt Lean and the way they implement it two-fold. The first process they use is automating some aspects of work while having humans checking the quality of products. The second process is using Just In Time (JIT) so that next step of the process only started after the previous is completed which allows no extra or unnecessary work to be done on flawed products. The second company of the four is Intel that has seen improved quality and waste reduction. The third company is John Deere that has seen shorter manufacturing times and more optimised production amounts leading to lower need to warehouse items and lowered prices of their products. The fourth company on the list is Nike that was able to lower the amount of waste and raise the quality combined with reduction on poor labour practices. The latter is because Lean gives significant value to employees as they are more important than in some other approaches. (Lombardi, S. N.D.)

Mr Dennis introduces three non-manufacturing companies that use Kanban in his article “Lean tool of “Kanban” embraced at Pixar, Zara and Spotify”. Pixar Animation is one to the three mentioned by Mr Dennis. They use Kanban boards to make sure that their films are made in order because they found that it made it easier for staff to know how their work affects their co-workers and take more ownership of the work. The second company is Spotify that uses Kanban boards after realising that most of the work done in the company is reactive which requires them to find time for more features after the planning phase of a project. The third company is Zara that focuses on continuously updating its collections with a 15 days long design to production to shop floor cycle. Individual stores also use Kanban boards to see product flows through the selling process. (Dennis, J. 2016.)

As above-mentioned examples show Lean and Kanban are widely used in manufacturing but also in other industries. This also shows that there is not definite answer to whom Lean and Kanban are suitable. It could be argued that most industries can use them as they are designed to be used when the process of producing a product or service needs to be improved and clarified. The only way to know if Scrum, Lean of Kanban could be useful for a certain company is to investigate how the company wants to operate and what values do they want their employees to embrace. Answers to those questions can give an indication whether it is worth it to try Agile or not.

Sources:

Stellman, A. & Greene, J. 2017. Head First Agile. USA. O’Reilly Media.

Lotz, M. 2018. Waterfall vs. Agile: Which is the Right Development Methodology for Your Project?. Segue Technologies. Read on 01.04.2020. https://www.seguetech.com/waterfall-vs-agile-methodology/

Lombardi, S. N.D. 4 Good Examples of Companies that Use Lean Manufacturing. RefinedImpact. Read on 02.04.2020. https://refinedimpact.com/4-good-examples-of-companies-that-use-lean-manufacturing/

Dennis, J. 2016. Lean tool of “Kanban” embraced at Pixar, Zara and Spotify. Read on 02.04.2020. https://www.linkedin.com/pulse/lean-tool-kanban-embraced-pixar-zara-spotify-dennis-lean-six-sigma/