Project Management

An introduction to the basics of the Kanban System.

Kanban is a visual system for managing work as it moves through a process. It enables a shared understanding of the issues and progress of current work and the next immediate task priorities. In this resource the authors explore all the basics of Kanban, including its principles, practices, background and usage in lean-agile environments. Complete with videos and clear images, it is highly recommended for novices and experts alike.

Describing various Agile design principles and practices in-depth.

Describes Agile Design principles and practices in-depth, including refactoring, restructuring, clean-code, simple code, technical debt, incremental design, design principles, design patterns, emrgenet design, domain-driven design, evolutionary architecture.

An update to the rules of the game in it's 20th year anniversary.

Ever since the first version of the Scrum Guide was released in 2010 with the goal to help people understand Scrum globally, it has been continually updated with new rules and uses to coincide with the ever-evolving complex world. Check the newly updated 2020 version of the Scrum Guide with more details and definitions of the rules of the game.

Explaining what Agile really means in daily practice.

The definitions of Agile in the context of software development vary, but few focus on what it means in daily practice. In this to-the-point article, Barry Overeem shares his favorite definitions of Agile, the 7 principles of Continuous Innovation and an example video from the video by the Nordstrom Innovation Lab that put's it all into practice. It will help you grasp the concept of Agile Software Development better.

Transforming the part of the value stream that corresponds to the development of options, order management or product discovery into elements ready for delivery.

Upstream Kanban helps companies model the process of transforming options into elements ready for delivery. Basically, it is all the activities done to fix inconsistencies in the Upstream and enhance business agility to deliver the expected product or service quickly to the customers. However, most companies find it difficult to implement it fully because they lack basic information and decision frameworks to be able to do that quickly and effectively. This article details information about what is an Upstream Kanban, how it can help companies, and how to implement it.

How Kanban can help you get a handle on your volume of work by unhiding it and improving your flow.

Is your team under constant pressure to meet delivery dates and increase efficiency? Brendan Wovchko explains how using Kanban gives you the visibility you need to streamline your IT operations. You'll learn how to: 1) Prioritize work more effectively; 2) Manage stakeholder expectations; 3) Use Lean metrics to remove waste. Only when you’re dealing with the true state of your work can you identify ways to accelerate your delivery.

Exposing the reality of work at Spotify, as a failure/learning report intended for change agents to see the challenges and the opportunities for growth.

Let's put aside the 'bubblegum and unicorns' of the Spotify Engineering Culture videos and talk about what doesn't quite work at Spotify, and how we're trying to solve it. Joakim Sundén (who was an agile coach at Spotify headquarters from 2011 to 2017) presents a failure/learning report intended for coaches and other change agents who need encouragement that it's always hard AND it's always possible to improve.

The principles of Agile 2 - the self-proclaimed "Next Generation of Agile".

The article describes the proclaimed next-generation of Agile principles. The authors further list the problems and insights discovered during their retrospective on the state of Agile and the ensuing discussions when coming to a consensus on these principles. As we have highlighted some of them in the takeaways, the principles teach us about what to expect in Agile 2.0. Check the article for more insights about each principle, the corresponding problem, and the key roles that Agile will be playing to solve them.

A very short and simple kanban intro, showing the changes of state as time progresses.

Is your company still trying to understand and implement Kanban? check this short, simple, and clear Kanban introduction by Henrik Kniberg. In a comic style, the designer displays briefly the events that take place in a Kanban environment. From selecting the two most important things in the backlog list to the development team, to releasing the features by the deployment team.

How to identify when agile tools and practices are being adopted without deploying them with the accompanying mindset.

Agile senior contributor Steve Denning explains Fake Agile. It follows a request by a major corporation to give a talk on the topic describing what it is, how to identify it, and how to deal with it. He argues that the term “agile” is often thrown around without any agreement on its meaning and being applied to firms, or parts of firms, that have no substantive claim to any agility. Surveys by Deloitte and McKinsey show that more than 90% of senior executives give high priority to becoming agile, while less than 10% see their firm as currently highly agile. Based on his past research, Steve suggests that Real Agile is achieved by organizations embodying a mindset with three main laws: the "Law of the Customer", the "Law of the Small Team", and the "Law of the Network".

Find out why attempting to standardize a single method of Agile practice across your organization could be slowing everyone down.

Knowing the power of self-organization, frameworks, and best practices can be very useful. But staying open to solutions that are different is more important than standardizing one framework in the organization. An Agile framework that works for one department may not automatically work for all other departments. As such, rather than having a universal process for all departments within the organization, allow tailored processes for each department(s) as required. Check the article to find out more about the risk of adopting a one-size-fits-all approach and the role of leadership when implementing Agile frameworks.

The steady routine of actions - centred around continuous improvement - that reduce complexity, promotes predictability and controls risk.

Sjoerd Nijland explores the four formal Scrum events listed in the Scrum guide that evolve around inspection and adaptation. They include Sprint planning, Daily Scrum, Sprint Review, and Sprint Retrospective. He explains that Scrum events are collaborative sessions that create regularity, and are time-boxed with a maximum duration, among other characteristics. We can learn more from the article about these events, like the core values they bring to a scrum team.

Learn about Kanban, a visual method for managing workflow. If your work follows the pattern of “To Do,” “Doing,” and “Done,” it can be managed with Kanban.

An in-depth analysis of the Kanban methodology explaining what it is, how its key features such as a Kanban board and card work, its role in Agile, where the method originated, and more. We learn that, unlike other workflow management methods that force change from the outset, Kanban is about evolution, not revolution. It hinges on the fundamental truth that you must know where you are before you can get to your desired destination. If your work follows the pattern of “To Do,” “Doing,” and “Done,” it can be managed on a Kanban board.

Often misunderstood, having a “done” increment of product at the end of every sprint drives continuous improvement.

Tristan Libersat delves into Scrum to explain the most important element of the Agile framework that most people often contradict with its principles. He notes that many people don’t understand Scrum, they see 3 roles, 5 events, and 3 artifacts, but they fail to get the real purpose of the framework. He adds that every agile framework and practice has an intended purpose that can be different from others, but that always relates to at least one value or principle described in the Agile Manifesto. Thus Libersat concludes that the Sprint is the cornerstone of Scrum. Let's find out more about the purpose of Scrum and its essence in the article.

Differentiating between continuous (kaizen) and radical (kaikaku) improvement.

The Kanban Method helps teams maximize productivity by creating a flow from request to delivery of value. Jurgen Appelo argues that Kanban's ability to handle continuous, evolutionary, and incremental improvement (kaizen) may prevent from being a great choice for discontinuous, revolutionary, and radical improvement (kaikaku). The best tools are always great in context, and he shares his reasoning and alternative solutions.

Introducing an iterative innovation process focused on the creation of value and the priorities of the organization.

Jose Cabrera introduces an iterative innovation process that is being adopted by new generation companies within the current age of technology to survive the uncertainties it poses and accelerate their growth. He alleges that the world is moving exponentially while company structures remain very linear thus creating a dynamic environment for organizations. As a result, he suggests that stakeholders need new mental models to build and lead organizations in this world of accelerated changes, new organizational structures capable of interacting with the new reality, and new systemic models for change, in order to allow the transformation of the entire organization.

A catchup with Kent Beck, the creator of Extreme Programming, the pioneer of xUnit and author of numerous books including "Extreme Programming Explained" and "Test Driven Development".

Kent Beck, the creator of extreme programming and the pioneer of xUnit and other multiple books, shares his knowledge of programming in this episode covering fundamental coding lessons that developers should pay attention to. For starters, he states that programmers are responsible for their codes to run and once they have accepted that responsibility, unit testing falls directly out of it. The programming ace also points out that extreme software programming is a social process and not an individual activity and in the coding world, nobody cares about certificates - they care about competence.

Outlining a framework to handle the rapid pace of change by managing the Survive Channel and the Thrive Channel.

In the post-pandemic period, organizations are adapting to the new changes made during the pandemic. Such as leveraging social tools like zoom to interact with their teams and clients. However, how are the companies dealing with this major transition? Here, we learn the two-channel systems coded into humans that are usually in response during times of rapid change and uncertainty. The Survive Channel, which is activated by threats and leads to feelings of fear, anxiety, and stress; and the Thrive Channel, which is activated by opportunities and is associated with feelings of excitement, passion, and joy.

As delicate a balance in Scrum as it is in our democratic institutions.

Talking about the balance of the accountabilities, did you know the success of every Scrum Team is geared by the mutual balance that exists between the three separate roles of the Scrum Framework? In a Scrum Team, the Product Owner decides what needs to be done, the Developers decide how to develop it, and the Scrum Master helps everyone to continuously improve the way they use the Scrum Framework to carry out their responsibilities. The balance between these three people makes a Scrum Team effective. This also reflects in the democratic government world as discussed in the article.

Dr. Mik Kersten reviews Gene Kim's latest book The Unicorn Project, drawing parrallels between The Five Ideals & The Flow Framework™.

The article explains the birth of the Five Ideals that underpin the Unicorn Project and lay the foundation for the flow metrics. Dr. Mik Kersten together with Gene the author of the Unicorn Project book review and scribble down ideas for the ideals that the main character (Chris) was seeking on her leadership and transformation journey. Get more insights through this review about the Unicorn Project and the empirical significance of the five ideals.

The books cover all eight areas of the Scrum Master competency model.

This handy list of books is categorized by each of the eight areas of the Scrum Master competency model developed by the Agile Coaching Institute. Whether you have questions regarding the practice, coaching, facilitating, teaching, mentoring, or mastering either technical, transformation or business settings - this list from Illia Pavlichenko will provide you with key resources to get started with.

Understanding how cultural management impacts agile approaches in an organization.

Does managerial culture influence agile approaches? Johanna Rothman, a managerial consultant, summarizes a Twitter thread about perspective and non-perspective agile approaches in this article to explain how managers (and the culture they uphold) impact agile transformations in an organization. Organizations live by either Theory X or the Theory Y of management, however, irrespective of the method used, most agile transformations fail! WHY? Johanna adds that for any agile approach to work, managerial culture has to change first.

Explaining the very first instance of SCRUM, and its mission to deliver as much quality software as possible within a series of short time boxes called Sprints.

A cunning critique of the Scrum Guide and why you shouldn’t care about the immutability rule present in the Scrum Guide.

The messy reality of what it’s like to be a Scrum Master, from an author with the guts to share failures where most people only share their pretty successes.

A simple model to explain Agile in a nutshell with an anchored visualization, with visible items and some below the surface.

Explaining the difference between increments and iterations and their implications for agile delivery.

Incremental and iterative development are not the same thing. Here is an explanation of the key difference and why agile is both, using Jeff Patton's famous example of the Mona Lisa and Karl Scotland's concept of fidelity.

A description of empiricism, how it is used and why it is so critical when practicing Scrum.

Professional Scrum Trainer Mark Noneman describes empiricism, how it is used and why it is so critical when practicing Scrum. He notes that Empiricism is an essential and critical way by which we can emerge the best-fit solutions for complex problems, as it helps us to quickly inspect and adapt to the actual environment and be transparent about our organizational goals. Let's view the clip to learn more from the Scrum master about empiricism and its key role in Scrum.

Have The Conversation. Do The Thing. Review. Go Home.

John Cuttlefish proposes a one-day sprint to teams failing at their sprints saying that he tried it with the single-batch flow after a chat on long sprints with a friend and the results were successful. Through the chat, the friend suggests shortening a sprint down to a day if necessary could be a solution. He further details how it can be done as John asks questions noting that the process only entails, showing up for the sprint, having the conversation, collaborating on what to deliver together with the team, and reviewing the work by the end of the day. Open the article to get a deeper insight into what is a one-day sprint and how it can be implemented.

The pros and cons of shorter and longer Sprints, and how to discover what works best for your team.

A very descriptive agile text focusing on the pros and cons of short scrum sprints and long sprints to help teams decide on which would work best. We learn that a Scrum Sprint is a fixed period of time for the Team to focus and develop a product with quality high enough that they could release it to the customer. A “good” Sprint Length, then, has to be long enough to produce results, but short enough to limit risk. The article also notes that short sprints help reveal problems and impediments faster while longer sprints are vulnerable to risks due to the high chances of unpredictability. Let's read to explore the merits and demerits of these two and narrow down why shorter sprints are more effective.

The three primary mechanisms for implementing flow that increase throughput and accelerate value delivery.

A descriptive text of the 3 primary keys to achieving continuous flow for increased throughput and high-value delivery. We learn roles that visualizing and limiting the work in process (WIP), reducing the batch sizes of the work items, and managing queue lengths play to eliminate the obstacles that hinder seamless flow in an organization. Read to know more about the advantages of these principles and the reason lean organizations leverage them for real-time flow to turn new system features quickly from concept to cash.

The benefits of deploying small batches as seen through the experience of multiple large-scale organizations.

Take a look at this descriptive presentation explaining the benefits of small batches in real cases for multiple organizations. Generally, we see that working in small batches is among the principles of continuous delivery, and from a changes deployment perspective, they make it easier to detect and fix problems. View the slides for more insights on the importance of small batches.

Learn how to use the Scrum cycle to create a product with the right features and the right user experience (UX).

Scrum is a simple framework based on the idea of inspect and adapt: Create a product increment, show it to the stakeholders, and use the feedback to see if the right product is developed. This post describes what Roman Pichler regards as the essence of Scrum: a cyclic three-step process. It shows how the three steps help create a product with the right features and the right user experience (UX).

The sprint backlog is a list of tasks that must be completed during a Scrum sprint.

The Sprint Backlog is a list of tasks to complete during a delivery, created from selected items of the product backlog. In this video/article description of Scrum Tools, Mike Cohn details how teams may tweak the sprint backlog as sprints move forward, some do-and-don'ts, and the usages of the burn-down chart. This resource is part of a 19-part Scrum Foundations video series available on the Mountain Goat site.

Why and how our development teams sustain a deliberate, weekly release cadence and use a train metaphor to drive planning.

Working in a fact-based, experience-based, and evidence-based manner.

In this minimalistic article, Hiren Doshi shares his view of the three pillars of empiricism: Adaptation, Inspection, and Transparency. As the author points out, Scrum works not because of its structure or practices, but by adhering to the underlying principles of iterative, value-based incremental delivery by frequently gathering customer feedback and embracing change.

The Sprint length is of major influence to a team’s agility, with shorter Sprints having less risk that the definition of what is being built may change.

How to determine the perfect sprint duration for every project phase.

Sprints are basically equally divided sections of the main project that each have their own planning, work phase, and review. Your project goal determines how long your sprints should be. Agile coach Matthias Orgler explores the answer to "What is the optimal sprint length in Scrum and how you can determine it" in this piece.

He writes that everything shorter than 1 week creates too much overhead compared to the time you get to actually work on the product. And everything longer than 1 month deprives you of the much-needed checkpoints. So the sprint length always has to be between 1 week and 1 month. Read to find out what is sprint, why you need it, the benefits of doing multiple sprints, and a lot more.

Managers ask it. Developers hate it. Know why that is and what you should be asking instead.

How should you handle employees working on complex projects in an organization as a manager? Perhaps you intend to know "'when the project will be done" but it's a bit unpredictable for the employees to define when they will be done. Blake Norrish in this text explains how to approach such scenarios to estimate the deadline of unpredictable projects like Software projects. He notes that instead of asking when the job will be done, rather ask "WHAT IS LEFT TO DO?"

Exploring the relationship between the need for "idle time" and increasing productive capacity in Kanban.

The word Slack is often poised with a negative connotation that it creates more idle time for employees while they could be utilizing the spare time for productive tasks in the company. This article subverts that claim suggesting that its crucial for exercutives to do away with that negative mindset against Slack. It explains that rather than staying idle, employees have more time to reflect on innovations and improvements keeping the company's products and services stable and innovative. Learn more in the article about Slack and how to leverage its spare time for more valuable things in the company.

Making waste visible in the development process with a visual representation to engage your team into making clear improvements.

How do you make waste visible in a system? Value-Stream-Mapping, a lean technique as well-described in this piece, is key to identifying waste in a system. The technique maps the development cycle of your system in a visual presentation making it easier to detect both value and non-value-adding tasks that should be defined and tracked from customer requirement to delivery. As a result, the people working on the system unify their ideas to channel out the waste and work on the value-adding parts of the system. Therefore, reducing individual blames and optimizing the entire system.

Combining Kanban, Flow and Cadence (KFC) to migrate from a timebox-based to a pipeline-based approach of software development.

Exploring what can happen when teams get fixated on “velocity” metric, and lessons to avoid this anti-pattern.

Project management specialist Willem-Jan tells a story of a team that he led as a scrum master. The team got fixated on the velocity metric and later couldn't handle complex tasks. On the other hand, management thought that it was helping Willem and his team to get the backlog executed faster. The idea was if the team was self-improving, the velocity at which work is done should also increase. Willem then realized this just deviated the team further from the scrum goal. The episode covers the repercussions of getting fixated on the velocity metric and the lessons that Willem learned to offset the anti-pattern.

Going beyond information about status of work, and spotting issues the team may be facing - all with a quick glance.

Cumulative Flow Diagrams can be extracted automagically from many issue-tracking tools, and this simple graph can shed a light on a plethora of information about the team and its work style. From a single diagram, Pawel Brodzinski shows how we can identify common patterns and deduce what the team can be struggling with. A master class on team tracking - make sure to read the comments for more insights.

Defining when the Product Increment is considered “Done”, what to look for and the typical patterns used to measure it.

Sjoerd Nijland talks abt the product increment and the definition of done citing that most teams deliver products in one shot and consider them done but the Agile author argues that this only ends up in getting something that is barely good enough but not perfect. He also adds that a done product is that which we keep on improving to perfection through learning and adapting. If your goal is to learn about the characteristics of a 'done' product backlog and increment plus the definition of DONE and its key benefits to Agile teams, this article is a must-read.

Avoiding the trap of eroding sprint goals so there will be motivation to take corrective actions to prevent future failures.

Anshul Kapoor uses the analogy of a frog and boiling water to pass fundamental lessons Agile teams can learn to avoid sprint goal failures. He notes that like a frog in slightly warm water, Agile teams get comfortable with a few sprint goal failures, and the more the situation persists the teams' failure tolerance levels increases putting the organization into the trap of eroding goals. The same case happens to the frog if you continue heating the water. It tolerates the temperatures and boils along with it. Let's read this interesting article for more insights into how Agile teams relate to a frog in warm water, and what we can do to deal with the trap of eroding goals.

Individual performance metrics may destroy morale and kill teamwork, if used wrongly, but their absence hurts even more.

Project founder and programmer Yegor Bugeyenko, criticizes the modern way of management claiming that programmers have way too much power over projects than managers exempting them from individual performance metrics and that should not be the case. Moreover, they believe that putting a metric on them is a bad practice as it might have negative effects on the team and the organization at large. However, according to Yegor and other Agile experts, individual performance metrics seem to have a positive and contagious effect on all the other members of the team when used correctly. Read the article for more information on why we need good performance metrics in organizations and how to choose them.

Turn raw kanban data into actionable flow metrics.

A different take on a related post by Daniel Vacanti, where he shares how to collect data, and to calculate cycle time and throughput, this article focuses on how to turn data into meaningful flow metrics by calculating the cycle time using start and finish times of work items. The calculation helps with prediction of completion time, and measuring the overall performance of your process.

How do you turn your data into meaningful flow metrics

Part of a series of posts from Daniel Vacanti, where he shares how to collect data, and to calculate cycle time and throughput, this article focuses on how to turn data into meaningful flow metrics by calculating the cycle time using start and finish times of work items. The calculation helps with prediction of completion time, and measuring the overall performance of your process.

Considering the multiple benefits you gain from having a Definition of Done.

The reasons for having a Definition of Done (DoD) may vary from team to team, and each person might find a different reason compelling. And others might also have the wrong meaning of the Definition of Done. Learn the true meaning of the Definition of Done and five fundamental reasons for having it during an organizations' development process.

Why burn-downs and velocity slow down your team.

Knowing when you are “Done” frames the work to be undertaken.

In Scrum each iteration - or Sprint - should yield a valuable product increment of release quality. Ian Mitchell advises that an understanding of what makes an increment truly releasable - and therefore genuinely “Done” - provides transparency over the work a Development Team plans to do, and the tasks it brings into progress. Work nearly done puts the team in technical debt, which must be repaid at compounding rates of interest.

Ensure that each Solution increment meets appropriate quality standards.

Built-in quality is a principle of the Agile Manifesto, a core principle of the Lean-Agile Mindset, and one of SAFe's core values. It helps avoid the cost of delays (CoDs) associated with recalls, rework, and fixing defects, and enables an enterprise to deliver new functionality with the shortest sustainable lead time. In this article SAFe dives into the five dimensions of built-in quality: flow and quality in architecture, code, system, and release systems.

Learn about the simple and elegant formula known as Little’s Law and apply it to a vast range of business management and team leadership scenarios.

Businesses have applied Little's law across their models to calculate the capacity of their systems. However, what is really Little's law? This article widely explains Little's Law, why it's important for businesses, and how it relates and differs from other "throughput" measuring concepts like Kenban strategies and Cycle Time.

The complete and definitive guide to Scrum, describing the rules of the game by the originators - Ken Schwaber and Jeff Sutherland.

The Scrum Guide contains the definition of Scrum, including roles, events, artifacts, and the rules that bind them together. Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

The Daily Scrum serves to create transparency over the progress towards the Sprint Goal and provides the development team an opportunity to inspect and adapt.

Daily Scrums help Developments teams to self-organize and better their chances towards achieving the sprint goal. A Scrum Master or the team's leader facilitates these daily events making sure the meeting is a success and the team is aligned on their plan for the next 24hours. However, how does a Daily Scrum differ from a Daily Standup, what's its main purpose, and how should it be done? Sjoerd Nijland explains these questions and details much more about the Daily Scrum in this article.

A look at 6 different types of Scrum Masters and how shared or dedicated they are with their teams.

The role of the Scrum Master can vary greatly depending on the context and the needs of the team. Consequently, there are various SM variations which adapt to specific situations. Andreea Gheorghiu shares her views on the pros and cons of each variation, and makes recommendations. Having someone look over the processes of a team and help it evolve is necessary, but it is equally necessary to maximize each SM's chance of success.

Understanding the ramifications of the decisions we make with respect to what is fixed, what is firm, and what is flexible about scope, schedule and resources.

When we work on projects with fixed dates, scopes, and resources, we run the risk of burning out our teams and compromising quality. Use the tradeoff matrix to agree with your stakeholders as to what you’ll do when things - almost inevitably - don’t go exactly as planned.

By putting these assumptions in place, discussions about prioritization become more focused on the work and how to make the best use of our scares capacity.

An Agile coach reflects, formulates and then re-iterates three basic assumptions as to why agile teams prioritize as they do: 1) People give it their best in every project; 2) there is always more work to do than people have the capacity to do; and 3) people do not initially know what works best unless they try. They are not new or novel but Marcus Hammarberg has found that re-iterating them before starting discussions about prioritization makes the conversation more focused on the work and how to make the best use of our scarce capacity.

Story point represent the effort involved to deliver a product backlog item.

Story points are about time, since they exist in order to predict how much functionality can be delivered by what date. Time is what our bosses, clients and customers care about. In this article Mike Cohn examines how risk, uncertainty and complexity are factors that may influence the effort involved.

Invoking the immutability rule to disallow the gradual introduction of Scrum is nonsensical.

Several Scrum practitioners claim that there’s only one approach for introducing Scrum. They say you have to start by explaining Scrum thoroughly, and then the team has to start doing everything that’s part of the framework. But, rolling out Scrum and practicing it by the letter does not mean you're doing it. In fact, the author argues this only makes it harder for people to practice Scrum.

He invokes the idea that adopting Scrum gradually limits you from the Scrum benefits noting that the Scrum guide does not completely rule out the gradual implementation of Scrum and he believes it is easier to learn and understand the benefits of the different parts of Scrum.

The mechanics of a Sprint, and how team members collaborate to produce an increment.

As the title indicates, in this article Ian Mitchell goes step-by-step at the mechanics of a Sprint - starting with the preparation, the first items to be delivered, and the day-to-day work to be done. The play-by-play goes all the way to the retrospective, looking at how team members are expected to collaborate through out the development process.

How fluid scrum teams could assist multiple scrum teams self-organize to manage complexity.

Understanding the mathematics of queuing theory.

Managers who do not understand Little's Law often panic when they see long cycle times and perform the exact opposite intervention they should: they initiate more work. Their reasoning is that if things are taking too long, new items should be started as soon as possible in order to finish the bulk on time. But they ignore work-in-progress at their own peril, as Little's Law shows that the greater the quantity of work, the longer they take to finish on average.