Book Summary

The 2018 InfoQ Editors’ Recommended Reading List: Part Two

/ Craig Smith / Leave a comment

As part of our core values of sharing knowledge, the InfoQ editors were keen to capture and share our book and article recommendations for 2018, so that others can benefit from this too. In this second part we are sharing the final batch of recommendations

Source: The 2018 InfoQ Editors’ Recommended Reading List: Part Two

Advertisement

BDD In Action (Book Review & Summary)

/ Craig Smith / Leave a comment

BDDInActionI have known John Ferguson Smart for a number of years, bumping into him at various conferences since 2009. When I heard he was writing a book on BDD I was both excited and apprehensive – a number of people have attempted to cover BDD over the years to varying levels of success. I must say I was pleasantly surprised with the outcome – “BDD In Action“.

I have long been an advocate of Test Driven Development (TDD). I have long subscrbed to the definition of TDD being developer test driven at the code level, ATDD being storycard level and BDD being the approach of testing behaviour (most popularly using the Given… When… Then… format. I do understand this is not quite the definition of Dan North, Gojko Adzic or John Smart (the terms are all interchangeable) but one thing I have appreciated more in recent years (particularly after spending time with Gojko) is the importance of the conversation.

Review

BDD In Action kicks off with an in-depth explanation of what BDD is and why it is important before a good end-to-end example. One of the highlights of the book for me was chapter 3 which has some good coverage of different techniques for requirements analysis. Whilst it could be argued that these are not really BDD, they are included as good examples on how to ensure you are working on requirements that are adding business value. The approaches include Feature Injection, Impact Mapping and the Purpose-Based Alignment Model as well as Real Options and Deliberate Discovery.

John has always extended how I define the core roles on the development team (the three amigos) and this is described within the book as well. The second section of the book explains requirements gathering, through to specifications and then basic automation of a DSL at the scenario level. It seems to imply that the tester should be able to write the executable specification and the base automation, although this does not match my experience of most testers in the field.

Section three of the book covers the coding aspects of BDD, including the automation of tests at the UI level as well as the unit testing level. It goes into a fair amount of detail on how different tools work in different languages as well as a fairly comprehensive overview of TDD. The final section of the book introduces living documentation, mainly using tools like Thucyidides as well as how BDD fits into the continuous delivery world.

The book is full of diagrams as well as comprehensive code examples that are well explained and relevant. One of the main advantages of this book is that is not aimed at any tool – in fact it covers a number of tools and languages in a reasonable amount of detail. The other standout books on the subject have either covered the process in great detail (Specfication By Example) or a tool in detail (The Cucumber Book). This does a very reasonable job of both.

This advantage is also its disadvantage – I would hope testers and business analysts would read this book but may be discouraged by the amoutn of code examples which start from very early in the book. On the flipside, there is a good coverage of requirements tools at the beginning of the book that may discourage some developers. I hope that in this world of cross functional teams that this is not the case.

Overall this is a very well written book that covers the full spectrum of BDD (and TDD, ATDD and SBE). It is also good to see a book that has Australian examples in it for a change, including the Sydney train system and the Queensland Health payroll project.

My full book review and interview with John is available on InfoQ.

Summary

Here are my notes from the book:

The Basics

  • BDD was born – It was a response to a triple conundrum: programmers didn’t want to write tests; testers didn’t want programmers writing tests; and business stakeholders didn’t see any value in anything that wasn’t production code (quote from Dan North)
  • BDD is a mechanism for fostering collaboration and discovery through examples – the real goal is to use software to create business impact
  • 2011 edition of the Standish Group’s annual CHAOS Report found that 42% of projects were delivered late, ran over budget, or failed to deliver all of the requested features and 21% of projects were cancelled entirely
  • BDD practitioners use conversations around concrete examples of system behavior to help understand how features will provide value to the business
  • Queensland Health Department – initial budget for the project was around $6 million, cost the state over $416 million since going into production and would cost an additional $837 million to fix. This colossal sum included $220 million just to fix the immediate software issues
  • “When the terrain disagrees with the map, trust the terrain” (Swiss Army proverb)
  • one important benefit of BDD is that it provides techniques that can help you manage this uncertainty and reduce the risk that comes with it
  • Behavior-Driven Development (BDD) is a set of software engineering practices designed to help teams build and deliver more valuable, higher quality software faster
  • North observed that a few simple practices, such as naming unit tests as full sentences and using the word “should,” can help developers write more meaningful tests, which in turn helps them write higher quality code more efficiently. When you think in terms of what the class should do, instead of what method or function is being tested, it’s easier to keep your efforts focused on the underlying business requirements.
  • Acceptance-Test-Driven Development (ATDD) is now a widely used synonym for Specification by Example
  • A feature is a tangible, deliverable piece of functionality that helps the business to achieve its business goals
  • In Gherkin, the requirements related to a particular feature are grouped into a single text file called a feature file. A feature file contains a short description of the feature, followed by a number of scenarios, or formalized examples of how a feature works. Each scenario is made up of a number of steps, where each step starts with one of a small number of keywords (Given, When, Then, And, and But).
  • Given describes the preconditions for the scenario and prepares the test environment. When describes the action under test. Then describes the expected outcomes. The And and But keywords can be used to join several Given, When, or Then steps together in a more readable way:
  • Executable specifications are about communication as much as they are about validation
  • Don’t write unit tests, write low-level specifications
  • Benefits – Reduced waste, Reduced costs, Easier and safer changes, Faster releases
  • Disadvantages – BDD requires high business engagement and collaboration, works best in an Agile or iterative context, doesn’t work well in a silo, poorly written tests can lead to higher test-maintenance costs
  • Spock is a lightweight and expressive BDD-style testing library for Java and Groovy applications. You write unit tests in the form of “specifications,” using a very readable “given … when … then” structure similar to that used in the JBehave scenarios. The >> sign in Spock is shorthand for saying “when I call this method with these parameters, return these values.”

Starting at Requirements

  • Business Analysts will find it useful to identify four things: 1.  Why is the software being built (what is the project’s vision statement)? 2.  How will the project deliver value to the organization (what are the project’s business goals)? 3.  What stakeholders are involved in the project, and how will the project affect them? 4.  What high-level capabilities should the software provide for stakeholders to enable them to achieve their business goals more effectively
  • 1.  Hunt the value. 2.  Inject the features. 3.  Spot the examples
  • In his book Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers, Geoffrey A. Moore proposes a template for a good product vision statement
  • You can also write goals using the following “In order to … As a … I want to …” format: In order to increase ticket sales by 5% over the next year As the Flying High Sales Manager I want to encourage travellers to fly with Flying High rather than with a rival company
  • Some business managers use the SMART acronym: business goals should be Specific, Measurable, Achievable, Relevant, Time-bound
  • The goals of most commercial organizations are, by definition, ultimately financial in nature. In fact, almost all business goals can be grouped into one of the four following categories: Increasing revenue, Reducing costs, Protecting revenue, Avoiding future costs
  • An impact map is a mind-map built during a conversation, or series of conversations, between stakeholders and members of the development team. The conversation centers around four types of questions: Why? Who? How? What?
  • Purpose Based Alignment Model – a feature will fall into one of four categories: Differentiating, Parity, Partner, Minimum impact
  • BDD places great emphasis on building “software that matters” and defines several processes for turning client requirements into something that developers can use to code against and that accurately reflects the core values of the software the client wants, that a project is meant to deliver and the features that will be able to deliver this value.
  • The aim of Feature Injection is to flesh out the minimum set of features that will provide the most benefit to stakeholders in terms of achieving their business goals
  • Project vision, a short statement that provides a high-level guiding direction for the project
  • As a software developer, your job is to design and build capabilities that help the business realize these goals. A capability gives your users the ability to achieve some goal or fulfill some task. A good way to spot a capability is that it can be prefixed with the words “to be able to
  • Features are what you actually build, and they’re what deliver the value
  • Business goal succinctly defines how the project will benefit the organization or how it will align with the organization’s strategies or vocation
  • Repeatedly ask “why” until you get to a viable business goal. As a rule of thumb, five why-style questions are usually enough to identify the underlying business value (known as “popping the why stack)
  • “Don’t tell people how to do things, tell them what to do and let them surprise you with their results”. George S. Patton
  • Not all features are equal. Some features will be areas of innovation, requiring specialized domain knowledge and expertise and adding significant value. Others, such as online payment with credit cards, might be necessary in a market, but won’t distinguish your product from the competition

Building Features

  • Dan North, “Introducing Deliberate Discovery” (2010), http://dannorth.net/2010/08/30/introducing-deliberate-discovery.
  • In BDD terms, a feature is a piece of software functionality that helps users or other stakeholders achieve some business goal
  • User story is a way of breaking the feature down into more manageable chunks, user stories are essentially planning artifacts
  • Features are expressed in business terms and in a language that management can understand. If you were writing a user manual, a feature would probably have its own section or subsection
  • Dan Goodin, “Anatomy of a hack: even your ‘complicated’ password is easy to crack,” http://www.wired.co.uk/news/archive/2013-05/28/password-cracking
  • Real Options in three simple points: Options have value. Options expire. Never commit early unless you know why
  • Deliberate Discovery is the flip side of Real Options – starts with the assumption that there are things you don’t know. Real Options help you keep your options open until you have enough information to act; Deliberate Discovery helps you get this information
  • Three Amigos.” Three team-members—a developer, a tester, and a business analyst or product owner—get together to discuss a feature and draw up the examples

Executable Specifications

  • Scenario starts with the Scenario keyword and a descriptive title: Scenario:
  • The Then step is where the testing takes place—this is where you describe what outcome you expect. A common anti-pattern among new BDD practitioners is to mix the When and Then steps
  • Tables can be used to combine several similar examples more concisely in a single scenario, or to express test data or expected results in a more succinct way
  • Scenarios are organized in feature files
  • One of the core concepts behind BDD is the idea that you can express significant concrete examples in a form that’s both readable for stakeholders and executable as part of your automated test suite
  • Scenarios are stored in simple text files and grouped by feature. These files are called, logically enough, feature files
  • At the top of a feature file is a section where you can include the description of the corresponding feature
  • The title should describe an activity that a user or stakeholder would like to perform
  • Dan North’s article, “What’s in a story,” for some interesting tips on writing well-pitched stories and scenarios: http://dannorth.net/whats-in-a-story/
  • In JBehave, the Narrative keyword is used to mark the start of an optional, free-form description
  • In Gherkin, you use the Feature keyword to mark the feature’s title. Any text between this title and the first scenario is treated as a feature description
  • The Given step describes the preconditions for your test – be careful to only include the preconditions that are directly related to the scenario
  • The When step describes the principal action or event that you want to do
  • The Then step compares the observed outcome or state of the system with what you expect
  • Both Gerkin and JBehave, any of the previous steps can be extended using and.
  • Good habit to keep “Given … When … Then” clauses concise and focused. If you’re tempted to place two conditions in the same step, consider splitting them
  • In Gherkin, you can insert a comment, or comment out a line, by placing the hash character (#) at the start of a line. In JBehave, a comment line starts with !–
  • Having a lot of similar scenarios to describe a set of related business rules is a poor practice; the duplication makes the scenarios harder to maintain
  • Data from a table is passed into each step via the field names in angle brackets
  • Presenting data in tabular form can make it easier to spot patterns
  • Good scenarios are declarative, not imperative. They describe the requirements in terms of what a feature should do, not how it should do it
  • The Background keyword lets you specify steps that will be run before each scenario in the feature. You can use this to avoid duplicating steps in each scenario, which also helps focus attention on the important bits of each scenario. In JBehave, you can do something similar with the GivenStories keyword
  • In JBehave, feature files conventionally use the .story suffix, whereas the Gherkin-based tools use the .feature suffix
  • The role of a scenario is to illustrate a feature, and you place all the scenarios that describe a particular feature in a single file, usually with a name that summarizes the feature
  • Useful to relate a feature or an individual scenario back to the corresponding issue, both for information and so that reporting tools can use this data to create a link back to the corresponding issue. In JBehave, you can do this using the Meta keyword.
  • Some BDD tools (Cucumber, in particular) also let you write hooks—methods that will be executed before or after a scenario with a specific tag is executed

Automation

  • Tools like JBehave and Cucumber can’t turn a text scenario into an automated test by themselves; they need your help.
  • Step definitions are essentially bits of code that interpret the text in feature files and know what to do for each step
  • The test automation library will read the feature files and figure out what method it should call for each step
  • Step definitions interpret the scenario texts and call the test automation layer to perform the actual tasks
  • The test automation layer interacts with the application under test:
  • If all of the steps succeed, then the scenario will succeed. If one of the steps fails, then the scenario will fail
  • Thucydides (http://thucydides.info) is an open source library that adds better-integrated and more-comprehensive reporting capabilities to conventional BDD tools such as JBehave and Cucumber. The specialty of Thucydides is taking the test results produced by BDD tools like JBehave and turning them into rich, well-integrated living documentation
  • JBehave (http://jbehave.org) is a popular Java-based BDD framework that was originally written by Dan North. In JBehave, you write step definition methods in Java or in other JVM languages such as Groovy or Scala.
  • Easiest way to build and run a JBehave/Thucydides test suite is to use Maven
  • JBehave step definitions are just annotated Java methods that live in ordinary Java classes. JBehave uses an @Given, @When, or @Then annotation
  • Cucumber is a very popular BDD tool from the Ruby world
  • Cucumber-JVM is a more recent Java implementation of Cucumber, which allows you to write step definitions in Java and other JVM languages
  • For pure Python solutions, there are currently three tools available: Lettuce (http://pythonhosted.org/lettuce), Freshen (https://github.com/rlisagor/freshen), and Behave (http://pythonhosted.org/behave). Behave is the most stable, best documented, and most feature-rich of the three.
  • For a .NET environment, your best option for BDD is SpecFlow (http://specflow.org). SpecFlow is an open source Visual Studio extension that provides support for Gherkin scenarios
  • Unit testing is well supported in JavaScript, and low-level BDD unit-testing libraries like Jasmine and Mocha are widely used including Cucumber-JS (https://github.com/cucumber/cucumber-js), which is probably the best known of the JavaScript BDD libraries, and Yadda (https://github.com/acuminous/yadda), an alternative to Cucumber-JS that allows more flexibility in the scenario wording. Cucumber-JS relies on Node.js and npm

Coding

  • Most reliable way to set up your test database is to automatically reinitialize the database schema before each test. The next-best way to prepare test data is to automatically reinitialize the database schema every time you run the test suite. This is faster than reinitializing the database before each scenario, but it means that each scenario is responsible for deleting any test data that it creates, which isn’t without risk
  • most BDD tools provide “hooks” that allow you to perform actions before and after each scenario and at other strategic points in the test suite lifecycle.
  • When you write automated acceptance criteria, using layers can help you isolate the more volatile, low-level implementation details of your tests from the higher level, more stable business rules
  • Gojko Adzik, “How to implement UI testing without shooting yourself in the foot,” http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/
  • The Business Rules layer describes the requirement under test in high-level business terms – scenario in a feature file using either a table or a narrative structure
  • Business Flow layer. This layer represents the user’s journey through the system to achieve a particular business goal
  • The Technical layer represents how the user interacts with the system at a detailed level—how they navigate to the registration page, what they enter when they get there, how you identify these fields on the HTML page, and so forth
  • Page objects—classes that hide the technical details about HTML fields and CSS classes behind descriptively named methods
  • Only need a web test for two things: Illustrating the user’s journey through the system and illustrating how a business rule is represented in the user interface
  • Screenshots from automated web tests can be a valuable aid for testers, and they’re also a great way to provide illustrated documentation describing how the application behaves.
  • Selenium WebDriver provides good support for Page Objects. The Page Objects design pattern can to help make automated web tests more readable and easier to maintain
  • Mobile apps can be tested effectively using Appium (http://appium.io/), a WebDriver-based automation library for mobile apps, and the Page Objects pattern is applicable for any type of GUI.
  • It’s virtually impossible to do good BDD-style acceptance testing with Record-Replay tools
  • HtmlUnit for Java (http://htmlunit.sourceforge.net), Webrat for Ruby (https://github.com/brynary/webrat), and Twill for Python (http://twill.idyll.org) send HTTP queries directly to the server, without having to start up an actual web browser
  • PhantomJS (http://phantomjs.org) provides a more accurate browser simulation, because it renders the HTML like a real browser would, but does so internally
  • HtmlUnit uses the Rhino Java-Script implementation, which isn’t used by a real browser. PhantomJS uses WebKit, which may have different behavior than Firefox or Internet Explorer
  • Several open source libraries for different platforms that can help you build on WebDriver to write web tests more efficiently and more expressively, including Thucydides, Watir, WatiN, and Geb
  • There are many open source and commercial load-testing tools, and most can be scripted. Popular open source options in the Java world include SoapUI (www.soapui.org), JMeter (http://jmeter.apache.org/), and The Grinder (http://grinder.sourceforge.net)
  • number of more BDD-flavored unit-testing tools have emerged over recent years that make these techniques easier and more intuitive to practice. Tools like RSpec, NSpec, Spock, and Jasmine
  • There are two main flavors to fluent assertions. The first typically uses the word “assert,” whereas the second uses terms like “should” or “expect. The first approach comes from a more traditional unit-testing background and focuses on testing and verification. The second is more BDD-centric: the words “should” and “expect” describe what you think the application should do, regardless of what it does currently, or if it even exists

Living Documentation

  • BDD reporting completes the circle that started with the initial conversations with business stakeholders
  • Testers also use the living documentation to complement their own testing activities, to understand how features have been implemented, and to get a better idea of the areas in which they should focus their exploratory testing
  • In BDD terms, a feature can be considered ready (or done) when all of its acceptance criteria pass
  • Cucumber Reports (www.masterthought.net/section/cucumber-reporting) provides more presentable reports
  • Thucydides provides feature-level reports, either directly with JBehave or with test results imported from other tools such as Cucumber, SpecFlow, and Behave
  • Organize living documentation to reflect the requirements hierarchy of the project, organize cross-functional concerns by using tags
  • Some automated acceptance-testing tools such as FitNesse and Concordion (http://concordion.org) give you even more flexibility in how you organize the living documentation. FitNesse (http://fitnesse.org/) uses wiki pages to let the team, including business analysts and even users, write their own acceptance criteria in a tabular format

Continuous *

  • Each executable specification should be self-sufficient. Executable specifications should be stored in version control. You should be able to run the executable specifications from the command line, typically using a build script
  • Executable specifications shouldn’t depend on other specifications to prepare test data or to place the system in a particular state. Each specification should be able to run in isolation, and each specification should set up the test environment in the initial state it require
  • Automated build process needs to be able to run the right set of executable specifications for a given version of the applicatio
  • Automated acceptance criteria should be considered a form of source code and stored in the same source code repository as your application code
  • There are many build-scripting tools, and your choice will typically depend on the nature of your project. In the Java world, you might use Maven, Gradle, or Ant. For a JavaScript-based project, you could use Grunt or Gulp. In .NET, it might be MSBuild or NAnt, and so
  • CI relies heavily on good automated testing: without automated testing, a CI server is little better than an automated compilation checker
  • For teams practicing BDD, a CI server also acts as a platform for automatically building and publishing living documentation
  • the build pipeline is typically made up of a series of quality gateways, which run different sorts of tests and checks
  • This simplest way to publish up-to-date living documentation is to store it directly on the CI build server. Almost all of the BDD tools we’ve discussed in this book produce HTML reports, and most CI servers let you store HTML reports produced as part of a build

Interview and Book Review: BDD In Action

/ Craig Smith / Leave a comment

InfoQ“BDD In Action” is a book that aims to cover the full spectrum of BDD practices from requirements through to the development of production code backed by executable specifications and automated tests.

BDDInActionSource: Interview and Book Review: BDD In Action

Scrum Shortcuts Without Cutting Corners (Book Review & Summary)

/ Craig Smith / 2 Comments

ScrumShortcutsI was priviliged to be an early reviewer for Ilan Goldstein’s book “Scrum Shortcuts Without Cutting Corners” and to also count him as a colleague and a friend. The Agile community in Australia is relatively small, so it is always exciting to see a book come out the community, particularly one that is part of one of the leading Agile Series by Mike Cohn. I was also honoured to be asked to provide a quote for the book. The following is my brief review and notes from the book.

Review

The following is my quote from the front of the book:

“If Scrum and Agile were easy, everybody would be doing it! Now that so many are, this book is the virtual Agile coach I wish I had when I was on the early steps of my Scrum journey. Ilan is a world-class coach, and he has packed this book full of ideas and approaches to all of the common questions and issues that are bound to come up as you transform your world of work to Scrum.”

–Craig Smith, Agile coach and editor at InfoQ

The book is broken into 10 chapters, each with 3 shortcuts each. It is written in a very easy to read and laid back style and feels like you are having a conversation with Ilan. It’s organisation means you can read the book from cover to cover of ad-hoc as a reference. It is clearly written with the Scrum Master / Iteration Manager as the primary audience, although it is suitable for anyone on the Agile team.

The key concept I really liked in the book was the notion of a Chief Scrum Master. As organisations begin to scale, it is a necessary role that is not always taken seriously. The book also covers the notion of One Scrum Master = One Team and deals with the ramifications and alternatives to this setup in a reasonable amount of pragmatic detail.

There were a couple of areas I disagreed with, mainly from an hybrid Agile approach as opposed to Scrum

  • protected sprint – Scrum talks about the idea of a protected sprint so that the team can focus. I can see some merit for new teams, but in this day and age of constant change I much prefer working on the next highest priority and the kanban approach to focussing on one-piece flow
  • sprint lengths – Ilan mentions that “1 week is too short, 4 weeks is too long, leaving me sitting on the fence between 2 and 3 weeks”. I have had a lot of success with 1 week sprints, particularly in business teams. Also, with teams adopting kanban, I have found 1 week sprints a good starting point. I have had some mainframe teams argue that they need 3 week sprints, but I personally find them too long.
  • creating and estimating tasks – Ilan writes “break the PBIs into more granular technical tasks and to estimate each task to the nearest hour”. I find this a complete overkill and much prefer to have nicely sized cards of no more than 3 days. That said. Ilan has some good strategies for splitting stories in the book that I completely agree with.
  • tracking time – further in the book, it is written “before going home each day, everyone on the development team should adjust the remaining time for any tasks they had been working on that day to ensure that up-to-date data is being fed into the sprint burndown chart.” As per the above point, I find this to be in most cases a useless metric, particularly if you cannot get the estimates from everyone in the team. In this age of #noestimates, I personally see this as an administrative overkill.

Overall, this is a book that belongs on any Agile pratitioners bookshelf as a trusted advisor or useful reference. As you become more experienced, this is the book you will definitely hand-on and recommend to your more novice colleagues as they take on the Scrum Master role.

My full book review and interview with Ilan and Colin is available on InfoQ.

Summary

Here are my key notes from the book:

Shortcut 1: Scrum On The Pitch

  • protected sprint allows the developers to completely fix their focus on what they committed to during the sprint planning session
  • the idea of personal achievement is overshadowed by team achievement
  • ScrumMaster protects the team from disruptive outside influences and removes issues that may be impeding development progress.
  • Scrum promotes transparency as a core tenet

Shortcut 2: Fragile Agile

  • Scrum is a framework not a method – Scrum is a framework of practices tied together by a small set of clearly defined rules
  • a requirement should not be considered done unless it has met the quality requirements stipulated in the definition of done
  • sprint zero – artificial term often used to describe the preliminary work that a team might undertake before it is ready to commence an actual sprint. The issue is inappropriate work is bundled into it that delays the starting of real sprints
  • poor ScrumMaster selection – unilateral product or technical decisions, micromanaging task assignments, driving the team to put in regular overtime, or generally acting like a tyrant

Shortcut 3: Creative Comfort

  • important to ensure that everyone is feeling energized and excited about coming to work
  • teams are made up of individuals, and individuals still maintain a sense of self-worth and appreciate having their hard work recognized.
  • when our value feels at risk, as it so often does, that worry becomes preoccupying, which drains and diverts our energy from creating value
  • basics for the environment: plentiful whiteboard and wall space, plenty of light, open desk space for each team, ample chair space, small round discussion table, readily available large meeting rooms, do-not-disturb zones, private areas, buffering from the noisier elements of the organisation
  • developers who are offered their choice of the latest and greatest equipment see it as the most wonderful benefit – keeping developers happy but also improving overall productivity!
  • jelled teams are usually marked by a strong sense of identity . . . team members feel they’re part of something unique. They feel they’re better than the run of the mill.
  • the more passionate people are about their projects, the more likely they are to fully engage in them each day
  • include the developers in some of the early user story workshops so that they not only feel involved in the conception of the product but also get an early idea of what they will be expected to develop and why.
  • a warm greeting in the morning, a sincere pat on the back for a task well done, and the feeling that you are part of a unique team can often be all that is required to maintain smiling faces.

Shortcut 4: Masterful ScrumMaster

  • begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead
  • 7 abilities: leading without authority, bring about change without fear, be diplomatic without being political, behave selflessly without downplaying the role, protect without being overprotective, maintain technical knowledge without being an expert, be comfortable never finishing, next generation leadership
  • ScrumMasters form part of a new generation of enlightened professionals. The role of the ScrumMaster is deep and complex and should never be seen simply as a laundry list of operational functions
  • although not everyone can be a ScrumMaster, a ScrumMaster can be anyone

Shortcut 5: Rock Stars or Studio Musicians

  • we prefer attitude over aptitude
  • teammates are expected to step up to the plate and, if necessary, temporarily help carry any additional load in the same way that a fellow soldier will help stretcher a wounded comrade off the battlefield
  • constant feeling of safety should be generated from the knowledge that teammates will be respectful even if they aren’t particularly enamored with an idea or opinion
  • the effort you’re willing to contribute goes down the more times you hear “You’re wrong!”

Shortcut 6: Picking Your Team Line-Up

  • consider many factors when running your own Scrum “draft pick,” including attitude, compatibility, skill sets, team size, ratio of functional specialties, shared resources, and workplace logistics
  • everyone is a developer – Scrum views all development team members as equals and labels them accordingly with the collective title “developer.” – it is like being a medical specialist; irrespective of specialty, all specialists are still doctors
  • Scrum team size – 5-7
  • development team ratios – 3 programmers : 1 tester : 0.5 “deep specialist(s)”
  • preferable to limit the work in progress and instead encourage as many developers as practicable to focus on completing a smaller number of PBIs
  • in your next sprint planning meeting, agree that one specialist on the team will not work in that specialty for the duration of the sprint. The specialist can advise others who do the specialty work but cannot do the work personally
  • have often found it unnecessary (from a requirement perspective) and unrealistic (from a budgeting perspective) to have deep specialists, such as database administrators, dedicated full time to a development team – treat the as consultants and trainers for the rest of the team
  • one team = one ScrumMaster

Shortcut 7: Setting the Scrum Stage

  • keep the team together for the duration of the project
  • a reasonable assessment of startup cost (for a new team member) is therefore approximately three lost work-months per new hire
  • work conducted in ad hoc space has got more energy and a higher success rate. People suffer less from noise and interruption and frustration
  • sitting together is the most effective way I know to build empathy
  • overtime should be the exception, not the rule – symptom of a serious problem on the project,” not simply business as usual
  • big believer in initially running a pilot project. I recommend this approach even if the business is champing at the bit to roll Scrum out en masse
  • as an industry we have enough evidence that Scrum works; what individual organizations need to learn is how to make Scrum work inside their organizations

Shortcut 8: Plan the Sprint, Sprint the Plan

  • by collectively resetting the goals for the upcoming sprint every few weeks, the team can start afresh rather than remain stuck on a seemingly endless treadmill of ongoing work
  • ensure that the product owner (with relevant assistance) not only has determined the next priority requirements for the upcoming sprint but also has fleshed them out in just enough detail to allow the developers to get started
  • 1 week is too short, 4 weeks is too long, leaving me sitting on the fence between 2 and 3 weeks
  • don’t fall into the trap of believing that those who are dedicated full time to the sprint will be able to spend their entire working day on sprint-related tasks
  • 7 Ps – proper planning and preparation prevents piss-poor performance

Shortcut 9: Incriminating Impediments

  • anything impeding your team’s progress becomes the number-one priority for the ScrumMaster to tackle
  • impediments – meetings of large magnitude, illness, broken builds, issues with the tools of the trade, unreliable supplier, unrefined product backlog, absent or unempowered Product Owner, incentive schemes focussed on the individual
  • impediment ConTROL – Confirm, Triage, Remove, Outline, Learn
  • an obstruction that has stopped progress on a particular task but hasn’t necessarily slowed down overall progress (a block) versus an obstruction that is slowing down the team’s sprint progress (an impediment)
  • you want clear visibility of all blocked tasks, irrespective of how temporary the block may be – spin the corresponding sticky-note 45 degrees

Shortcut 10: Structuring Stories

  • an epic story is a user story that will take more than one or two sprints to develop and test
  • not necessary to have detailed user stories for every requirement only the top-priority items that are going to be worked on in the next one or two sprints
  • key is that stories should be written so that the customer can value them
  • if you can split a story into smaller ones and it is possible to independently prioritize them, it makes sense to treat them as actual stories rather than tasks
  • technical stories are things that need to get done but that are uninteresting to the customer, such as upgrading a database, cleaning out unused code, refactoring a messy design, or catching up on test automation for old features.

Shortcut 11: Developing the Definition of Done

  • DoD becomes the governing agreement that guides all developmental activities, clearly stating what is required for a piece of work to be categorically classified as “done”
  • we should be regularly inspecting and adapting the DoD
  • acceptance criteria or DoD – comes down to whether the requirement is applicable to every user story or to a smaller subset of stories
  • be realistic and get the ball rolling with a minimally acceptable DoD that everyone can live with

Shortcut 12: Progressive Revelations

  • inspect and adapt the user stories under development on a day-to-day basis throughout the sprint
  • typically a hands-on demonstration of the work requiring verification/validation, it usually occurs at the desk of the applicable developer

Shortcut 13: Relating to Estimating

  • estimate to make trade-off decisions and help set goals
  • relative estimation applies the principle that comparing is much quicker and more accurate than deconstructing
  • determine the effort required to complete a PBI using three factors: complexity, repetition, and risk

Shortcut 14: Planning Poker at Pace

  • the issue when using Fibonacci numbers is that people can get into the bad habit of equating 13 points to 13 hours, for example
  • some teams adopt more abstract classifiers, such as T-shirt sizes – requires the extra step of mapping to a numeric value to enable forecasting during release planning
  • ScrumMaster acts as the facilitator throughout and is not involved in the actual estimation
  • Reestimation should be required only when a whole class of PBIs suddenly becomes smaller or larger
  • important to circulate a small number of reference PBIs that correspond to the point levels in the card deck
  • typically advocate removing the big cards (20, 40, 100, infinity) as well as the ½ card from the Planning Poker deck – fewer options equals less analysis paralysis
  • group of PBIs will inevitably rely on some of the same important research or technical plumbing – underlying work should be incorporated into the estimation of only one of the PBIs, not into all of them

Shortcut 15: Transitioning Relatively

  • identify the smallest user story in the product backlog and designate it to be the initial ½-point story – this approach can certainly work, and it seems straightforward on the surface, but the reality is that it can end up taking considerably more time than you might expect
  • map historical work to the new point scale system – identify, sort and stack, sizing up, subclassify, final filter

Shortcut 16: Bah! Scrum Bug!

  • an issue is a problem that occurs during the sprint and is tightly coupled to a user story – not a product backlog item
  • bug is a bug only if it is identified after a user story has been completed and accepted by the product owner – type of product backlog item
  • unless a user story meets the definition of done, it might as well not exist as far as the customer is concerned

Shortcut 17: We Still Love The Testers!

  • loss of identity fear – lose QA identity, lack of skills, won’t get support they need
  • testers think in alternative problem-solving patterns that are, generally speaking, mutually exclusive to the way programmers think
  • pair testing (when a tester pairs up with a programmer) is potentially even more powerful because there is additional scope to encourage functional skills transfer
  • there will always be the need for manual exploratory testing that no level of automation is able to replicate

Shortcut 18: Automation Nation

  • if your programmers are using TDD as a mechanism to write their tests, then they are not only creating a great regression suite, but they are using them to design high-quality, robust code
  • functional testing is also often called acceptance testing. Perhaps one day we will call it user story testing, as the idea is to be able to test and automate the full end-to-end functionality of a particular user story
  • integration testing is all about ensuring that new functionality is able to play nicely with the broader ecosystem and not just in isolation
  • performance testing is to measure the operation of the product when under pressure, typically brought about by increasing the number of users and/or increasing the amount of data processing required
  • recommend running a secondary build in the development environment (traditionally known as the nightly build) that is triggered manually and less frequently. The difference between the CI build and the secondary build is that the latter should be given the luxury of time, and therefore, it can include the full set of tests (including all of the heavier functional and UI tests that take significantly longer to run
  • should configure registry settings, initialize database schemas, set up web servers, launch processes—everything you need to build and test your software from scratch without human intervention
  • while continuous delivery makes every build releasable to users, continuous deployment actually releases every change to users (sometimes multiple times a day)
  • Scrum does not say that you must release at the end of every sprint, but it does say that you should do everything possible to have something releasable at the end of a sprint
  • just start somewhere –  recommend that if you are new to automation, you allocate a percentage of your sprint capacity to chipping away at it

Shortcut 19: Metrics That Matter

  • use them only for good, not for evil
  • good metric – used as a signal to help the team identify roughly where things are at and, more importantly, as a guide to help the team inspect and adapt its processes to improve over time
  • evil metric – used as an inflexible indicator for micromanaging an individual’s performance over time and, more importantly, for beating people up and killing morale
  • meaningful metrics – sprint burndown, enhanced release burndown, sprint intereference, remedial focus

Shortcut 20: Outstanding Stand-Ups

  • GIFTS – good start, improvement, focus, team, status
  • stand-up ambassadors – act as observers in the other groups to pick up on any potential contention and/or lessons
  • if you notice a team member addressing the ScrumMaster without making eye contact with anyone else, a tip is to start slowly turning around or looking up at the ceiling
  • daily scrum is a simple concept, but without care it can quickly turn into a daily mess

Shortcut 21: Taming the Task Board

  • colorful, sticky-note-adorned board has almost become the symbol of Scrum
  • visceral “ceremony” of this movement really appeals to our natural sense of achievement because of the visual recognition of work completed

Shortcut 22: To-Dos for your Sprint Reviews

  • sprint review is rarely simple, and in fact, I consider it to be the most delicate session to facilitate
  • nothing is more embarrassing than so-called technology experts unable to get the projector to work before the session even begins
  • demo of the sprint’s completed work should act as a prompt to encourage a two-way conversation between the business and the Scrum team
  • team should demonstrate only stories that meet the definition of done
  • acknowledge any suggestions made (no matter how outlandish they might sound) by writing them down on the whiteboard or index cards

Shortcut 23: Retrospective Irrespective

  • irony is that this session is most valuable when the pressure is on and/or when things aren’t running as expected
  • without an atmosphere of openness, you will never get to the heart of issues; without courage, the team won’t be willing to confront problems head on; without respect, the team won’t present criticism in a constructive fashion; and without focus and commitment, the team won’t care enough to resolve the issues
  • recommend a relaxed setting such as a coffee shop, a break room (if you have one), or even the kitchen area
  • focus areas – communication, processes, scope, quality, environment, skills
  • ensure that all improvement suggestions are documented, but aim to tackle no more than a few issues
  • circles technique employs an affinity mapping variation, bubbles technique requires each person to document on paper the three most urgent issues that he or she feels should be focused on pair and keep bubbling up the top 3 issues

Shortcut 24: Risk Takers and Mistake Makers

  • to successfully implement Scrum, we must overcome a range of fears
  • spend your time and effort helping those who are already enthusiastic
  • the few bad eggs are often the ones who are most afraid of exposure
  • Scrum turns software development into an open book where mistakes are clearly visible
  • when openly discussing mistakes and vulnerabilities is the forging of closer bonds between team members

Shoprtcut 25: Perception is Reality

  • you have a role as the ScrumMaster to keep the sponsor from blowing a gasket
  • reinforce the positive changes that are occurring while also gauging the sponsor’s current perception of how the project is going
  • sponsors become less upset when confronted with problems if they are involved in the resolution
  • take the sponsor on a “Tour of the Task Boards” now and again
  • never say no is a lesson that I have learned over time

Shortcut 26: Our Lords and Masters

  • Chief ScrumMaster – facilitator of the ScrumMaster Community of Practice – training and coaching, challenge existing behaviours, provide and maintain tools, define and refine metrics, help establish communities of practice, ensure consistency, coordinate teams, ongoing Scrum promotion, developing the approach, company-level education, aligning the teams DoD, continual process improvement via Collective Retrospectives, impediment escalation, HR for the ScrumMasters, creating a physical environment conducive to Scrum
  • ScrumMaster – process improvement, impediment management, diplomacy, coaching, managing change, maintaining the DoD, maintainin effective communication, updating artifacts, faciliating workshops, faciliating Scrum activities

Shortcut 27: Morphing Managers in the Matrix

  • requires visionary leadership that is genuinely interested in encouraging continuous improvement as opposed to playing politics
  • intra-organizational coordination, logistical planning, scheduling, and tracking are massive roles and ones that are nicely suited to the traditional project manager
  • the manager in Scrum is less of a ‘nanny’ to the Team and more of a mentor or ‘guru,’ helping them learn, grow and perform

Shortcut 28: Scrum Rollout Reckoning

  • you are either doing Scrum or not – it is binary
  • Scrum is not a mechanical process… it is so reliant on people and culture that even with fantastic quantitative results, the introduction of Scrum may have caused such upheaval that too many people are unhappy and that is not good for Scrum’s long-term survival
  • Benefield and Deemer used a simple survey based on the following six criteria: How much the team got done in 30 days; Clarity of goals—what the team was supposed to deliver; Collaboration and cooperation within the team; Business value of what the team produced in 30 days; Amount of time wasted, work thrown out, cycles misused; Overall quality and “rightness” of what the team produced
  • Comparative Agility – teamwork, requirements, planning, technical practices, quality, culture, knowledge creation
  • 3 questions – are your clients happier, are your team members happier, are your stakeholders happier

Shortcut 29: Eyes on the Prize

  • development team has no top-down command-and-control authority that tells the team how to do its work. Instead, a cross-functionally diverse team of people organize themselves in the most appropriate way to get work done
  • self-organization needs to be grown and nurtured in a particular environment with distinct boundaries, or it risks spreading wildly out of control
  • ScrumMaster should assist management in the selection of team members to ensure that the team has the natural predisposition to self-organize and work together as one
  • ScrumMasters should not become obsolete – impediments are never predictable, perfection is impossible

Shortcut 30: Shortcut to the Final Level

  • if you remain disciplined, follow the Scrum rules, and adhere to the key practices, then, at the very worst, Scrum will act like a mirror, helping you to uncover the dysfunctions that caused the project to fizzle
  • three words to remember from the book: transparency, inspection, adaption
  • A Scrum adoption should be seen as a big collection of small experiments, wrapped up in a big experiment
  • convince every single person in your organization that “agility needs to be seen as a business strategy and not just something the IT guys do

Enterprise Software Delivery (Book Review & Summary)

/ Craig Smith / 2 Comments

Enterprise Software DeliveryI recently completed reading Enterprise Software Delivery by Alan W. Brown. I read and reviewed the book for InfoQ and the following is my brief review and key notes from the book.

Review

This is a book that sums up any large organisation with a software delivery function. It certainly matches the experiences in my last company but also matches the many case studies I have heard from my colleagues over the years.

It starts by defining enterprise software delivery, noting it uses the word delivery and not development. This is on purpose as software development is only useful when in the hands of the end-user.

The key focus areas are:

  • software supply chain and factories – a large portion of the book points to understanding the entire delivery process and understanding how to deal with distributed teams (whether they be within the organisation or partnered or near or offshore)
  • collaboration – the importance of collaboration and the use of collaborative delivery environments (CDE) and collaborative application lifecycle management (CALM)
  • agile – the importance of agile and approaches to rolling out and scaling in the enterprise
  • quality – the importance of building quality in as well as quality of the team and its relationships
  • governance – measuring your delivery and managing your team and partnerships effectively
  • future – trends that are starting to effect enterprise software delivery including cloud, multisourcing, crowdsourcing and mobile

The Agile portion of the book had me either in agreement or in a couple of cases opposition. I could understand the viewpoint of the author — for example the use of software testing factories which I think removes a lot of the collaboration that is possible with Agile testing techniques and tooling. The author is the CTO for IBM Rational in Europe and as a result a lot of IBM thinking comes through in the ideas. Whilst this is not a bad thing, it is useful to remember that the IBM approach is not the only approach.

The book has lots of case study material (mostly revolving around the financial industry and Danske Bank as well as IBM itself). There are a number of figures and illustrations throughout that demonstrate the points that the author is trying to make (like examples of metrics, processes and plans) and and these alone make the book a valuable asset for those times when you are looking for an example to get started.

This is a book that all technical leaders (including developers, architects and CIOs) should read if they are involved in software delivery in a large organisation. This was a book that I admit I struggled with a little as I read it, which I think was because I had spent so much time in a large organisation that had a continuous focus on governance, sourcing and agile. But on reflection, there were lots of ideas and trigger points throughout the book that are calls to action. Of course, for those just venturing into this domain, it is a recommended read.

Overall, this was a worthwhile read and a book that I would summarise as being very good for lots of ideas rather than a playbook that you follow from beginning to end.

Summary

Here are my key notes from the book:

  • agile “steering” leadership style – frequent course corrections based on testing, measurement, and trends in defects and cost-of-change
  • economic pressures have focused attention in enterprise software delivery organisations on cost-cutting activities, severely stretching existing delivery practices
  • CRASH Report – examined 288 deployed enterprise applications from 75 organizations (with more than 108 million lines of code) and found structural errors that on average would require an investment of more than $1 million per application to fix
  • must learn how to balance the relationship between necessary investments in enterprise software delivery and the business value these investments bring to the organisation
  • inefficiencies and misunderstandings are a major source of errors, frustration, and waste. Clear approaches to communication and coordination greatly improve the team’s performance
  • early and continuous attention to quality is essential
  • adoption of an industrialised approach places the focus on cost efficiency, reuse, and standardisation in enterprise software delivery
  • best-in-class product and services companies are those that have built a strong competency in enterprise software delivery—approaching this as a core business process. Their attention is placed on enabling innovation, lowering costs, and managing change
  • Application assembly optimization (AAO) – consist of centres of competency, technology assembly centres, collaboration and measurements and lean processes – uses work packets to deliver work (self-contained unit of work, the receiver designs, plans, and executes the work requested and measured in real-time)
  • software testing factories – particularly effective in organisations that are more complex, with numerous departments, vendors, and locations – cost-efficient and effective testing on-demand, standardised business-driven test processes, centralises test equipment, common approach to metrics and measures, centralisation of test service requests
  • important insights for an industrialised view of enterprise software delivery – new ideas needed around monitoring progress and managing status, focus measurement on broader SLA’s across vendors, transparency across the chain is critical,  choose different partners for specialist tasks and to reduce risk and increase flexibility and competition
  • an extreme version of multisourcing is the use of crowd sourcing for component delivery
  • collaboration is king – trends –  globalisation, outsourcing, faster time to market, agile, end user demands
  • organisational arrangements for collaboration – internal partnerships (many companies operate software development as a separate legal entity), supplier partnerships (strategic alignment between both parties), outsourced partnerships (formal SLA between parties)
  • global approach – reduce labour costs, skills in short demand, gain access to emerging markets
  • points of friction – “energy is lost in their execution which could otherwise be directed to more creative activities that contribute directly to the completion of the project’s mission”
  • time starvation – “typically never enough time to complete everything on an individual’s to-do list”
  • collaborative application life-cycle management (CALM) focuses on the synchronization of the entire team and the hand offs that occur across domains
  • balance delivery capabilities – time to market, productivity, process maturity and quality
  • the approach to agility – “an iterative and incremental approach performed in a highly collaborative and self-organizing manner with just the right amount of ceremony to frequently produce high quality software”
  • investment should be placed in techniques that support and encourage software to evolve – critical phase comes after first release
  • evolutionary view  – distinction between these two activities is blurred to the point that development and maintenance are just two aspects of the same need to create and deliver the system
  • agility possible when: high-bandwidth communication and coordination, decisions based on real-time information, continuous measurement and transparency into individual, team, and project progress
  • impacts on the scaling of agile – geographical distribution, compliance requirements, technical complexity, team size, enterprise discipline, organisation distribution, organisational complexity, domain complexity
  • “My experience with several large enterprise software delivery organizations suggests that agile approaches can be successful in almost every kind of development team and in almost all organizations”
  • Agile observations: 1) roles most challenged by agile approaches are Executive Managers, Product Managers, and Project Managers; 2) plan at multiple levels and adopt a “measure and steer” approach; 3) don’t use agile methods for everything, match to optimize success; 4) adapt and harden the agile process as the project gets closer to delivery
  • National Institute of Standards and Technology (NIST) – 80% of development costs are spent on identifying and correcting defects
  • almost two thirds of errors are a result of requirements and design problems, misunderstandings, and omissions, while more than 80% of error discovery occurs in acceptance testing or once the software is placed into production
  • improving quality – automating repetitive tasks, discovering more defects earlier in the life cycle, closer alignment between roles, lowering risk
  • “the quality of the enterprise software is a direct reflection of the organization’s activities, practices, skills, and morale”
  • “the evolution of the role of the software testing factory is toward a utility view of testing as a service that can be readily acquired on a pay-per-usage model or a results-based scheme” – performance and load testing, security testing, compliance testing
  • important aspects of governance – establishing chains of responsibility, authority, and communication and establishing measurement, policies, standards, and control mechanisms to enable people to carry out their roles and responsibilities
  • challenge lies in knowing which metrics are more meaningful in a specific context and how to use those metrics to change the way an organization performs it tasks – one cannot control what one cannot measure
  • a well-chosen set of metrics clarifies the goals of the organization
  • measure what you can, what you value, what drives behaviour and what optimises results
  • decisions that may be considered optimal in one area of the business (e.g., software testing) may introduce challenges in other areas (e.g., deployment management).
  • Walker Royce – analogy between enterprise software delivery and movie making – early stages of the process involve significant “scrap and rework” as part of the creative process and later in the process there must be a great deal of focus on reducing rework to eliminate inefficiencies
  • Royce’s ten management principles for agile software delivery
  • through-life capability management (TLCM) – evolutionary acquisition – each increment provides useful and supportable operational capabilities that can be developed, produced, deployed, and sustained. Major enhancements and preplanned product improvements are managed as separate increments.
  • supply chain operations reference model (SCOR) – ensure that the supply chain is operating as efficiently as possible and generating the highest level of customer satisfaction at the lowest cost
  • lean is a philosophy that seeks to eliminate waste in all aspects of a company’s production activities: human relations, vendor relations, technology, and the management of materials and inventory
  • Bell’s Law – a new platform emerges about every ten years to offer improved functionality in new areas, accompanied by lower prices for existing capabilities compared to those of the incumbent platform
  • cloud-based services are usually viewed as operational expenses because they are “leased” for the time they are needed – the switch from capital to operational expense can be very attractive from an accounting perspective
  • “you ship your organization”—the way you organize individuals and teams will undoubtedly have significant impact on the structure and effectiveness of the system delivered

Specification By Example (Book Review & Summary)

/ Craig Smith / 1 Comment

I was lucky enough to be a reviewer on Specification By Example by Gojko Adzic, and the final version was recently released to print by Manning. And I was stoked to see not only my name in the acknowledgements, but that my quote made it to the cover of the book. The following is my brief review and notes from the book.

Review

“I love this book. This is testing done right.” That is my quote on the back cover of the book, and I meant every word of it. Having been a quality advocate in the agile space for a few years now, this is the first book I have read in a long time which had me nodding my head all of the way through, as it resonated with my ideas on how development teams need to reconsider specifications and testing.

The book starts out by summarising why specification by example is so important and outlines some key patterns for success and then, through examples throughout the book, steps through the patterns pointing out the warning signs along the way. The key steps are to ensure the culture is fit, then approach specification in a collaborative manner, use examples and automate and finally evolving a living document / specification.

I really appreciated the fact that the examples were not just the run of the mill greenfield Java web applications that are used in most books. There is a good sampling of different organisations, most of which are using this technique on existing legacy applications on a variety of different platforms. The book is an easy read for the entire team, which means it can (and should) be required reading for the developer, tester, analyst and project manager. I have encouraged many of my teams to take a look at the book, and a couple of my colleagues have indicated this book helped convince and reinforce why this approach is so valuable.

My only concern when reviewing was the fact that the title of this book may not standout to testers and developers (not perhaps as much as Acceptance Test Driven Development or ATDD might). Currently the community has a number of similar approaches with similar names, although I must acknowledge that the specification by example tag has grown on me over the last few months.

The book does not expend much effort talking about tools in this space, by design, I think this fact makes the book more readable and accessible to a wider audience, but that said it suggests to me that there is still a gap for a good text that matches specification by example to particular tools like Concordion, Fitnesse and the like.

Overall, this book is a definite must read for any teams (particularly agile teams) who are trying to balance or find a decent approach to specifications and testing. It is a good balance of patterns and real case studies on how testing and specifications should be approached in an agile world. It would make my list of Top 5 must read testing books and Top 10 must read agile books. And now I know what the proper name is for the cats eyes that are embedded in the freeway!

Finally, I had some other suggestions for summaries for the book that did not make it to cover, but they are just as relevant of my feelings about the book:

  • “One of the best Agile related books I have ever read. Buy it, read it, recommend it to your colleagues.”
  • “This book sums up the right way to attack requirements and testing while delivering to your customer. A must read for all agile teams.”
  • “I loved this book. I could not stop raving about it to my colleagues. It’s testing done right”

Summary

Here are my key notes from the book:

  • a people problem, not a technical one
  • building the product right and building the right product are two very different things, we need both to be successful
  • living documents – fundamental – a source of information about system functionality that is as reliable as the programming language code but much easier to access and understand
  • allows easier management of product backlogs
  • proceed with specifications only when the team is ready to start implementing an item eg. at the start of an iteration
  • derive scope from goals – business communicate the intent and team suggest a solution
  • verbose descriptions over-constrain the system – how something should be done rather than just what is to be done
  • traditional validation – we risk introducing problems if things get lost in translation between the business specification and technical automation
  • an automated specification with examples, still in a human readable form and easily accessible to all team members, becomes an executable specification
  • tests are specifications, specifications are tests
  • consider living documentation as a separate product with different customers and stakeholders
  • may find that Specification By Example means that UAT is no longer needed
  • changing the process – push Specification By Example as part of a culture change, focus on improving quality, start with functional test automation, introduce a new tool, use TDD as a stepping stone
  • changing the culture – avoid agile terminology, management support, Specification By Example a better way to do UAT, don’t make automation the end goal, don’t focus on a tool, leave one person behind to migrate legacy scripts (batman), track who is/isn’t running automated tests, hire someone who has done it before, bring in a consultant, introduce training
  • dealing with signoff and tracebility – keep specifications in a version control system, get signoff of living documentation, get signoff on scope not specifications, get signoff on slimmed down use cases, introduce use case realisations
  • warning signs – watch out for tests that change frequently, boomerangs, test slippage, just in case code and shotgun surgery
  • F16 – asked to be built for speed but real problem was to escape enemy combat – still very successful 30+ years later
  • scope implies solutions – work out the goals and collaborately work out the scope to meet goals
  • people tell you what they think they need, and by asking them ‘why’ you can identify new implicit goals they have
  • understanding why something is needed, and who needs it, is crucial to evaluating a suggested solution.
  • discuss, prioritise and estimate at goals level for better understanding and reduced effort
  • outside-in design – start with the outputs of the system and investigate why they are needed and how the software can provide them (comes from BDD)
  • one approach is to get developers to write the “I want” part of the storycard
  • when you don’t have control of scope – ask how something is useful, ask for an alternative solution, don’t only look at lowest level, deliver complete features
  • collaboration is valuable – big all team workshops, smaller workshops (three amigos), developers and analysts pairing on tests, developers review tests, informal conversations
  • business analysts are part of the delivery team, not customer representatives
  • right level of detail is picking up a card and saying ‘I’m not quite sure’, it pushes you to have a conversation
  • collaboration – hold introductory meetings, involve stakeholders, work ahead to prepare, developers and testers review stories, prepare only basic examples, overprescribing hinders discussion
  • one of the best ways to check if the requirements are complete is to try to design black-box test cases against them. If we don’t have enough information to design good test cases, we definitely don’t have enough information to build the system.
  • feature examples should be precise (no yes/no answers, use concrete examples), realistic (use real data, get realistic examples from customers), complete (experiment with data combinations, check for alternate ways to test) and easy to understand (don’t explore every combination, look for implied concepts)
  • whenever you see too many examples or very complicated examples in a specification, try to raise the level of abstraction for those descriptions
  • illustrate non-functional requirements – get precice performance requirements, use low-fi prototypes for UI, use the QUPER model, use a checklist for discussions, build a reference example for things that are hard to quantify (such as fun) to compare against
  • good specifications – should be precise and testable, not written as a script, not written as a flow
  • watch out for descriptions of how the system should work, think about what the system should do
  • specifications should not be about software design – not tightly coupled with code, work around technical difficulties, trapped in user interface details
  • specifications should be self explanatory – descriptive title and short paragraph of the goal, understood by others, not over-specified, start basic and then expanded
  • specifications should be focussed – use given-when-then, don’t explicitly detail all the dependencies, put defaults at the technical layer but don’t rely on them
  • define and use an ubiquitous language
  • starting with automation – try a small sample project, plan upfront, don’t postpone or delegate, avoid automating existing manual scripts, gain trust with UI tests
  • managing test automation – don’t treat as second-grade code, describe validation. don’t replicate business logic, automate along system boundaries, don’t check business logic through the UI
  • automating user interfaces – specify interaction at a higher level (logging rather than filling out the login page), check UI functionality with UI specifications, avoid record and playback, setup context in a database
  • test data management – avoid using pre-populated data, use pre-populated reference data, pull prototypes from the database,
  • Bott’s Dott’s are the lane markers on the roads that alert you when you move out of your lane, continuous integration has that function in software, run it with Specification By Example and you have continuous validation
  • reducing unreliability – find most annoying thing and fix it, identify unstable tests, setup dedicated validation environment, automated deployment, test doubles for external systems, multi-stage validation, execute tests in transactions, run quick checks for reference data, wait for events not elapsed time, make asynchronous processing optional, don’t use specification as an end to end validation
  • faster feedback – introduce business time, break long tests into smaller modules, avoid in-memory databases for testing, separate quick and slow tests, keep overnight tests stable, create a current iteration pack, parallelise test runs
  • managing failing tests – sometimes you can’t fix tests – create a known regression failures pack, automatically check disabled tests
  • easy to understand documentation – avoid long specifications, avoid lots of small specifications for a single feature, look for higher level concepts, avoid technical automation concepts
  • consistent documentation – evolve an ubiquitous language, use personas, collaborate on defining language, document building blocks
  • organize for easy access – by stories, functional areas, UI navigation routes, business processes, use tags instead of URLs

Tribes (Book Review & Summary)

/ Craig Smith / 1 Comment

After on and off reading of this book for about six months, I finally got around to finishing Tribes by Seth Godin. The book was a gift from my CIO for my involvement in a collaboration initiative at work. The following is my brief review and notes from the book.

Review

The tag line for the book is “we need you to lead us”, and this essentially is the theme of the book. The book reinforces the idea that in this internet age, anybody can (and should) be a leader and anybody can make a living doing things that they love. Furthermore, it highlights that challenging the status quo is okay and that the traditional factory management approaches are dead. It is an easy read and uses a number of examples throughout the book to reinforce the ideas being presented. For the most part, it was common sense to me, but it served as an encouragement and reinforcement to the ideas that I already believe in. This book is best passed on to colleagues who need that push over the edge to challenging the norms in the workplace.

Overall it was an easy, entertaining read and I recommend it to anyone who needs reinforcement or encouragement to lead change.

Summary

Here are my key notes from the book:

  • a tribe is a shared interest and way to communicate
  • everyone is a leader
  • move from being stuck embracing a factory instead of a tribe and acting like managers and employees and not leaders
  • heretics are the new leaders, challenging the status quo
  • leaders have followers, managers have employees
  • leading from the bottom (with a newsletter) – the story of how Seth in the mid-1980’s took a small team with a difficult challenge, and how twice a week he sent a newsletter to all of the employees in the company detailing the team and their good work. Over time a number of people transferred or moonlighted on the project to be be part of the journey, and years later people still talk about the project. The moral of the story is leading, not managing.
  • factories are efficient and stable, but nobody in factories make a difference. Over time, factories have become less stable, nor are they the illusion of a dream job.
  • beware of the unicorn in the balloon factory
  • a remarkable product or service is like a purple cow (brown cows are boring, purple cows are worth mentioning). Why is your team not producing more purple cows?
  • good leaders back off and lead the tribe. This is different to doing nothing. Leadership is a choice to not do anything. Lean in, back off, but don’t do nothing.
  • change needs belief. Change is not made by asking permission, it is made by asking forgiveness later.
  • sheepwalking – hiring obedient people for brain-dead jobs and raising fear to keep them in line. Rather, hire amazing people and give them freedom to do amazing stuff.
  • thermometers reveal something is broken, thermostats are indicators to keep us in sync with the outside world. Thermometers are more valuable than thermostats and very organisation needs at least one.
  • creating a micromovement: 1) publish a manifesto; 2) make it easy for followers to connect with you; 3) make it easy for followers to connect with another; 4) money is not the point; and 5) track progress. The principles are: 1) transparency; 2) movement is bigger than you; 3) grow to thrive; 4) compare to status quo or push in a different direction; 5) exclude outsiders; and 6) build followers up rather than tear others down
  • be willing to be wrong rather than avoiding being wrong, the secret of leadership is to do what you believe in, paint a picture of the future and go there
  • “no” is not the enemy, it is “not yet”, because “not yet” is safe, Change never fails because it is early, it almost always fails because it is too late
  • Reagans secret – listen, value what you hear, and make a decision even if it contradicts the people you are listening to. People want to know they have been heard
  • The Simpsons Movie – Matt Groening resisted product placement, which delayed the project but would have ruined it. Compromise can expedite, but can also ruin.