{{announcement.body}}
{{announcement.title}}

Agile and Lean Startup - Part 2

DZone 's Guide to

Agile and Lean Startup - Part 2

Let's look at the ever-evolving space of lean and agile developments and provide you with a collective study that will help us understand the evolution.

· Agile Zone ·
Free Resource

Hope the first part of the series gave a good overview of Agile and Lean Developments. For those who missed the first part here is a reference.

https://dzone.com/articles/agile-amp-lean-startup-part-1

This chapter we would be looking into Scrum and Kanban, two of the most popular methods used widely to realize Agile.

Scrum

Scrum is considered to be one of the important agile approaches used for developing new products or services. Scrum lets the team do the work in short, time-boxed iterations, which usually range from a week to a calendar month in length. Scrum stresses on a small self-organizing, cross-functional team having all the competencies to do the work. The Scrum Team keeps delivering the products iteratively and incrementally allowing a useful working version of the product readily available. (Ken Schwaber and Jeff Sutherland (2012)

Every Scrum development effort is made of one or more scrum teams and three major scrum roles.

  • The Product Owner is the single authority who is empowered to decide what will be developed and in which order. 
  • The ScrumMaster is responsible for guiding the team, promoting, and supporting the Scrum framework. 
  • The Development Team is responsible for delivering a releasable increment of the product as mandated by the product owner.

Scrum uses few prescribed events to operate regularly and to cut down on unnecessary meetings.

Refer: https://www.visual-paradigm.com/scrum/what-are-scrum-ceremonies/

Sprint  

The heart of Scrum is a Sprint, which is a time-boxed event and a period during which a useable and ideally releasable Increment of the product is available. Once defined, any changes to sprint goals are not allowed. Every Sprint is made of the following events Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

Sprint Planning  

Sprint Planning happens at the start of the Sprint and answers the following questions:

  • Items that could be delivered in the upcoming sprint and related discussions.
  • Plans and discussion on delivering the agreed increment

Daily Scrum

The Daily Scrum is a 15-minute meeting for the Development Team. The team shares the progress and makes plans for the work for the next 24 hours.

  • What I did the previous day would allow us to meet the Sprint Goal?
  • What I will be doing today to meet the Sprint Goal? 
  • Any impediment that is stopping me or the Development Team from doing my work?

Sprint Review  

A Sprint Review is usually held at the end of the Sprint and the features of increment are seen and changes are made to the Product Backlog on a need basis. The entire Scrum team discusses things that were done in the Sprint, presents the work that is done, and solicit feedback. The attendees discuss any changes to the Product Backlog for the next Sprint.

Sprint Retrospective

Sprint retrospective happens at the end of every sprint and the Scrum Team reflects on the things that have gone good and bad and create a plan for improvements. The team consistently reflects on its activities, identifies improvements, tracks them, and makes sure that these improvements are enacted in the subsequent sprint.

Product Backlog  

The Product Backlog has the set of items that are needed in the product and is actively maintained by the Product Owner. The product backlog has a description, order of preference, a rough estimate, and the value. 

Sprint Backlog

The Sprint Backlog has only the specific items picked from Product Backlog for the current sprint, the sprint goal, and the details of execution. 

Scrum Versus Agile  

Scrum as we see is a generic process that came even before Agile. However, I do see how the process could be mapped against the agile principles. 

 Table 1 Scrum Versus Agile

Agile Principles


Scrum


Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.


 


Scrum operates using the concept of Sprint, a time-boxed duration where potentially releasable product Increment is created. 


 


Businesspeople and developers must work together daily throughout the project.


The Product Owner in Scrum represents the business side and acts as a liaison between a variety of business stakeholders.


Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.


“Development Teams are structured and empowered by the organization to organize and manage their work.” Ken Schwaber and Jeff Sutherland (2017)


 


 


The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.


The daily standup acts as an explicit opportunity for the business stakeholders represented by Product Owner and developers to have frequent face to face conversation,


Working software is the primary measure of progress.


By its nature, a working increment is delivered at the end of the sprint and the product backlog tracks against the working items.


Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.


The very nature of a well-defined scrum process allows for sustainable development.


Continuous attention to technical excellence and good design enhances agility


This isn’t explicitly covered anywhere in the Scrum process but for teams to follow.


Simplicity--the art of maximizing the amount of work not done--is essential.


All of the work items in terms of what features are needed is to be decided by the product manager. The actual team doing the work could decide on its implementation as to what it needs and not.


The best architectures, requirements, and designs emerge from self-organizing teams.


The scrum team by definition is self-organizing and are empowered to manage their work,


At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.


During sprint retrospective that happens at the end of every sprint, the Scrum Team reflects on the things that have gone good and bad and creates a plan for improvements


Scrum has proven to be extremely effective in delivering iterative and incremental software and is more and more used by many product and service teams.


The Kanban Method

The word Kanban which means signaling was originally used in Toyota Production System, a method that makes sure that necessary parts are made and delivered at the right time whenever it is needed. The production process is designed to produce only what is deliverable, making the business leaner by not holding excessive stocks of raw material or inventory of finished goods. Kanban establishes an upper limit to work in process inventory to avoid overcapacity. By limiting the number of items waiting, deeper inefficiencies are identified and removed, Kanban is used in conjunction with kaizen (“continuous improvement”) process. Kanban Method is also known colloquially as Kanban tries to apply the original concepts from manufacturing tailored to knowledge work. Kanban software development can be used to identify and make improvements to the existing processes.


Refer: https://www.integrify.com/blog/posts/kanban-project-management/


The core of Kanban could be explained by the following outlined steps:

  • Visualize your work. Many different works that a development organization does to satisfy a stakeholder’s request is mapped. 
  • Define the input. This includes defining the upstream stakeholders. Ex: Product manager could be an upstream stakeholder
  • Define the exit point beyond which the team has no control. That is defined as downstream and downstream stakeholders.
  • Identify the type of work and define different classes of service each having their priority. Eventually, every class of service would have its Service Level Agreement.
  • Analyze the demand for each work item type. Identify the risks, variability, tolerance limit, and create an appropriate risk profile for demand.
  • Meet regularly with upstream and downstream stakeholders and get a broader consensus on work in progress (WIP) limit.  
  • Placing limits on the WIP  allows teams to first finish the work that currently needs to be done before taking any new work. Multiple work items have done concurrently cause inefficiencies and by limiting the work that is being done we attempt to create the capacity to pull new work when appropriate.
  • Agree around how new requests would be frequently prioritized. Regular prioritization meeting with upstream partners.
  • Agree on a standard release mechanism with downstream stakeholders to allow the release of software regularly.
  • Create a visual board as to items controlled within the development team. Once you build a Kanban board that is fit with cards, it makes it easy to spot and tackle bottlenecks in them.
  • In front of the Kanban board, Teams would meet regularly as a form of standup meeting.
  • There would be regular review meetings for retrospective analysis.
  • All of the team's existing process remains the same except the team is now educated with a new board, WIP limits, and the pull system.

Properly implemented, Kanban implementation would frequently deliver high-quality working software. Both Customers as well as stakeholders would have complete visibility into the workings of the process and could offer suggestions to improve. Frequent meetings are held to ensure that important new items are selected for development. By limiting WIP, teams are devoid of distractions and complete work items faster by avoiding costly context-switching and multitasking.

Kanban Versus Agile  

We would attempt to see how the Kanban process could be mapped against the agile principles. In general, teams tend to use Kanban in places where teams need to highly interrupt-driven and reactive like support and maintenance projects.

 Table 2 Kanban Versus Agile


Agile Principles


Kanban


Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.


 


Teams agree on a standard release mechanism with downstream stakeholders so that regular software released


 


Businesspeople and developers must work together daily throughout the project.


Meet regularly with upstream and downstream stakeholders and get a broader consensus on work in progress (WIP) limit.  


 


Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.


The teams collectively own the visual board and have total visibility and opportunities to improve the process.


 


 


The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.


The daily standup acts as an explicit opportunity to have frequent face to face conversation,


Working software is the primary measure of progress.


Working software is delivered frequently as teams would still have the WIP limits for items to be released and not releasing them is going to cause red herrings.


Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.


By limiting WIP teams are devoid of distractions and complete work items faster by avoiding costly context-switching and multitasking. Also, the teams are only taking work that they could handle.


 


Continuous attention to technical excellence and good design enhances agility


This is more for teams to imbibe the agile mindset and follow.


Simplicity--the art of maximizing the amount of work not done--is essential.


The WIP limits automatically force the stakeholders to a pull model where they have to constantly evaluate what work needs to be done instead of a push model where the team is asked to do as much work as possible. The pull model leads to maximizing work that does not need to be done.


The best architectures, requirements, and designs emerge from self-organizing teams.


Kanban is just a visualization technique and process-driving tool and doesn’t mandate how teams need to be structured,


 


At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.


There would be regular review meetings for retrospective analysis. Kanban promotes teams to use their quality processes like six-sigma in conjunction with Kanban.


 


 

We could quickly see that in most places we have taken the idea of Kanban boards and use them in conjunction with Scrum along with concepts like poker cards used to assist planning. Hopefully, this part in conjunction with the first part would have given a good background about Agile and the methods. In the next part, we would be looking into Lean Startup Methodology and what it offers.

Topics:
software development

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}