How to "Agile?" - full script

Crucial assumption to begin with

This document by definition does not cover every detail of every topic that is mentioned inside of it. This is an intro to Agile as a concept and an intro to  certain Agile frameworks that may be useful in software development (Scrum, Kan-Ban & ScrumBan).

Knowledge Base is growing which means that this document may change scope or new, separate documents will cover certain topics more deeply.

Last but not least - please look deeply at the last section of this document (“Useful knowledge sources - books/essays/websites/YT channels etc. “) where you can find multiple knowledge sources. Some of them (books) are in Sailing Byte’s library rest is accessible completely free on the internet!

Why is Sailing Byte trying to learn, implement (if needed) and share knowledge about Agile? 

Currently Sailing Byte it’s under processes of both product restructuring & agile adaptation. We have recognized that there are potential organizational benefits in introducing agile frameworks to our ongoing software development projects. 

Ultimately we want to deliver high quality code (therefore more value to end customers) with a more predictable pace through the whole portfolio of projects. To obtain that goal we may have to change the way we work & cooperate with certain stakeholders. We are still learning how deeply we can apply those changes in various projects.

Sharing knowledge about Agile methodologies to both existing & future Sailing Byte clients works only beneficial. It’s a clear win-win situation when both sides understand from the very beginning how the whole process looks like and what are the benefits of a certain approach.

Hopefully 2021 will end for Sailing Byte as a year of important changes that allow our organization to grow & constantly

What do “Agile'' mean in context of software development?

Term agile means to be “able to move quickly and easily.”  World of software development of 80’ and 90’ was far from being able to quickly and easily manage any changes. Every business need for new software had to follow a strict “Waterfall” path of development.

There is nothing bad by definition with this (Waterfall) approach. It’s perfectly reasonable to work all stepps (requirements, design, implementation, verification, maintenance) one by one. For example when you would be asked to build a bridge there would be nothing bad in first gathering requirements (who needs that bridge and for what), then designing it (making a strict technical plan) then implementing that plan exactly as planned (start construction work). Finally you will have to cover verification (check if that bridge is safe and serve its purpose) and maintenance (make sure that bridge will not collapse and will be useful for end customers in the next 100 years). 

Bridge has to be built with a constant set of requirements to serve its needs which can happen only if you will finally build the whole bridge. There is no value for the end customer in a bridge done 65% or even 99.9% To deliver value faster you can’t change plans in the middle of construction work. It’s rather obvious.

If you will apply this (waterfall) method to software development it will be clear that the end customer will have to wait for value until the very end of a whole process. You will have to know all requirements at the very beginning and you will not be able to change them unless you are ready to handle all the risks that come with a possible 2-3x times longer development period. (budget waste, waste of company production capacity, pressure from stakeholders etc.)

Now let’s ask yourself if the world is changing now in 2021 faster than it Was changing in 80’-90’ ? Do customers change their behaviours and choose different applications to solve their problems/needs more frequently ? Do product’s have to change more frequently due to that “world acceleration” ? 

Answers to those questions are rather obvious but imagine that there was a brave group of software engineers who saw that the world is “accelerating” way faster than the others. Those American & English software engineers proposed in february 2001 “Manifesto for Agile Software Development” (later “Agile Manifesto”) - a bald statement that changed the future of software development. 

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• 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.

___________________________________________________________

Moreover that group of engineers proposed a list of 12 principles behind the  Agile Manifesto .
_______________________________________________________________
            We follow these principles:

• 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.
• 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.
  
  

more about Agile Manifesto:
Agilemanifesto.org

___________________________________________________________

Combination of such a manifesto and it’s principles had a tremendous impact  on the world of software development. There was an urge inside of industry “biggest brains” to get rid of “waterfall” as the only way to produce software. 

Approach that they proposed gives a main advantage in the form of faster delivery of value to the end customer combined with faster feedback. As a result we are now able to lower the risk that comes with delivering a project that at the end of the development process will NOT cover end customer needs.
Those needs can change at any time and they will change only more frequently in the 21st century. 

Agile frameworks in software development.

“Agile” as defined above approach to software development is not prescriptive which means that it’s not by itself defying exactly HOW to obtain agility. Through the last 40 years there were many approaches (with better and worse results) to creating a concrete guidebook or framework that will tell exactly how to obtain agility in organization.  Some of those frameworks were formalized even before Agile Manifesto (2001) but in their most updated versions they are in line with manifest’s message. 

Scrum and it’s foundations (Transparency, Inspection & Adaptation).

Scrum as a complete framework for software development was first described and formalized by two American practitioners of software engineering Jeff Sutherland & Ken Schwaber in 1995. (Ken Schwaber Was one of the engineers that originally created “Agile Manifesto”).

Most recent update of Scrum Guide (a document describing Scrum) took place at the end of 2020 and changed the concept of Scrum as a framework that may be used not only in software development. You can find all information about Scrum (Scrum Guide, training, certifications, knowledge base etc.) on www.scrum.org.

Scrum: 

• founded on Empiricism to asserts that knowledge comes from experience and making decisions based on what is observed. 
• founded on Lean thinking to reduce waste and focuses on the essentials.
• employs an iterative, incremental approach to optimize predictability and to control risk;
• engages groups of people who collectively have all the skills and expertise to do the work and share or acquire such skills as needed.
• combines formal Scrum Events (2.1.1) for inspection and adaptation within a containing event, the Sprint.
• these events work because they implement the empirical Scrum pillars of transparency, inspection, and adaptation

Transparency:
- process and work (Scrum Artifacts 2.1.1) must be visible to those performing the work as well as those receiving the work;

Inspection:
- Scrum artifacts (2.1.1) and the progress toward agreed goals must be inspected frequently and diligently (during Scrum Events 2.1.1.) to detect problems early.
- inspection without transparency is misleading and wasteful.
- inspection without adaptation is pointless (Scrum has to provoke change);

Adaptation:
- Anty adjustment must be made as soon as possible to minimize further deviation.
- Adaptation becomes more difficult when the people involved are not empowered or self-managing. 
- A Scrum Team (2.1.1) is expected to adapt the moment it learns anything new through inspection; 

Scrum Framework, Events, Artifacts, Scrum Team & roles Responsibilities. 

Scrum Team = Product Owner + Scrum Master + Developers 

____________________________________________________________________________

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

1. A Product Owner orders the work for a complex problem into a Product Backlog 
2. The self organizing Scrum Team turns a selection of the work into an Increment of value during a Sprint.
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
4. Repeat
   

As you see it’s not a very complicated process but for scrum to operate properly there have to be proper definitions (and understanding of those definitions) of a) Scrum Events, b) Scrum Artifacts and c) Scrum Team Roles & Responsibilities , d) Stakeholders Responsibilities

a) Scrum Events:

• create regularity and minimize the need for meetings not defined in Scrum;
• are time-boxed to not allow waste of time;
• It’s totally OK to organize other, non-scrum events/meetings as long as they serve their purpose and are not a waste of time;
  

Sprint - (Scrum Team):
Scrum Event that is time-boxed to one month or less, that serves as a container for the other Scrum events and activities. Sprints are done consecutively, without intermediate gaps. 

Sprint Planning - (Scrum Team):
Scrum Event that is time-boxed for a maximum 4-8 hours (or less). During it Scrum Team (product owner+developers+scrum master) inspect the work from the Product Backlog that’s most valuable to be done next and design that work into Sprint backlog.

Daily Scrum - (Developers):
15-minute time-boxed event held each day. During it developers are planning work for the next 24 hours and are inspecting what was done in the last 24 hours to better predict if Sprint Goal is achievable. The Daily Scrum is held at the same time and place each day to reduce complexity

Sprint Review - (Scrum Team + Stakeholders):
Maximum 4 hour event to conclude the development work of a Sprint. During it Stakeholders inspect the Increment of product resulting from the Sprint and assess the impact of the work performed on overall progress and update the Product backlog in order to maximize the value of the next period/sprint. 

Sprint Retrospective - (Scrum Team):
Maximum 3 hour event to end a Sprint. During it Scrum Team inspect the past Sprint and plan for improvements to be enacted during the next Sprint.

b) Scrum Artifacts:

• represent work or value to provide transparency and opportunities for inspection and adaptation;
• are specifically designed to maximize transparency of key information so that everybody has the same understanding of artifact’s state; 
• every artifact is owned by somebody who is responsible for it: 

Product Backlog - (owned by Product Owner): 

• Consists an ordered list of the work to be done in order to create, maintain and sustain a product. Managed by the Product Owner who is responsible for clearly stating Product Goal.

Sprint Backlog - (owned by Developers): 

• Scrum Artifact that provides an overview of the development work to realize a Sprint’s goal, typically a forecast of functionality and the work needed to deliver that functionality. Managed by the Developers.

Increment - (owned by Scrum Team): 

• Defines the complete and valuable work produced by the Development Team during one Sprint. Work cannot be considered part of an Increment unless it meets the Definition of Done. The sum of all Increments form a product
  

c) Scrum Team Roles & Responsibilities

• define who is responsible for what and why;
• within a Scrum Team, there are no sub-teams or hierarchies. It is a cohesive unit of professionals focused on one objective at a time, the Product Goal.

 Developers:   

• Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint;
  
• specific skills needed by the Developers are often broad and  will vary with the domain of work
  
• Create a plan for the Sprint, the Sprint Backlog;
• apply Definition of Done;
• Adapting their plan each day toward the Sprint Goal
• hold each other accountable as professionals.

Product Owner

• Entire organization (including Stakeholders) must respect 
• Product Owner decisions!
• The Product Owner is one person, not a committee. 
• The Product Owner may represent the needs of many stakeholders in the Product Backlog. 
• Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.
  
  

Product Owner responsibilities

• accountable for maximizing the value of a product by managing and expressing business and functional expectations for a product to the Developers;
• Developing and explicitly communicating the Product Goal;
• Creating and clearly communicating Product Backlog items;
• Ordering Product Backlog items;
• Ensuring that the Product Backlog is transparent, visible and understood.
• Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

Scrum Master:

• accountable for guiding, coaching, teaching and assisting a Scrum Team, Key Stakeholders and its environments in a proper understanding and use of Scrum.
• creating Definition Of Done and maintaining it.
  

• a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for it’s incremental development (it will be mostly Product Sponsor/Inventor but may be also customers in B2C model); 
• Stakeholders have to be represented by product Owner (or they have to delegate his responsibilities to someone); 
• They must be actively engaged with the Scrum Team at Sprint Review; 
• Stakeholders must respect Product Owner’s decisions!

Definition of Done (DoD)

• formal description of quality measures that are required for product backlog item to become and Increment 
• If a Product Backlog item does not meet the DoD, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

Scrum Values 

Is it harder for Scrum Master to implement a certain framework of “how we work” or to change the whole company culture ? Company culture it’s something that is defined mostly at the very beginning of its existence thus the hardest part of a Scrum Master job during implementation of scrum is to “foster an environment”.  This means to lay strong foundations in company culture for Scrum to even occur. Those foundations are: Courage, Focus, Commitment, Respect & Openness.

Summary: Pros, cons of Scrum 

Scrum provides a clear iteration structure for:
a) developing and sustaining complex products (for example software development);
b) smooth delivery of value to end customer;
c) creating a feedback loop from end customer to production team
d) adapting to changes in product requirements

Pros of Scrum: 

a) Scrum specifies precisely how to set an iteration structure for product development. If company does not have any structure for product development Scrum it’s most probably the easiest way of introduction to Agility (if Agile is a valuable concept for development of such a product);

b) Scrum gives a chance to adjust if change of product requirement Existence of time-boxed Sprint restricts those most recent changes to be agreed only during every sprint planning (we should avoid to change requirements during ongoing sprint!). This helps a lot if we are working with a Client who is constantly shifting his approach to every piece of planned development thus we are suffering from the cost of constant context switching & non-stop research. Convincing that Client to use Scrum and maintaining it it’s a good way to make your product better.

Cons of Scrum:

a) Scrum specifies precisely how to set an iteration structure thus it’s tempting to just apply it and not think about consequences. It may seem easy to apply Scrum everywhere but in reality the most challenging part is to change behaviour of people that are using this framework. Focusing constantly only on some aspects of Scrum may result in Cargo Cult. 

b) Scrum gives a chance to adjust if change of product requirement But what if gathering feedback from client/project sponsor is made only during sprint review at the end of the 4-week sprint?  It is highly probable that requirements have changed but developers had no idea about it and delivered increment that have some value but could have way more value! Adaptation to changes of requirements do not magically happen just by applying scrum or any other framework. If values like transparency and openness are not cultivated in organization adaptation to any change will be almost impossible.

KanBan and it’s foundations (JIT & Lean)

KanBan first emerged in post II World War Japan as a very important component of “Toyota Production System”, a groundbreaking shift in approach to production process management in car development. This system know also as JIT (just in time) was invented & implemented in Toyota by group of engineers led by Taiichi Ohno.

In yearly 90’ JIT production process management was confronted with other manufacturing systems in the book “The Machine That Changed the World” (by James P. Wormack, Daniel T.Jones & Daniel Roos). That confrontation led to the definition of what we today understand as LEAN defined in its principles: 

1. Specify value from the standpoint of the end customer by product family.
   
2. Identify all the steps in the value stream for each product family, eliminating whenever possible those steps that do not create value.
   
3. Make the value-creating steps occur in tight sequence so the product will flow smoothly towards the customer.
   
4. As flow is introduced, let customers pull value from the next upstream activity.
   
5. As value is specified, value streams are identified, wasted steps are removed, and flow and pull are introduced, begin the process again and continue it until a state of perfection is reached in which perfect value is created with no waste.

It’s hard to catch at first glance how exactly improvements in the process of car manufacturing can be adopted in software engineering but as you may already recognize LEAN principles were one of inspirations for borth SCRUM inventors & Agile Manifesto signers.

KanBan board, WiP limit, pull system

The easiest way to express KanBan it’s by clearly showing a full map of the value stream on KanBan board (later defined as “board”). Board should be visible & easily obtainable by all developers that are responsible for all steps that occur through value stream.

Direction of value stream - left to right only! 

Now we have a map of the development of our product. In our case that value of the product is working software so we can imagine that every sticky on board is a small “batch” of potentially working software (later defined as “feature”). Every feature that is planned for development has to “travel” through the board from left to right through all steps (pending, analysys, development, test, deploy) before it can be delivered as a value to the end customer. At this point you may ask where is the catch? It does not look like a hard thing to implement this kind of workflow. There are (at least :D) two caches. One is implementing Work in Progress Limit (WiP Limit) , second one is implementing a Pull System. 

Work in Progres Limit (WiP limit):

There is a number above every step name on board and that number defines maximum amount of “stickies” (features) that could be developed at any given stage of value stream.

It may be counterintuitive to recognize that limiting work in progress may actually help to deliver value to end customers faster. The truth is that it really helps and this happen due to understanding of Little’s Law which states: "in general, for a given process with a given throughput, the more things that you work on at any given time (on average), the longer it is going to take to finish those things (on average)."

Pull System: 

In “normal” push system a person responsible for the analysis step would just PUSH a feature that has just been analysed by him to development. In this situation the developer is not in control of his own work in progress limit. He either waits for features to “jump” into development (which is a waste of time) or he is covered by a huge amount of features to develop at once thus development step become a bottleneck. (resolving bottlenecks also creates a waste of time).

As you see on the board in two of the existing steps (analysis & development) there are additional sub-steps - doing & done. In a pull system developer is PULLING feature to develop from a done sub-step of analysis step. This gives him (developer) control over his own work in progress limit. He can start work on new feature only if he has a capacity which he creates by finishing work on previous feature.

Creating a pull system and constantly inspecting & adapting it theoretically:

• eliminate possibilities of waste of time due to waiting for work and bottleneck resolution;
• gives the possibility to develop & deliver flawless value to the end customer. 
  

Of course in reality we are not able to eliminate waste totally but mastering flow of work through KanBan board is a great tool to keep waste on a minimum possible level.

You may think again that it’s not a big deal to implement WiP & Pull system but please confront your expectation with information that it took 10 YEARS (50’-60’) for Toyota to fully implement the JiT method for manufacturing. They have struggled with countless bigger (4-month strike of ALL manufacturing workforce due to NOT accepting that they have to now learn how to operate all machines in certain production line) or smaller (how to exchange information between workstations that are louder than airplane engines) problems during transition from “standard” way to this new JiT way of production. 

Summary:Pros, cons of Kan Ban

Even if something is very hard to achieve it does not mean that You would not pursue it. Implementing KanBan in organizations/teams now is way easier due to the now long history of do’s and don'ts scripted in multiple books about LEAN in practice.

KanBan is a very flexible but hard to master tool to:

a) developing and sustaining both complex products (for example software development) & “not so complex” products as cars etc;
b) fast & precise recognition where & when bottleneck occurs (thus giving possibility to focus ONLY on those problems that interfere with value delivery, focusing on other problems is a waste); 
c) minimizing amount of wastes that occur through certain work/production flow;
d) smooth delivery of value to end customer; 

Pros of KanBan:

a) KanBan is radically non-prescriptive and easy to apply to any given You can spend 10 minutes to draw the first draft of KanBan board for your workflow and you can already start using it. There are no roles, artifacts, set of responsibilities, secret meetings etc. KanBan is adapting to You. Not you to KanBan.

b) Once KanBan workflow is established a certain flow starts to dictate pace for work items to travel through the value stream. This gives a prediction of how fast a certain amount of value can be delivered to the end customer. 

Cons of KanBan:

a) KanBan is radically non-prescriptive and easy to apply to any given workflow but it is not by all means an easy process to sustain!  By definition KanBan it’s a constant improvement seek and waste reduction cycle. There is no “end” to the KanBan adaptation process and if an organization is not willing to continue that process it will not find the true reasons of occurring wastes & bottlenecks. “Lack” of strictly defined meetings structure, roles and responsibilities can be also frustrating because KanBan demands absolute attention to details and mutual understanding of lean principles from every value stream step team member. Forcing KanBan “wrong way” (without absolute understanding of its purpose by all participants) may become a case when mutual responsibility to seek perfection is misunderstood by individual responsibility to point a finger at anyone who makes mistakes. 

b) Once KanBan workflow is established a certain flow starts to dictate pace for work items to travel through the value stream. This gives a prediction of how fast a certain amount of value can be delivered to the end customer. 

That is exactly what it is - a prediction. Now imagine that a company X is asked by a client to deliver a complex, fully developed product in a strictly defined period of time . If X will accept such a request during adaptation of KanBan they are exposing themself to risk of not knowing the real throughput of their team. They will be under enormous pressure to deliver on time which will for sure dramatically grow cost AND lower quality of end product. (as 2x growth in the amount of developers is not going to magically deliver product 2x faster, quality of end product must suffer). 

ScrumBan

Concept of ScrumBan was first formalised in “Scrumban: Essays on Kanban Systems for Lean Software Development” written by a software engineering practitioner Corey Ladas in 2009.

In his essays Corey stated that adapting Scrum framework is for sure a good first step to introduce LEAN concepts in software development. What he also stated is that that first step has to be followed by next steps as every LEAN process is continuous. Applying every detail from Scrum Guide (especially from first versions of Scrum Guide) without recognition that maybe this framework has some build-in limitations may stop a team's ability to develop better products.

What is unique in ScrumBan?

We can remove those built-in limitations of Scrum by applying Kanban “inside” Scrum and slowly recognize which elements/artifacts/meetings of Scrum are bringing the most value and which are a potential waste and could be possibly terminated. 

We can specify a few steps that are needed to transform Scrum to Scrumban. At certain points You will have to decide if you want to “break” some rules of Scrum.

1. Visualize the work.
2. Impose WiP limits & add more columns to the sprint backlog.
3. Stop Estimating Backlog Items
   ---------(Let’s break some Scrum Guide’s rules! )  ------
4. Get rid of some “unnecessary” Scrum Events
5. Trigger your Sprint Planning aka. stop timeboxing

Ad. 1 Visualize the Work

At the beginning you have to be able to see the whole workflow to provide the necessary amount of transparency & mutual understanding of the development process. Even a basic KanBan board is a great tool to do that.

Ad. 2 Impose WiP limits & add more columns to the sprint backlog.

This step is both most important and most challenging. Work in progress limits it’s something that will indicate the Pull System to your current sprint workflow. To manage those “pulls” You can add a separate doing/done column into every work category.

Ad. 3. Stop Estimating Backlog Items (if You are still doing it).

At this point you will have a KanBan board for the Sprint Backlog but how to connect it to the Product Backlog? Sprint planning it’s still a thing so you can use that event in the most efficient and valuable way. Estimating items from Product Backlog by using some tools like planning poker etc. could help but is widely misused. In the “Useful links section you can find an Allen Holub’s “No Estimates” presentation that shows what i mean by misused).

What may be helpful to easily avoid estimation of backlog items is adding a limit not only to work in progress stepps but also to both Product and Sprint Backlog. For start you can apply two simple rules:

1. "pulling" not more than X items into Sprint Backlog from Product Backlog (during sprint planning); 
2. not having more than Y most important work items fully described on the “TOP” of product backlog (items that will potentially be pulled by developer’s;

--------------(Let’s break some Scrum Guide’s rules :) )  -----------------
If you are a Scrum purist or steps 1-3 are exactly what you need in your product development process you don’t even have to make steps 4 and 5. At this point You have KanBan that is time-boxed and maintained by the Scrum framework. Still nothing stops you from shifting your focus from delivering more value to the customer every sprint to delivering value to the customer more often by mastering WiP limits.

Ad. 4. Get rid of some unnecessary Scrum Events & meetings

You will always benefit from focusing on the quality of scrum&non scrum events/meetings. After careful assessment & hearing feedback from your team you may end up with one of conclusions:

1. Effects of that meeting don't have enough value yet. Let's try to make that meeting better next time. 
2. That meeting has no purpose due to the introduction of KanBan. Let’s get rid of it and use time in a way that will as a result bring more value. 

Ad. 5. Trigger your Sprint Planning aka. stop timeboxing

Final result of  KanBan “injection” to Scrum may result in resigning from time-boxed sprints. You can still plan them during Sprint Planning but the moment of that Sprint Planning will not be fixed as before. That moment of next sprint planning will be triggered when for example there will be less than Z work items left in your current Sprint Backlog.

Summary: Pros, cons of ScrumBan

ScrumBan is using the known Scrum framework shell to “inject” KanBan. This strategy results in a minimum amount of organizational effort needed to obtain agility. In theory ScrumBan gives opportunity to benefit from all of both Scrum & KanBan qualities

Pros of KanBan:

a) ScrumBan provides a decent amount of flexibility. If your development process is benefitting from time boxing (for example Your client is constantly switching requirements and You really want to “stop him down”) you can apply Sprints of same length. On the other hand if you have mastered your workflow you can start experimenting with breaking down some Scrum guide rules ( triggered sprint planning etc.).

b) If the Scrum framework was already introduced & applied to your development process it will be way easier for the whole organization to understand & adapt to ScrumBan. (and finally KanBan if it’s the goal).

Cons of KanBan:

a) ScrumBan provides a decent amount of flexibility. If your development process is benefitting from time boxing you can apply Sprints of the same length. On the other hand if you have mastered your workflow you can start experimenting with breaking some Scrum rules ( triggered sprint planning etc.).

You have to remember that applying any amount of flexibility into your development process will not cure existing problems by itself.  For example If developers are constantly not delivering the amount of value agreed during Sprint Planning you should always carefully analyze what is a root cause of such a problem rather than instantly propose triggered planning or getting rid of estimates as an only solution.

b) If the Scrum framework was already introduced & applied to your development process it will be way easier for the whole organization to understand & adapt to ScrumBan.

It’s true if your organization was introduced to Scrum with proper attention to transparency/inspection/adaptation and Scrum values. If existing Scrum is already nothing more than a cargo cult any change of current situation will be very hard due to lack of understanding what Agile truly means.

Agile frameworks - summary 

You may be confused why the same aspects are constantly mentioned as both positives and negatives during summary of every framework. There is a purpose to it and that purpose is to always consider “it depends'' as the best possible FIRST answer to every question (not only in matters of agile frameworks). Every answer has some amount of trade off that we apply to the stated question. You can’t both eat and have a cookie.  We should think about agile frameworks exactly in the same way. So let’s try to ask yourself which framework is the best? Scrum , KanBan or ScrumBan?

Which framework/tool is THE BEST !? (and Why it is not possible to answer that question)

Answer: “It depends on: “

1) What are you trying to achieve by applying a certain framework ?

Maybe you just need a next round of “organizational changes” that will excuse the current not-so-good state of a certain product? I hope not :D It will be way better to fully commit to a certain framework after careful analysis (please engage your developers into that analysys!) & live test on existing project.

2) What is the current structure of your product development ?

Maybe you are already developing a product in a more-or-less agile way  but you didn't even consider to name it that way. If there are only few things that need to change to adapt your current production/workflow to for example KanBan why to go around and force for example Scrum ? 

The less changes you will force on the whole organization at once the better.  

3) What is Your product and why do you even want to consider Agile as a valuable approach to that product development ?

As mentioned at the very beginning there are products (a bridge for example) that need to be developed in the waterfall approach. You simply will not benefit from applying Agile frameworks into bridge development. Maybe your product is not exactly a bridge but follows the same rule ? If yes then organizational effort to impose “Agile” will be a clear waste.

4) Do you have a vision for your product ? 

It’s almost impossible to imagine a product that will not benefit from having a clearly stated future plan for development. Even if those plans will change (and the truth is that they will change a lot) you are creating a common sense through the whole company that You as a product owner/CEO/product manager/project manager (choose which name you want) care about the product.

This is a very important signal to:

a) developers - it gives them a purpose to focus on what they are best at - development! If they see that you have a clear product goal and plan to deliver it they will follow you!

b) future employees - do you want it or not current team members are sharing opinion about your company/team all the time. Creating a product vision is partially giving you also a good PR on the job market.

c) current & future business partners - if you are clear in expressing vision for your product you will be able to maintain those partnerships that are valuable to your organization.

5) Are you sure that the culture of your organization will align with Agile’s principles

As stated a few times in this document changing culture of the whole organization is very difficult. Implementing any agile framework it’s pointless if your organization it’s not already at least a bit transparent and ready to inspect & adapt (thus ready to accept failure as a natural outcome of changing “how we work”). Even the best possible product to implement an agile framework will not benefit from it without proper values as foundations.

If you are running a small company (or one team or division of teams inside a bigger company) you have the biggest influence to impose cultural changes by clearly expressing by yourself all those values that you want to impose on your team members. If that will work out and you will find team members eager to follow those values (sometimes you will have to fire someone who is not willing to adapt) AND those values are in line with Agile’s values you should try to use an agile framework. Then it’s almost guaranteed that your team/small company will benefit from using a certain framework thus it will grow and create curiosity on the market/inside of a bigger company.

 At this point you are:

a)  running a small company and you just have a hard task to maintain this “proper culture” through a period of painful company growth; 
b) running a team or division in a bigger company and you have a very very hard task of convincing upper management/CEO/board to apply your team’s culture upon the whole company.

I wish you all the best in both cases :D 

How to define which framework/tool should i use then ?

Knowing that there is no clear answer to the question “which framework is the best” we have to ask yourself a different one “Which framework / tool suits best for my product ?

Important similarities of Scrum, ScrumBan & KanBan:

• relatively easy to implement but hard to master due to perfection as an end goal;
• they focus on reducing waste, continuous value delivery and creating a feedback loop;
• demand developers team to be cross functional ;
• demand proper organizational culture to bring any benefits;

What may be tricky during choosing proper framework/tool:

• some aspects of each framework/tool could bring either a benefit or a harm to your product development process so choose wisely;
• be careful with implementing top-down one framework/tool to all of the processes connected to product management (support department may need a different approach then R&D) .
• If your product is big and complicated it’s almost always better to fit a certain framework/tool bottom-up; ;
• always gather feedback from developers about direction of ongoing changes during agile transformation;
• remember that the character of your product can change in time so no solution will last forever;

Differences & probable best applications table

Implementation & Change management

Everyone knows that “it takes time and effort to make an organizational change”. Unfortunately not everyone knows exactly what it means.  You have to ask yourself some key questions before introducing any change of process (“how we work”). Otherwise you will be sooner or later (rather sooner) faced with exactly the same questions directly from people who are affected by those changes. There is no escape from it as if your goal is to successfully change processes you have to know how to successfully engage people about why they have to change “how we work”.

In my opinion 3 crucial questions to ask yourself would be: 

1. Do I know how people react to changes ?
2. What are the real costs vs potential benefits of that change ? 
3. How much time would it take to see results after implementation of a change ?

Ad A)  how people react to changes ?

This straightforward graph from Ray Immelman’s “Great Boss Dead Boss”. It’s rather self explanatory. Show it to everybody involved in any process change. People are changing attitudes in time and there is nothing wrong with it. We have to just accept it and keep everyone on the same page with the current state of “where we are”. What we should focus on is identification of impediments, gathering clear feedback from and clearly stating the reason for change to everyone who is affected

Ad. B) What are the real costs vs potential benefits of planned change ?

This is really the true tradeoff that has to be made. Changing processes is taxing both time, resources and will power of people involved in change. If you will radically underestimate how big that tax is, you will be exposing yourself to huge risks. Lowering temporary quantity & quality of delivered end product is one of those risks but even more dangerous one is “squeezing” people’s psyche. The more sophisticated your end product is (software is rather sophisticated) the bigger burnout of your team you will observe from forcing process changes that are not properly managed. Ask yourself if the risk of losing crucial team members is something that You can accept.

Potential benefits of change are most of the time way more exposed and shiny then real costs. We have to always properly assess if that “beautiful future” is really that bright and worth the sum of effort. 

Overall there is a risk in both making too frequent changes and not making any changes at all. There is no clear definition of where is an optimal balance between those two but for sure there is a value in figuring out that balance.

Ad. C) How much time would it take to see results after implementation of a change ?

Nobody wants to engage in a change of process that will not bring any result. Even if that result is clearly negative there is some value in testing a hypothesis. We should accept that if a change will not bring results we are always able to make a step back. What we should avoid is to stall in situations where no results of change are observed (either good or bad) and no clear timeframe/plan for reaction is set.

What to avoid during implementation of Agile frameworks/tools? 

Implementation of the Agile framework it’s a really hard and complex task but you can make it a bit easier by focusing on things that are really important at any given point of time.(read Theory of Constraints - link in bottom of that article ). 

During first steps try to focus on:

a) choosing a framework/tool that will suit most to your product development process (but don’t be upset when 1 st choice will eventually not last, just try different one if there is enough potential value in it)

It’s crucial to balance time spent on figuring out which framework to choose vs time spent on actual implementation. It’s no sense to waste time on forcing some solution where it’s clear that it’s not bringing enough value. It’s better to be open to change of direction. On the other hand if you will never make a decision you will never test any solution.b) teaching about foundations & important elements of certain agile frameworks / tools. 

b) teaching about foundations & important elements of certain agile frameworks / tools.

It is absolutely necessary for everyone working in a certain framework/tool to understand why and how they are going to use it. The more widely acknowledged and accepted is that reason the smoother and less stressful this process of transformation will be. .  

c) not becoming an Agile policeman who is expressing need for every small change separately (without context) by only reading loud short fragments of Scrum Guide (or a KanBan manual).

Always express why there is a value in a certain approach/method/rule/artifact/event and what we may miss if we would not change “how we work”. That will create a mutual understanding and will spread responsibility across the whole group affected by agile framework introduction.

d) not pushing detailed and overspecified solutions to every problem that occurs during adaptation. 

Your role is to install certain mindset, boundaries and responsibilities but not to actually execute changes in behaviour by micromanagement. Certain team members/stakeholders will need your help to better understand reasoning but ultimately it’s their job to grow into new responsibility. Your job is also to constantly (at least every retrospective) induce clarification and open a discussion to find what was the root cause of the emerging problem so the people involved can react and find a solution by themself.

Which project to choose for Agile framework implementation ?

There is no clear answer to that question but for sure this scheme/graph is going to help you to choose a certain class of projects/products.

Your best shot will be a project/product that is at the same time:
- critical to the point that whole organization will even care about it’s progression or regression  ;
- having a “future” in term of time and potential team grow to give you possibility to observe if transformation brought expected value; 
- supported by a client/sponsor that is “stable” in terms of both finance and quality of cooperation. It will be necessary for all stakeholders to understand what will a planned transformation mean to them. (change of value delivery, value quantity & quality etc. )

For now this is end of "How To Agile?" script but look out for more :D 

You can always find articles about more specyfic topics in our Knowladge Base. 

Useful knowledge sources - books/essays/websites/YT channels etc.
(not only about Agile etc)  

About frameworks: 

Scrum Guide - version 2020
“Scrum with CanBan” scrum.org guide - version 2021 
Labirynty Scruma - Jacek Wieczorek
Scrumban: Essays on Kanban Systems for Lean Software Development, Corey Ladas
Kan-Ban - Agile Project Management with Kanban, Eric Brechner
Succeeding with Agile: Software Development Using Scrum

Inspirations : 

scrumgroup.org
Scrum.org
Zainspiruj mnie kuba - PL YT channel
AgileRebels.org
Agile.org
Atlassian - YT channel 
Development that pays - YT channel 
kanbanblog.com

Books that are loosely connected with Agile/organization/management topics: 

Cargo Cult Programming - Richard P. Feynman
calteches.library.caltech.edu/51/2/CargoCult.pdf 

The Machine That Changed The World - James P. Womack, Daniel T. Jones, Daniel Roos
It’s Not Luck - Eliyahu M. Goldratt (TOC)
THE GOAL - Eliyahu M. Goldratt (TOC)
Slack - Tom DeMarco
Project Phoenix - Gene Kim & Kevin Behr, George Spafford
Elegant Puzzle - An Elegant Puzzle, Systems Of Engineering Management - WIlliam Larsson
Five dysfunctions of a team - Patric Lencioni  
Extreme Ownership - Jocko Willink  & Leif Babin