The foundations of agile – Lean Software Development, Theory of Constraints and Systems Thinking

During a recent brown bag lunch I gave a presentation on the foundations of agile. I talked about the some of the underlying philosophies and methodologies that have influence agile software development.

The presentation covered a little bit of history before looking at Lean Software Development (and it development from the Toyota Production System), The Theory of Constraints and Systems Thinking.

The presentation can be found here.

Remember to have a look at the slide notes, as it has some more information not included on the slides themselves.

Advertisements

Getting started with automated acceptance tests in an Agile project

Automated testing can bring great benefits to an Agile project but it is not always clear how to best integrate the processes and practices effectively. In this post I will outline a few ideas that might help, along with some pitfalls, based on experience gained from my own projects.

What is automated acceptance testing?

I am using the term automated acceptance tests to mean tests that exercise a system from it’s most external interface. For the purposes of this post I will be mainly talking about tests that exercise the user interface but it could also mean tests that exercise an externally visible API such as a web service. The important thing about the tests is that they test the expected behaviour of the system, ensuring that the desired functionality is met. This builds an executable specification for the system.

What does it bring to an Agile project?

In this post I am going to use terms that are from Scrum in particular, but the points covered are applicable to any Agile process (and more than likely non Agile processes as well).

Agile projects are focused on meeting the needs of their customers (Product Owner in Scrum terms) and one of the ways this is done it to use acceptance criteria to define the expected behaviour of a particular user story. It is very valuable to be able to prove that that the acceptance criteria have been satisfied, whilst building a very comprehensive suite of automated regression tests. A suite of automated acceptance tests gives incredible confidence when building the system, especially in Agile developments where there may be refactoring and changes of direction as the changing needs of the Product Owner are met.

Where does automated testing fit into the process?

One of the most important things I have learnt from using automated acceptance testing on an Agile project is that it has to be a first class part of the development process. Depending on the maturity of your team this may mean having an explicit step or task to ensure it gets done, or having it as part of your definition of done. Either way it needs to be given the same level of importance as the other practices. A story cannot be done without automated tests that at least cover the acceptance criteria of the story. It is almost certain that when time is tight and people are under pressure that the automated tests will be the first things to be skipped. This is almost always a mistake, and one which I have learnt the hard way. Missing acceptance tests will come back to haunt you. Include them in your process and account for them in your planning activities.

Who writes the automated tests?

The creation of automated acceptance tests requires input from all the members of an Agile team. The roles and make up  in your Agile team may differ, but typically acceptance criteria will be generated with the input of the product owner and analyst (and maybe also the tester in some teams) who will also create specific scenarios that will be automated. As the tests are automated there is obviously some development work in order to perform the automation. There are ways to gain a lot of reuse form a test suite and to reduce the amount of additional development required to extent the suite. I will talk about some of these when looking at some specific tools and technologies in a later section.

What does it mean to ‘traditional’ testing for the project?

In recent years I have become more convinced that it is no longer possible to speak about the traditional silo’d roles in software development. The roles of analyst, developer and tester continue to become blurred as roles change and responsibilities overlap. The creation of automated acceptance tests require a little bit of all these traditional disciplines. Who will be involved in your team depends on the skills and abilities of the team members. To make automated testing work in your team it will be necessary to let go of the idea that developers don’t do testing, or that testers don’t write code.

That said, automated acceptance tests are not meant as a replacement to traditional exploratory testing or to undermine the role of traditional testing in any way. Instead they should be seen as complimentary.

This is a great post that discusses the aims of automated and exploratory testing:

Automated vs. exploratory – we got it wrong!

Automated acceptance testing as part of the build process

To get the most out of automated acceptance tests they need to be part of your Continuous Integration build. Acceptance tests are never going to be fast running, and this can pose some challenges to getting the best feedback from your tests. As an indication, my current project has about 300 Selenium based tests and takes about an hour to run. We are 7 sprints in and the number of tests is going to get much higher. At present we have a fast CI build running only the unit tests to give instant feedback, followed by an integration build containing all the acceptance tests that runs after a successful CI build. We are finding that the feedback is a bit slow and are planning to introduce the concept of a ‘current’ integration build that will run a subset of the acceptance tests that have been tagged as being in the area which fast feedback is required (i.e. area in which work is being undertaken). The full set of tests will continue to run at their slower cadence.

Using the right tools

My tools of choice are SpecFlow and Selenium Web Driver, but there are others that perform a similar function. It is important to understand the tools and the best way to use them. When talking about automated acceptance tests, and specifically using Selenium to drive the browser, I often encounter people who have tried to do automation and then have stopped as the tests become brittle and the cost of maintenance becomes too high.  Here are a few tips from my experience of using automated acceptance tests on a large project:

  • Aim to get a lot of reuse from your SpecFlow scenarios. Use the features built into SpecFlow, such as the Scenario.Context.Current and it’s DI capabilities, to make steps that can be reused across many features. If done correctly you will find that it is very easy to add new tests without writing any new steps at all.
  • Us the page object pattern to encapsulate the logic for the web pages. This is the one of the single biggest factors to ensuring your test suite is maintainable. Without page object you will find yourself fixing lots of tests due to a small change to a single page.
  • Thing about the wider ecosystem. We are using Selenium Server to give us the ability to run tests across multiple browsers.
  • Learn about you tools to get the best from them. Writing the automation will be a lot more pleasurable of you understand how things are working.

The posts below discuss how to make a start writing maintainable automated acceptance tests:

Behavioural testing in .Net with SpecFlow and Selenium (Part 1)

Behavioural testing in .Net with SpecFlow and Selenium (Part 2)

Managing SpecFlow acceptance test data with Entity Framework

Summary

  • Automated acceptance tests are about building an executable specification for your system.
  • The executable specification is very useful to to prove the acceptance criteria have been met and to give confidence that changed have not broken functionality.
  • Make automated tests part of your process. Do not skimp on them, even if you are under pressure to get things done. Add them to your definition of done.
  • Creating the tests is an activity for all the team, although traditional roles and responsibilities may be blurred.
  • Automated tests are in addition to traditional exploratory style testing and are not meant as a replacement.
  • Get the most from your tests by choosing a sensible CI strategy to give the best feedback
  • Choose the right tools for the job, and spend time learning to get the best from them
  • Become an advocate of automated testing in your organisation

Behavioural testing in .Net with SpecFlow and Selenium (Part 2)

In this series of posts I am going to run through using Selenium and SpecFlow to test .Net applications via the user interface. I will talk about the situations this type if testing can be used, and how we can create effective, non-brittle test with the help of the Page Objects Pattern.

The series in full:

In the first post in this series I looked at creating a scenario with SpecFlow and generating some empty step definitions. In this post I will implement the steps using Selenium in order to make the scenario test pass.

Selenium

Selenium is a web automation framework. In simple terms it allows you to drive a browser via code. Selenium can be used in many browser automation situations, but one of  it’s main uses is for automated testing of web applications.

When it comes to testing the behaviours of web pages there has traditionally been a problem where the testing code becomes tied to the implementation details of the page. This can make the tests brittle as a change to the page implementation details, such as a change to a field name or Id, will break the test even if the behaviour of the page has not changed.

In order to protect against this it is desireable to encapsulate the implementation details of a page under test in a single place, so that if there is an implementation change there is only a single place to change, instead of having to fix all the separate bits which rely on those details.

Separating the behaviour of a page from its implementation details is the purpose of the Page Object pattern. A page object is simply a class that encapsulates the implementation details for a web page, allowing the automation to focus only on behaviour.

Implementing the first scenario

The first test is all about the Search Page so it is the Search Page page object that is first to be created. I find it easiest to work in a TDD style workflow, using the SpecFlow steps to guide me towards the implementation one step at a time. Lets have a look at the implementation:

public class CrazyEventsSearchPage
{
    [FindsBy(How = How.Id, Using = "region")]
    private IWebElement regionDropdown;

    [FindsBy(How = How.Name, Using = "Submit")]
    private IWebElement submitButton;

    private static IWebDriver driver;

    public static CrazyEventsSearchPage NavigateTo(IWebDriver webDriver)
    {
        driver = webDriver;
        driver.Navigate().GoToUrl("http://localhost:2418/event/Search");
        var searchPage = new CrazyEventsSearchPage();
        PageFactory.InitElements(driver, searchPage);
        return searchPage;
    }

    public void SelectRegionDropdown()
    {
        regionDropdown.Click();
    }

    public IList<string> GetAllPossibleRegions()
    {
        var selectList = new SelectElement(regionDropdown);
        var options = selectList.Options;

        return options.Select(webElement => webElement.Text).ToList();
    }
}

Remember that the job of a page object is to encapsulate the implementation details of a web page. Selenium provided some helper for working with page objects. To use them make sure you have installed the Selenium Webdriver Support Classes into your test project via NuGet. PageFactory.InitElements(driver, searchPage) take a page object, in this case searchPage and ensures that all the elements are populated with the details from the web page. In this case it will populate the regionDropdown and submitButton web elements ready to be used.

It is the methods and fields of the page object that encapsulate the implementation details. If the id of the region needs to be changed, only the WebDriver FindsBy attribute that would need to be changed. If submitting the form needed to do something else, only a single change would be required.

The NavigateTo method is used as the entry point into the web site. The other methods are used by the SpecFlow steps.

[Binding]
public class EventSearchSteps
{
    private CrazyEventsSearchPage searchPage;
    private CrazyEventsSearchResultsPage searchResultsPage;
    private IWebDriver driver;

    [BeforeScenario()]
    public void Setup()
    {
        driver = new FirefoxDriver();
    }

    [AfterScenario()]
    public void TearDown()
    {
        driver.Quit();
    }

    [Given(@"that I want to search for an event by region")]
    public void GivenThatIWantToSearchForAnEventByRegion()
    {
        searchPage = CrazyEventsSearchPage.NavigateTo(driver);
    }

    [When(@"a list of possible regions is presented")]
    public void WhenAListOfPossibleRegionsIsPresented()
    {
        searchPage.SelectRegionDropdown();
    }

    [Then(@"the list should contain ""(.*)"", ""(.*)"", ""(.*)"" and ""(.*)""")]
    public void ThenTheListShouldContainAnd(string p0, string p1, string p2, string p3)
    {
        var regions = searchPage.GetAllPossibleRegions();
        Assert.IsTrue(regions.Contains(p0));
        Assert.IsTrue(regions.Contains(p1));
        Assert.IsTrue(regions.Contains(p1));
        Assert.IsTrue(regions.Contains(p1));
    }

    [Then(@"""(.*)"" should be the default value")]
    public void ThenShouldBeTheDefaultValue(string p0)
    {
        var selectedRegion = searchPage.GetSelectedRegion();
        Assert.IsTrue(selectedRegion.Contains(p0));
    }
}

I have added some setup and teardown methods to ensure that the web driver is initialised and shut down correctly. With all the implementation in place the scenario now passes.

Another scenario

Its time to add another scenario:

Scenario: Search for events in a region and display the results
	Given that I want to search for an event by region
	When I select the "London" region
	And perform a search
	Then The search results page is displayed
	And the following results are displayed
	| Event Code | Event Name                        | Region | Description                           |
	| CH/3001    | Cat Herding                       | London | A starter session for the uninitiated |
	| CH/302     | Cat Herding - Advanced techniques | London | Taking it to the next level           |

This scenario uses a SpecFlow table to define the expected results. Gherkin has a lot of powerful features to make the most of defining scenarios. The steps definitions were generated in the same way as the first scenario. I created another page object for the search results:

public class CrazyEventsSearchResultsPage
{
    private static IWebDriver driver;

    [FindsBy(How = How.Id, Using = "searchResults")] private IWebElement searchResults;

    public CrazyEventsSearchResultsPage(IWebDriver webDriver)
    {
        driver = webDriver;
    }

    public bool IsCurrentPage()
    {
        return driver.Title == "Crazy Events - Search Results";
    }

    public List<List<string>> GetResults()
    {
        var results = new List<List<string>>();
        var allRows = searchResults.FindElements(By.TagName("tr"));
        foreach (var row in allRows)
        {
            var cells = row.FindElements(By.TagName("td"));
            var result = cells.Select(cell => cell.Text).ToList();
            results.Add(result);
        }

        return results;
    }
}

This page object doesn’t have a direct entry point, as this page cannot be reached directly without a search being performed. Instead it is reached from the search page object. I have added some extra functionality for performing the search and initialising the search results page object. We will see these in a moment.

And the step definitions for the new steps. Remember that any identical steps share an implementation.

[When(@"I select the ""(.*)"" region")]
public void WhenISelectTheRegion(string region)
{
    searchPage.SelectRegion(region);
}

[When(@"perform a search")]
public void WhenPerformASearch()
{
    searchResultsPage = searchPage.SubmitSearch();
}

[Then(@"The search results page is displayed")]
public void ThenTheSearchResultsPageIsDisplayed()
{
    Assert.IsTrue(searchResultsPage.IsCurrentPage());
}

[Then(@"the following results are displayed")]
public void ThenTheFollowingResultsAreDisplayed(Table table)
{
    var results = searchResultsPage.GetResults();
    var i = 1; //ignore the header

    foreach (var row in table.Rows)
    {
        Assert.IsTrue(results[i].Contains(row["Event Code"]));
        Assert.IsTrue(results[i].Contains(row["Event Name"]));
        Assert.IsTrue(results[i].Contains(row["Region"]));
        Assert.IsTrue(results[i].Contains(row["Description"]));
        i++;
    }
}

The additional methods for the search page object are:

public string GetSelectedRegion()
        {
            var regionElement = new SelectElement(regionDropdown);
            return regionElement.SelectedOption.Text;
        }

        public void SelectRegion(string region)
        {
            var regionElement = new SelectElement(regionDropdown);
            regionElement.SelectByText(region);
        }

        public CrazyEventsSearchResultsPage SubmitSearch()
        {
            submitButton.Click();

            var searchResultsPage = new CrazyEventsSearchResultsPage(driver);
            PageFactory.InitElements(driver, searchResultsPage);

            return searchResultsPage;
        }

The SubmitSearch() method initialises the search results page object ready to be used in the scenario steps.

In conclusion…

Page objects are a powerful way to overcome the traditional problems with automated browser tests. When Selenium is coupled with SpecFlow they allow for a TDD style workflow that can give true outside-in development.

Another useful side effect of using SpecFlow scenarios is that the steps create an API for the application. Once the steps have been created it is possible to create new scenarios without any coding at all, which means that it is accessible to members of the team who might have otherwise found implementing tests a bit too developer centric.

Even the implementation of the page objects is not generally too complicated once the pattern has been established.  I appreciate that there is a bit more of a learning curve but I think this type of testing offers far more that the record and playback type behavioural tests and would be a useful skill for all team members to have.

Finally, as with all code, do not hesitate to refactor the scenarios, steps and page objects. There are lots of things that could be refactored in this simple example. A couple of the obvious things are the hard coded URL and logic that is used to get the data from the search results page. I will leave these as an exercise for the reader.

The series in full:

Behavioural testing in .Net with SpecFlow and Selenium (Part 1)

In this series of posts I am going to run through using Selenium and SpecFlow to test .Net applications via the user interface. I will talk about the situations this type if testing can be used, and how we can create effective, non-brittle test with the help of the Page Objects Pattern.

The series in full:

I have consciously avoided using the term Behaviour Driven Development (BDD) in the title as this post isn’t really about BDD as such. It is about using some tools in a way that could be used in many situations, with BDD being just one of them. I want to discuss how to use the BDD Framework SpecFlow and the web automation framework Selenium to create tests that test an application via it’s web user interface.

When to use this approach

You could use this approach in several situations. In any situation the idea is to create an executable specification and create automated testing for your code base. The two most common situations are:

  1. Automated acceptance tests – lets call this approach ‘test afterwards’. There is often a desire to create acceptance tests (or integration tests or smoke tests or whatever…) for an application. Using SpecFlow and Selenium you can create tests that test the application as a user would actually interact with it. A suite of acceptance tests is a worthwhile addition to any application.
  2. Behaviour Driven Development style – This is the ‘test before’ approach. In Test Driven Development with MVC I talked about how a true BDD style would ideally test user interaction with the application. These tools allow you to do just that. The workflow would be very similar to the outside-in approach I describe in the post, only you would create scenarios in SpecFlow instead of writing unit tests. Of course there are tons of approaches when it comes to BDD, this being  just one of them. Liz Keogh has a useful summary and introduction to BDD that is worth a look if you want to know more about it.

In this post I am going to use a test afterwards approach so that I can focus on the tooling.

Installing SpecFlow and Selenium

I have created a new folder to house my acceptance tests. Installing Selenium is easy, simply grab the latest version from NuGet (you are using NuGet, right?). Make sure to select Selenium WebDriver. For SpecFlow grab the latest version from NuGet and then get the Visual Studio integration from the Visual Studio Gallery. This will add some extra VS tooling we will use later.

The first scenario

I am going to revisit the event search scenario’s from Test Driven Development with MVC and expand on them a little. The first thing is to add a SpecFlow feature file to the project. Right click on the project and select New item.. Add a new SpecFlow feature file. I have called mine EventSearch.feature. The feature file has feature,which is essentially a user story, and a number of scenarios in the Given When Them format.

The feature files are written in the Gherkin language, which is intended to be a human readable DSL for describing business behaviour.

Lets start populating the feature file with the first scenario.

Feature: EventSearch
	In order to find an event to participate in
	As a potential event delegate
	I want to be able to search for an event

Scenario: Event Search Criteria should be displayed
	Given that I want to search for an event by region
	When I select to choose a region
	Then a list of possible regions is presented
	And the list should contain "All", "North", "South" and "London"
	And "All" should be the default value

The next step is to create the bindings that allows us to wire up the Gherkin feature to our application’s code. Before we do that we just need to tell SpecFlow to use Visual Studio’s testing framework MSTest instead of the default NUnit. This is done by adding a line  of configuration to your app.config, you will find the SpecFlow section already exists:

<specFlow>
<!-- For additional details on SpecFlow configuration options see http://go.specflow.org/doc-config -->

    <unitTestProvider name="MsTest.2010"/>
</specFlow>

As a brief aside, you will notice that the feature file has a code behind .cs file that has been created by SpecFlow. If you have a look inside you will see that the code is a rather awkward looking MSTest test class. It is used to run the Scenario’s that are described in the feature file and implemented in the binding step definitions we are about to create. It is not pretty, but it is not intended to be read or edited by a user as it is generated by SpecFlow when the feature file is saved. SpecFlow will generate the correct type of testing hooks for the test framework you are using.

Create the step definitions

The step definitons are where we add code to perform the tests. The step defintions are defined in a file with a [Binding] attribute. When we run the feature the test runner run the test defined in the feature code-behind which is bound to these steps by SpecFlow. The easiest way to create these bindings is to use SpecFlows Visual Studio tooling. Right click on the scenario in the feature file and select “Generate step definitions”. This brings up a dialogue box that allows you to create the necessary bindings to wire up the test. I created the bindings in a new class called EventSearchSteps. The generated bindings look like this:

using System;
using TechTalk.SpecFlow;

namespace CrazyEvents.AcceptanceTests
{
    [Binding]
    public class EventSearchSteps
    {
        [Given(@"that I want to search for an event by region")]
        public void GivenThatIWantToSearchForAnEventByRegion()
        {
            ScenarioContext.Current.Pending();
        }

        [When(@"a list of possible regions is presented")]
        public void ThenAListOfPossibleRegionsIsPresented()
        {
            ScenarioContext.Current.Pending();
        }

        [Then(@"the list should contain ""(.*)"", ""(.*)"", ""(.*)"" and ""(.*)""")]
        public void ThenTheListShouldContainAnd(string p0, string p1, string p2, string p3)
        {
            ScenarioContext.Current.Pending();
        }

        [Then(@"""(.*)"" should be the default value")]
        public void ThenShouldBeTheDefaultValue(string p0)
        {
            ScenarioContext.Current.Pending();
        }
    }
}

The step definitions have been created with a pending implementation ready for us to complete. You will see that some parts of the features have generated steps that contains attributes with what looks like regular expressions, and that the methods have parameters. This is a feature of SpecFlow that allows for reuse of step definitions when the only thing that changes is a string value. We will see how this is used later. SpecFlow has lots of useful features like this, I would advise checking out the documentation to learn more about it.

Lets run the test and see what happens.

Resharper’s test runner shows that the test was inconclusive. This is not really a surprise as the test implementation is pending. Of course you can use Visual Studio’s built in test runner instead.

In the next post we will have a look at how we can implement the bindings with Selenium to automate browser interactions.

The series in full:

Dialogues and discussions

At a recent team meeting thoughts quickly turned to problems with an upcoming release and the state of software development at the organisation. A general feeling that things weren’t better anywhere else gave way to the usual suspects of incomplete requirements, no focus on quality and lack of resources. On the list of things that could be done was a meeting with the team and other members of the department including the development manager and the Head of IT.

Comments were made about the idea of a meeting which included:

  • Similar meetings in the past had made no real difference
  • With senior management present people would not feel able to discuss certain topics
  • Nobody would pay any attention until there was a serious failure

I thought the comments seemed plausible as I have been in enough of those types of meetings to know that this type probably wasn’t going to help, at least not without a change of approach. I recalled Peter Senge talking about different types of discourse, and the differences between them, in ‘The Fifth Discipline‘. I grabbed my copy and started reading. Below I have attempted to summarise my understanding.

Dialogues and discussions

British physicist David Bohm developed the idea that dialogue and discussion are related but different concepts, and that is it the synergy between dialogue and discussion that yields its power. Bohm asserts that this power is unlikely to exist if the distinctions between the two are not appreciated. Most people are aware that not all discussions are the same in tone, focus or outcome but few have thought about, and could explicitly call out the differences in their experiences.

For Bohm, a “dialogue can be considered as a free flow of meaning between people in communication, in the sense of a stream that flows between banks” in an effort to gain understanding of a complex issue. A discussion is used to present different points of view with the intent of finding a course of action. The table below summarises the differences:

Discussion Dialogue
Decision Making A discussion converges on a course of action and decisions are made. Complex issues are discussed, but no decisions are made during dialogue. Instead of a decision, a dialogue diverges to gain understanding, not to seek consensus. The outcome from a dialogue may feed into a discussion when a decision needs to be made.
Purpose Although it is not always immediately obvious, in most cases the purpose of a discussion is to “win” the discussion by having your view accepted by the group. It is not hard to see how this might be at odds with the espoused outcome of a discussion. A dialogue is not won at an individual level, but at a group level. A group accessing a larger pool of common meaning which goes beyond any one individuals meaning.
View point The different views of the group are presented and defended to give an overall view of the situation from different directions. The prefered view is then selected from all the possible alternatives. Different views are presented in a safe environemnt as a means to discover a new viewpoint.

I think it’s fairly safe to say that most organisations cannot always distinguish between the two, as indeed, neither could I until I had read The Fifth Discipline. I can relate to situations that I can now identify as being a dialogue, and some that were discussions. That is not to say that it has to be an either / or situation. Once a team can make the distinction they can move between dialogue and discussion as required.

Context for a dialogue

In order to be able to explore complex issues in a safe environment a context must be established. Bohm establishes some initial conditions:

  • All participants must “suspend” their assumptions “as if suspended before us”. This is not to say the assumptions and opinions are bad, just that we should hold up our opinions for observation, questioning and examination. It is vital that participants are free to talk about their assumptions without prejudice or fear. People are naturally cautious about revealing their assumptions but it is not possible to have a productive dialogue if people are defending their assumptions or are simply unaware of them.
  • All participants must regard one another as colleagues. I know what you are thinking; the people I work with are by definition colleagues. This is not the point Bohm was making. Instead it means that the participants must see the dialogue as a mutual quest for insight without feeling vulnerable to office politics, ridicule, coercion or judgement. One of the initial comments about the meeting hit upon an important related idea: that certain topics would not be discussed freely with senior management present. This is a very common problem (or untested assumption?), but it is vital organisational levels are not recreated in the dialogue. Transparency should transcend hierarchy.
  • A facilitator is a prerequisite as without this the dialogue will be pulled towards discussion. As well as providing the usual benefits of facilitation, the dialogue facilitator should keep the dialogue on track. It is their job to ensure that the conditions of the dialogue are been met. Once a team has become accustomed to dialogues they may find that they can control the dialogue without the need for a facilitator.

Team Learning

As with most concepts in Systems Thinking, establishing effective dialogues takes practice to build the trust and respect required. With practice effective dialogue should also lead to effective discussions.

With regards to the original idea of having a meeting with senior management, it seems to me that the first step should definitely be a meeting in the spirit of dialogue rather than discussion. Not least because there were numerous untested assumptions and some underlying tension present. I acknowledge that this is not an easy thing to do, but team learning has to start somewhere. Also I think the group need to make more opportunities for team learning on the whole, where people can share their views in a safe environment. This could be be with a retrospective like activity following a regular cadence.

Dialogues and discussions in software development

Within Agile software development there are parallels between the ideas of dialogues and discussion, and retrospectives. This should not be a surprise as the purpose of retrospectives is also team learning. As with effective dialogue, effective retrospectives take practice to build the requisite trust within the team. Often retrospectives are structured to have distinct sections of dialogue and discussion. The retrospective prime directive attempts to established the correct context, in effectively asking people to suspend their assumptions and biases. Sections such as setting the scene and gathering information try to explore the complex issue without searching for actions and outcomes. When generating insight the team attempts to converge on a possible set of actions, before finally selecting some tangible actions for the next iteration.

Sources:
Peter Senge – The Fifth Discipline
David Bohm – Bohm dialogue