Top-Down / Bottom-Up: Which strategy works best in Agile Organizations?

Top-Down or Bottom-Up

top-down - adj
Controlled, directed, or organized from the top

In a top down strategic management model, ownership or high-level management personnel determine objectives and how the rest of the business will work toward accomplishing those objectives.

As a small business owner, this puts all the responsibility on you and your management team to come up with how you will make your company successful and how each employee will contribute to that success. Input regarding business objectives from lower-level employees in a top down strategic management model is virtually nonexistent. What's the result when top-down strategy is used? Team members feel that they weren't listened to, that their voices didn't count. There simply was not enough full-spectrum collaboration.

bottom-up - adj
From the lowest level of a hierarchy or process to the top

The bottom up strategic management model seeks to develop ideas using the brainpower of your entire workforce. You, as the small business owner, still determine the overall goals for your company along with the dates you'd like to see these goals accomplished, but your employees of all levels assist in developing the mechanisms to reach those goals. 

Your management team compiles all the ideas from group brainstorming sessions and departmental meetings to allow you to select the strategies showing the most promise.

hybrid - adj
Of mixed character; composed of mixed parts

Let's be honest here, even in the most Agile of environments upper management still dictates what will be done and by when.  Unfortunately they tend to be inflexible, imposing, and controlling when doing so.

Hybrid, that's what I'm talking about!

In a pure bottom-up strategy there tends to be a lack of structure that the top-down strategy offers.  Even in an Agile setting this still exists (agile-fall or water-gile).  A system that takes the best of both strategies and combined them into one seems to be the answer.

What we are implementing now is a hybrid system that utilizes the top-down management structure to set the scope and deadlines along with the bottom-up team structure dictating the amount of features that can be released in a given time (metric).  

Using strong prioritization methods management is able to select features they want in each release in order to deliver the best value to the customer in a timely manner.

Using these metrics management adjusts their scope according to the output of the teams. To get more output they adjust team resources.  Gone are the command-and-control ideals that plagued us in the past; for the most part.  Nothing is perfect.



Contributors:

Pair Programming - Explained

Pair Programming - Explained

Two is better than one!

Pair Programming is an agile software development technique in which two programmers work together at one workstation. One, the driver, writes code while the other, the observer, pointer or navigator, reviews each line of code as it is typed in. The two programmers switch roles frequently.
While reviewing, the observer also considers the strategic direction of the work, coming up with ideas for improvements and likely future problems to address. This frees the driver to focus all of his or her attention on the tactical aspects of completing the current task, using the observer as a safety net and guide.

If the driver hits a problem, there are two people to find a solution, and one of the two usually has a good idea.

It is so easy, a baby can do it.

Other advantages include the fact that where two people have differing specialities, these skills are transferred. Ad-hoc training occurs as one person shows the other some tricks, nice workarounds, etcetera.

The end result is that both developers are fully aware of the code, how it works, and why it was done that way. Chances are the code is better than one developer working alone, as there was somebody watching. It's less likely to contain bugs and hacks and things that cause maintenance problems later.

In a bigger team, the pairing can change each week so each team member is partnered with somebody different. This is a huge advantage, as it gets developers talking and communicating ideas in the common language of code.

We found this to be as fast as working separately. The code got written quicker and didn't require revisiting. And when it did need to change, more than one person was familiar with the code.


Contributors:

Avoidance of Accountability - The Death Knell of Teamwork

Avoidance of Accountability

Track and Analyze

When a company first decides to initiate change and move towards the Agile methodology, it is inevitable that grumblings about it being yet another process change raise to the surface.

Companies that choose to use the Scrum framework within Agile face a similar situation.  This usually arises from what the developers feel is management watching them more closely.  This stems from the insistence of gathering metrics from the developers, i.e. daily hour reporting – or the like.

Their first instinct is to fear that management will be looking at the individual performance of the developers.  A hurdle faced by an Agile Coach and Scrum Master is to alleviate this fear.  Even though the matrices are there for management to do just that, I have yet to see the numbers used in that fashion.

They are watching me!

I was asked once if I could provide such numbers to management, I said I could but I explained that the numbers would be entirely out of context.  When asked to explain I indicated that the numbers will be a black and white description of hours worked only.  I went on to say that the work performed by individuals is quite different from developer to developer.  Developer A and B can indeed be developers that can devote 100% of their time to development.  But developer B is an SME and spends a good portion of the day helping other developers or attending meeting to help support development.  Most developers fall into some varying degree of time allotment spent on other tasks not directly associated with the current Sprint. Therefore it would be negligent to compare one developer to another.

Back to accountability.  Even though the developer’s fear of being tracked more closely is unfounded, the avoidance of accountability is very real.  In Patrick Lencioni’s book, The Five Dysfunctions of a Team, he explains that the team’s "lack of real commitment and buy-in" creates an environment in which the team does not want to be held accountable.  He goes on to say, "without committing to a clear plan of action, even the most focused and driven people often hesitate to call their peers on actions and behaviors that seem counterproductive to the good of the team."

"Just the facts, Ma'am."

It has been my experience that once I can make the teams feel less paranoid about being watched and assuring them the metrics are being used to track team progress, not individual, it becomes easier for them to trust the system.  Over time I show them how the metrics are being used.  For example, the velocity of a team is important.  Without that the team cannot determine how much work to plan for in each Sprint.  Without the Burndown Chart it is hard for the team to know if they are on track during the Sprint.  Finally, without the Burnup Chart is hard for the teams to know if they are completing the work in a timely manner.  Ideally the Burndown and Burnup chart is a mirror image of one another.

Having accountability at all levels is very important.  Do not try to avoid it.

Test Driven Development - Deep Dive

Test Driven Development (TDD) - Deep Dive

Test-driven development (TDD), is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring.   What is the primary goal of TDD? One view is the goal of TDD is specification and not validation. In other words, it’s one way to think through your requirements or design before your write your functional code (implying that TDD is both an important agile requirements and agile design technique).  Another view is that TDD is a programming technique.  The goal of TDD is to write clean code that works.  I think that there is merit in both arguments, although I lean towards the specification view, but I leave it for you to decide.

The first step is to quickly add a test, basically just enough code to fail.  Next you run your tests, often the complete test suite although for sake of speed you may decide to run only a subset, to ensure that the new test does in fact fail.  You then update your functional code to make it pass the new tests.  The fourth step is to run your tests again.  If they fail you need to update your functional code and retest.  Once the tests pass the next step is to start over (you may first need to refactor any duplication out of your design as needed, turning Test First Development (TFD) into TDD).

TDD completely turns traditional development around. When you first go to implement a new feature, the first question that you ask is whether the existing design is the best design possible that enables you to implement that functionality.  If so, you proceed via a TFD approach.  If not, you refactor it locally to change the portion of the design affected by the new feature, enabling you to add that feature as easy as possible.  As a result you will always be improving the quality of your design, thereby making it easier to work with in the future.

Instead of writing functional code first and then your testing code as an afterthought, if you write it at all, you instead write your test code before your functional code.   Furthermore, you do so in very small steps – one test and a small bit of corresponding functional code at a time.   A programmer taking a TDD approach refuses to write a new function until there is first a test that fails because that function isn’t present.  In fact, they refuse to add even a single line of code until a test exists for it.  Once the test is in place they then do the work required to ensure that the test suite now passes (your new code may break several existing tests as well as the new one).   This sounds simple in principle, but when you are first learning to take a TDD approach it proves require great discipline because it is easy to “slip” and write functional code without first writing a new test.  One of the advantages of pair programming is that your pair helps you to stay on track.

There are two levels of TDD:

1. Acceptance TDD (ATDD).  With ATDD you write a single acceptance test, or behavioral specification depending on your preferred terminology, and then just enough production functionality/code to fulfill that test.  The goal of ATDD is to specify detailed, executable requirements for your solution on a just in time (JIT) basis. ATDD is also called Behavior Driven Development (BDD).
   
2. Developer TDD. With developer TDD you write a single developer test, sometimes inaccurately referred to as a unit test, and then just enough production code to fulfill that test.  The goal of developer TDD is to specify a detailed, executable design for your solution on a JIT basis.  Developer TDD is often simply called TDD.

Ideally, you'll write a single acceptance test, then to implement the production code required to fulfill that test you'll take a developer TDD approach. This in turn requires you to iterate several times through the write a test, write production code, get it working cycle at the developer TDD level.

Why TDD?

A significant advantage of TDD is that it enables you to take small steps when writing software.  This is a practice that I have promoted for years because it is far more productive than attempting to code in large steps.  For example, assume you add some new functional code, compile, and test it.  Chances are pretty good that your tests will be broken by defects that exist in the new code.  It is much easier to find, and then fix, those defects if you've written two new lines of code than two thousand. The implication is that the faster your compiler and regression test suite, the more attractive it is to proceed in smaller and smaller steps.  I generally prefer to add a few new lines of functional code, typically less than ten, before I recompile and rerun my tests.


Contributors:

Our Data is Not Secure - Ever play Angry Birds or Candy Crush Saga?

Our Data is Not Secure

Ever Play Angry Birds?  Your information has been stolen.

Open up any newspaper or news website and you can find stories about the NSA data mining, Google, Facebook, LinkedIn, Yahoo, and Microsoft receiving requests to send information to the our government, and local government agencies snooping into your phones and computers.

Currently, at the olympics in Russia, there is an enormous effort underway to steal data from the people visiting the county which is authorized by the Russian government.

At the olympics, "Russian law allows its intelligence agents to do electronic snooping on anyone inside the country, meaning the phones and personal computers of thousands of foreign visitors, including Americans, are fair game. But even outside of the law, Russian organized crime groups also are well known for hacking smartphones and email for information they use for illicit profit." (ABC News, 2014)

Here at home, "The National Security Agency has secretly broken into the main communications links that connect Yahoo and Google data centers around the world, according to documents obtained from former NSA contractor Edward Snowden and interviews with knowledgeable officials.

By tapping those links, the agency has positioned itself to collect at will from hundreds of millions of user accounts, many of them belonging to Americans. The NSA does not keep everything it collects, but it keeps a lot." (Washington Post, 2014)

"If you're spending hours on your phone playing games like Angry Birds and Candy Crush Saga, or posting online to Google+ and Pinterest, you're probably being spied on. The latest releases from NSA whistle blower Edward Snowden reveal that the National Security Agency, and its UK counterpart, GCHQ, are mining the ad networks utilized in these apps to collect a trove of information on you." (WonderHowTo, 2014)

Even the local government agencies are jumping on board, "Armed with new technologies, including mobile devices that tap into cellphone data in real time, dozens of local and state police agencies are capturing information about thousands of cellphone users at a time, whether they are targets of an investigation or not, according to public records obtained by USA TODAY and Gannett newspapers and TV stations.

The records, from more than 125 police agencies in 33 states, reveal:

About one in four law-enforcement agencies have used a tactic known as a "tower dump," which gives police data about the identity, activity and location of any phone that connects to the targeted cellphone towers over a set span of time, usually an hour or two. A typical dump covers multiple towers, and wireless providers, and can net information from thousands of phones." (USA Today, 2013)

I have been telling my friends about this possibility for years.  Remember this next time you ignore the fine print and agree blindly to the Terms of Use for that cool free app.

Office Politics - Navigating the Political Waters

Office Politics - Navigating the Political Waters

Navigating the Waters

Some people take to office politics naturally. You know the ones who are irresistibly likeable and don't appear to have a manipulative bone in their bodies. They always seem to get people to gladly cooperate on projects. For other folks, actively playing the politics game is uncomfortable and feels inherently insincere. Regardless of which category you fall into, it helps to learn how office politics works. At least it could clear up common misperceptions about the practice and help you reevaluate your own motivations and tactics.

Office Politics

Office politics is at the core of all organizations. Paying attention to it can be just as important as fulfilling the responsibilities written in your job description. If you aren't on the watch for it or don't tactfully engage in it, you could jeopardize your career and watch your hard work and loyalty go down the drain. If this sounds like an exaggeration, consider how things work in your own office. People who get promoted are probably heavily involved in office politics. They often voice suggestions for improvements and make themselves known. Those who consider politics beneath them keep to themselves and appear unfriendly or unmotivated, even if they work hard. When budget cuts are necessary, these people might be the first heads on the chopping block.

A Necessary Evil

Office politics is a necessary evil. With over 20 years in the corporate world I have never seen anyone effectively exclude themselves from office politics. Unfortunately it is a sink or swim scenario.  As much we you would like to exclude ourselves, it is impossible.

Integrity

Avoid Gossip

Maintaining your integrity is a hard proposition when you are mired down in office politics. Avoiding office gossip is the number one way to maintain your integrity. The minute you find yourself dragged into gossip you must pull yourself out graciously. I have been as bold to say that I do not partake in gossip. This works if you know who you are talking to. Saying this to your manager is probably not a good move towards ensuring job longevity.

Office Landmines

Without even knowing, you could be offending your boss, coworkers, or stepping on someone else's toes. When you take over a job, a project or even a nice office that previously belonged to a well-liked coworker, it might foster bitterness and make it harder to work with his allies. Being on the lookout for these issues and addressing them could help you make peace with people you might unintentionally be offending. Indeed, the authors of "Enlightened Office Politics" suggest that you owe it to your company to engage in its politics, because it's the necessary avenue to getting things done.

Climb the Corporate Ladder

The Corporate Ladder

Unless you're an expert office politician, you won't get anywhere unless you've proven yourself to some degree. To climb the corporate ladder, you usually can't rely on empty words and promises, but you must be able to impress the higher-ups with a good reputation backed by solid accomplishments. That's not to say your political skills can't help you do this. In fact, political skill might be the best tool. This is where the alliances you formed with coworkers really pay off. Landing a big account or succeeding at a large project usually requires help from all sides, and if you've done well, you can call your allies into action.


Unfortunately, it's possible no one will notice your accomplishments unless you tell them and remind them. It is suggested that you occasionally brag -- as diplomatically as possible -- about your achievements even when you're not interviewing for an open position. If this seems difficult or even unnatural, try to at least convey how proud you are to have made a difference for the company.

Mastering office politics is not only about climbing the ladder. To me, it is more about earning the respect of my peers. The only way I can be effective at my job is to be able to work with my peers every day. If I don't have credibility at my level, worrying about climbing the corporate ladder is a moot point.



Contributors:

Is it a ScrumMaster weakness, or is there more to it?

Is it a ScrumMaster weakness, or is there more to it?

I have noticed that no two companies utilize Agile in the same way, it is always a hybrid. Such as Agil-fall, Water-gile, Scum-ban, and Agil-icious (Okay, I made that one up).

Slow Erosion

They key to Agile's success is how the ScrumMaster (SM) deals with the variations.  I heard from multiple recruiters that some SMs are rigid in their approach.  This is the letter of law of Scrum and I don't allow for deviation, to paraphrase.  In my opinion, that goes against the very meaning of being agile -  "having a quick resourceful and adaptable character."

This is a slow erosion of Agile principles that needs to be corrected.  If the SM fails to perform at a high level the Scrum framework will collapse under its own weight.

I feel the underlying reason this is happening stems from thinking one can take a 2-day training class and miraculously become an effective ScrumMaster.  

To me, that is like saying once a Medical Doctor (MD) gets certified he is good at what he does.  I don't know about you but I don't want a rookie MD cutting into my body.

I feel it takes at least a year of working in an Agile/Scrum environment before the ScrumMaster can fully understand the system.  It takes even more years to learn the variations.

The Agile methodology is only as strong as the people working within it.  The Product Owner position seems to be understood, but the importance of the SM position continues to be underestimated.

ScrumMasters communicate complex issues to product, stakeholders & developers. They coach engineers. They coach product. They coach executives. They foresee roadblocks and adjust around or plow over them. They report. They manage tools. They define processes. They bust-up ineffective overhead. They empower those around them. They manage (effective) meetings. They lead by example. They ship (damn good) code. They take the blame. They deflect the praise. They listen. They suggest. They rally the troops. They make work fun.


More importantly than all else, however, they seek & speak the truth - regardless of the fallout.


Contributors:

Unscrum Hero

Test Driven Development (TDD) - Explained

Test Driven Development (TDD)

Define

Test Driven Development (TDD) is about writing the test first before adding new functionality to the system.

Explain

The cycle at the heart of TDD is:

• Write a test (test fails - RED)
• Write some code to get the test to pass (GREEN)
• REFACTOR the code to be as simple an implementation of the tested features as possible
• Repeat

Agile developers work in this circle of life when adding new code. Write the test first. Make it pass. Then refactor.

Tests provide feedback regarding:

• Whether the system works
• If the system is well-structured

By writing the Test first, we get double the benefit. 

The Exercise of Writing the Tests:

• Makes us clarify the acceptance criteria for the next piece of work - we have to ask ourselves how we can tell when we are done (design)
• Encourages us to write loosely coupled components, so they can easily be tested in isolation and, at higher levels, combined together (design)
• Adds an executable description of what the code does (design)

Running the Tests:

• Detects errors while the context is fresh in our mind (implementation)
• Let us know when we've done enough, discouraging over-loading the code and adding unnecessary features (design)

This feedback cycle can be summed up by the Golden Rule of TDD: "Never write new functionality without a failing test"


Contributors:

"Growing Object-Oriented Software, Guided by Tests" by  Steve Freeman and Nat Pryce

Six Levels of Agile Planning

Six Levels of Agile Planning

Definition

One of the misconceptions is that agile process doesn't do enough planning. In reality, Agile does lot more planning and risk mitigation than traditional processes. Agile focuses on planning very often instead of doing comprehensive and assumption based planning once. Agile Planning (a.k.a. planning onion) has 6 levels - Strategy, Portfolio, Release, Iteration, Daily, and Continuous.

Think of Agile planning a layers of an onion. We peel them back one a time to give you a thorough understanding about how to perform each step.

Agile Planning Onion Layers

1. Strategy
2. Portfolio
3. Release
4. Iteration
5. Daily
6. Continuous

Agile Strategy Planning

Projects and product development efforts ideally start with a vision associated with a business need or direction. This vision is then typically framed in context of a strategy and associated goals and objectives during a management team planning session. Strategy is the creation of a unique and valuable position, involving a different set of activities and it involves making choices throughout the value chain that are interdependent.

Agile Portfolio Planning

Goal of portfolio management (strategy execution) is to minimize value evaporation and maximize value retention. Strategy creates value but some of it evaporates due to poor execution and other organizational frictions. To understand Value Evaporation, assume that the strategy is right and, therefore, value creating. Thus, if there is any loss in value due to a poor strategy, it is not a part of Value Evaporation.

A good agile strategy cannot prevent the evaporation of value. Think of a tropical village that is perpetually short of water. So, the villagers come up with a strategy. It involves digging a big hole in the ground to create a reservoir of water from natural rain. The strategy works. The reservoir fills up. But the villagers forgot how mercilessly hot the tropical sun can be. The reservoir did not last very long. Evaporation returned its water to the atmosphere. For the villagers, what matters is not just how much water was there in the reservoir initially, but how much is retained after evaporation. 

The same is true for any organization. Its goal is to come up with a strategy that maximizes value retention by incremental and mutually reinforcing execution of value chain. Key for value retention is to manage portfolio by inspecting and adapting in small increments to utilize feedback from internal and external customers.

Agile Release Planning

Release planning is the third layer of Agile Planning Onion. Releases represent the large-grained delivery cycle in agile development. Releases typically range between one and six months, but may extend longer in some environments. Key for agile release planning is to continuously add value in small increments to utilize feedback from internal and external customers. Following diagram depicts how traditional execution differs from agile execution. In traditional execution, value is stacked and only delivered in the end. On the contrary, agile execution creates continuous value chains driven by agile portfolio management.

Releases begin with a release planning meeting where product owners (or product managers, project leads, etc.) work to define and prioritize a candidate set of features that are then estimated by the team.

Agile Iteration Planning

Iteration planning is the fourth layer of Agile Planning Onion. Also known as Sprints, iterations are short, fixed-length subsets of releases, generally in the 1-4 week time frame. Iterations represent the execution heartbeat of the project. During each iteration the team's goal is to deliver potentially shippable software. 

Iterations incorporate three key phases:

1. Ready (backlog grooming, iteration planning)
2. Remove impediments throughout the execution (daily standup meeting)
3. Done - usually agreed by the team as a definition of done (iteration review and retrospective)

Agile Daily Planning

This is the fifth layer of Agile Planning Onion. Every day the team is focused on completing the highest priority features in the form of working, tested software. As features are delivered within the iteration, they are reviewed and accepted, if appropriate, by the product owner. Each day a short, 15-minute stand-up meeting facilitates the communication of individual detailed status and any impediments or issues. Product is integrated and tested on a daily basis. Burndown charts are the key tool for the team to review progress on a daily basis. These charts help teams to take corrective actions quickly. 


Agile Continuous Planning

This is the final and one of the most critical layer of the Agile Planning Onion. Agile product development teams are constantly driving towards a state of continuous, adaptive planning, collaboration, design, development, testing and integration. This commitment fosters a dynamic, highly productive environment in which automation is critical and the output is always high-quality, valuable working software.

Visit Agile, LLC Today

Contributors:

Kanban - In a Nutshell

Kanban - In a Nutshell

Visit Agile, LLC Today

Definition

Kanban is a method for developing software products and processes with an emphasis on just-in-time delivery while not overloading the software developers. In this approach, the process, from definition of a task to its delivery to the customer, is displayed for participants to see and developers pull work from a queue.

Kanban can be divided into two parts:

• Kanban – A visual process management system that tells what to produce, when to produce it, and how much to produce.
• The Kanban method – An approach to incremental, evolutionary process change for organizations.

The Kanban Method

Kanban - Signboard

The name 'Kanban' originates from Japanese, and translates roughly as "signboard". Kanban traces back to the early days of the Toyota production system. Taiichi Onho developed the Kanban system between 1940-1950 to control production between processes and to implement Just In Time (JIT) manufacturing at Toyota manufacturing plants in Japan. The Kanban method as formulated by David J. Anderson is an approach to incremental, evolutionary process and systems change for organizations. It uses a work-in-progress limited pull system as the core mechanism to expose system operation (or process) problems and stimulate collaboration to continuously improve the system. One example of such a pull system, is a Kanban system, and it is after this popular form of a work-in-progress, limited pull system that the method is named.

The Kanban method is rooted in these basic principles:

Start with what you do now

• The Kanban method does not prescribe a specific set of roles or process steps. 
• There is no such thing as the Kanban software development process or the Kanban project management method. 
• The Kanban method starts with the roles and processes you have and stimulates continuous, incremental and evolutionary changes to your system.

Agree to pursue incremental, evolutionary change

• The organization (or team) must agree that continuous, incremental and evolutionary change is the way to make system improvements and make them stick. 
• Sweeping changes may seem more effective but more often than not fail due to resistance and fear in the organization. 
• The Kanban method encourages continuous small incremental and evolutionary changes to your current system.

Respect the current process, roles, responsibilities and titles

• It is likely that the organization currently has some elements that work acceptably and are worth preserving. 
• We must also seek to drive out fear in order to facilitate future change. 
• By agreeing to respect current roles, responsibilities and job titles we eliminate initial fears. This should enable us to gain broader support for our Kanban initiative. 
• Perhaps presenting Kanban against an alternative more sweeping approach that would lead to changes in titles, roles, responsibilities and perhaps the wholesale removal of certain positions will help individuals to realize the benefits.

Leadership at All Levels

Acts of leadership at all levels in the organisation from individual contributors to senior management should be encouraged.

Six Core Practices

Anderson identified five core properties that had been observed in each successful implementation of the Kanban method. They were later relabeled as practices and extended with the addition of a sixth.

Visualize

• The workflow of knowledge work is inherently invisible. Visualizing the flow of work and making it visible is core to understanding how work proceeds. Without understanding the workflow, making the right changes is harder.
• A common way to visualize the workflow is to use a card wall with cards and columns. The columns on the card wall representing the different states or steps in the workflow.

Limit WIP

• Limiting work-in-process implies that a pull system is implemented on parts or all of the workflow. The pull system will act as one of the main stimuli for continuous, incremental and evolutionary changes to your system.
• The pull system can be implemented as a Kanban system. The critical elements are that work-in-process at each state in the workflow is limited and that new work is “pulled” into the new information discovery activity when there is available capacity within the local WIP limit.

Manage Flow

• The flow of work through each state in the workflow should be monitored, measured and reported. 
• By actively managing the flow the continuous, incremental and evolutionary changes to the system can be evaluated to have positive or negative effects on the system.

Make Policies Explicit

• Until the mechanism of a process is made explicit it is often hard or impossible to hold a discussion about improving it. Without an explicit understanding of how things work and how work is actually done, any discussion of problems tends to be emotional, anecdotal and subjective. 
• With an explicit understanding it is possible to move to a more rational, empirical, objective discussion of issues. This is more likely to facilitate consensus around improvement suggestions.

Implement Feedback Loops

• Collaboration to review flow of work and demand versus capability measures, metrics and indicators coupled with anecdotal narrative explaining notable events is vital to enabling evolutionary change. 
• Organizations that have not implemented the second level of feedback - the operations review - have generally not seen process improvements beyond a localized team level. As a result, they have not realized the full benefits of Kanban observed elsewhere.

Improve Collaboratively, Evolve Experimentally

• The Kanban method encourages small continuous, incremental and evolutionary changes that stick. 
• When teams have a shared understanding of theories about work, workflow, process, and risk, they are more likely to be able to build a shared comprehension of a problem and suggest improvement actions which can be agreed by consensus.
• The Kanban method suggests that a scientific approach is used to implement continuous, incremental and evolutionary changes. The method does not prescribe a specific scientific method to use.

Contributors: