Skip to content


An Ordered Collection of Agile and Lean Practices

In an effort to organize all the practices involved with effective, creative organizations, I’ve created a mind map to share with you. The next step would be to show typical learning or deployment paths for these practices. Another addition would be to link them to principles and values. Those will be forthcoming. In the interest of getting early feedback, here it is.

-Dennis

Posted in Uncategorized.


A First Order Acceptance Test Automation Stack

Acceptance testing, in some cases known as BDD, has moved to its rightful place at the forefront of software development alongside user stories. Here’s an approach to understanding the full deal involved with modern acceptance test automation.

User Stories are the Foundation of Automated Acceptance Testing

Agile Stories come in a variety of shapes and sizes. There are very specific ones that cover fundamental aspects of an experience and others that cover a collection of behaviors. The following larger sized story, sometimes called an ‘epic’, might be created after many aspects of the service have been created. Typically a series of smaller stories collectively represent the intent of an epic story. The nice part about automated acceptance testing vs. unit testing is that you can test at the highest level of end to end functionality as well as very specific aspects of interaction.

 Here’s the simple template often used to ensure a complete and testable story:

As an <type of user or persona> I want <what you want to happen> So that <underlying reasoning>

Here’s a larger test related to resupply:

Keep Flavor in Stock:

AS AN ice cream vendor, I WANT to proactively resupply my customers’ favorite flavors  SO THAT I can ensure I don’t run out or exceed my storage capacity.

Proper agile user stories must include acceptance criteria which require automatic validation to keep pace with agile development. Without these criteria a user story cannot be mutually understood nor automated. Before adding criteria you could call them sketches or just backlog items. I recommend between 2 and 5 acceptance criteria to right-size the story. Too many and it can get confusing to understand and test as well as take the lion’s share of the sprint to build and test. Too few and it could be poorly defined, too specific or incompletely specified.

Here’s the simple template often used to ensure a complete ‘test’ criteria:

Given <context or current status> AND <more context> WHEN  <triggering action> AND <further action> THEN <Expected Result>

Criteria 1:

Given Remaining storage capacity of 20 barrels of ice cream

AND we’re averaging at least 5 customers/hour ordering Rocky Road

AND delivery time of 2 days,

When Rocky Road gets down to 2 barrels

Then System orders 5 more barrels of Rocky Road.

Criteria 2:

Given remaining storage capacity of 10 barrels of ice cream

AND delivery time of 5 days,

AND we’re averaging at least 2 customers/hour ordering Rocky Road

When Rocky Road is down to 1 barrels

Then System orders 2 more barrels of Rocky Road.

Tables can be a convenient format for exercising the variety of values matching your criteria:

Remaining Storage

Remaining Barrels

Delivery Time

Customers/Hr

Barrels  Ordered

30

2

2

5

5

30

5

1

2

2

10

1

7

2

5

What better way to provide story validation then to connect them with a suite of acceptance tests which automatically validate their criteria signaling their readiness or ‘doneness’. In order to be able to be implemented, they must be written with clear intent, a clear understanding of which specific part of the system they are testing and possess clear pass/fail criteria.  Test automation is more than just a collection of test scripts tied to a test runner, but an interoperating system of components.

Eight Aspects of an Acceptance Test Automation Stack:

  1.  Expressions of Intent. A Feature or Story containing acceptance criteria can be stored in documents on desktop or cloud, wikis, code or document repositories. These are what the acceptance tests validate. They need to connect in a way that can drive executable tests.  A variety of tools help make this happen: Pivotal Tracker, Jira, Confluence, any wiki, repository-based text/html files and google docs.
  2.  Guiding Templates for semi-formal language.  These are helpful for structuring acceptance criteria and test descriptions in a way which connects to the code that executes the intended tests. Cucumber has a bridge language cleverly called ‘Gherkin’ for this purpose. FIT and Fitnesse use ‘Fixtures’. Thoughtwork’s Twist has a GUI template to guide the author into the right language. Jira Behave Plugin does this too. Most popular is the Given <context>, When <action/event> Then < expected result> format. The expected context and result can be data sets represented directly using tables in many tools. Concordion is alone in allowing free form English by hiding the ‘instrumentation’ in html tags.
  3.  Organizing.  Categories/tags/relationships can help create order out of the multitude. Almost any ticketing app like Jira, Pivotal Tracker or Wiki like Confluence or Mediawiki allows you to tag items.
  4.  Choosing. Build suites for versioning and pacing. Decide which tests to run, when.
  5.  Managing Data. Seed test data and application state. Most tools have ‘setup’ routines embedded in each test.
  6.  Driving the Tests. Executes the test logic and drives the software. There is a lot of diversity in this part of the stack. Fundamentally there are these ways:
    • To Code  eg. (xUnit, FIT, and Fitnesse which comes with a wiki to present and edit test descriptions)
    • To Data  eg. JDBC protocol or JSON calls to validate data
    • To Network Protocols eg. REST or SOAP calls
    • To Simulated Browsers
    • To Actual Browser API eg. Selenium (common GUI browser driver)
    • To Desktop GUI eg. HP QuickTest/WinRunner)
    • To Mobile API eg. Calabash (Mobile driver)
  7.  Triggering or Scheduling Tests and Signaling Pass or Fail eg. build managers like (Jenkins) and IDE’s like (Eclipse)
  8. Gathering and Reporting Results to a text file, html, via an api or data file.
    1. Note: It is important that the test tool helps you understand how the failures relate to what’s wrong with the system efficiently or else testing will become a bottleneck or worse: the results will get ignored.

Ten Things To Look (Out) For:

  1. Requirements ‘Traceability’. or more accurately something to link the test to the intent of the product owner usually represented by a story. Concordion, Twist, Behave and Cucumber are principal examples here.
  2. Task and issue trackers. They have a fundamentally different purpose than repeatedly running tests. If an issue is closed, its tests should still run (regression), conversely, tests run multiple times should not change the status of the user story unless you want it to.
  3. Business Clarity of Intent:  Tests should be readable by product people and customers. An approachable and flexible syntax or tabular structure for handling input and expected data sets is important here to keep the business/domain experts from having to dive into code just to communicate their expectations or the inverse: Programmers having to slog through thick specifications or mysterious datasets in order to import them into the test code.
  4. Usability for business product people. In other words having to use a developer IDE to check-in documents is not an option unless every product manager is willing to do this on a daily basis
  5. Continuous Integration (CI): Provides for the tightest feedback loop possible on the completeness of your software extracting the most utility out of your test suite.
  6. Suites: Collecting and finding just the right combination of tests requires a good organizer
  7. Versioning: Often overlooked until too late, you want to track and run tests that match the version of software they are built for or else you will get false failures or false positives
  8. Segmenting: Separate quick tests from slow tests to get the fastest turnaround time. Work diligently to turn your slow tests into fast tests. You may need to change technology or architecture to do this which is a good thing
  9. Themes: Create suites to focus on a particular problem area
  10. Refactoring: This test automation stuff is real software and can get unwieldy real fast. Practice safe coding with TDD and refactoring

Further Reading

Dale Emory’s excellent article on Maintainable Tests.

A nice list of Javascript test tools and Web testing tools.

For really practical hands on instruction you can’t beat Gojko Adzic’s  Specification By Example with some great instructional video.

Lean Startup Hypotheses for challenging the assumptions about the problems you think you may have: Interview with Josh Seidan and an article by Barry O’reilly

Posted in Quality.


Cross Post: Bending Jira to your Agile Will

http://www.tribalmashups.com/agilejiratips/

Posted in Uncategorized.


Tribal Mashup Meetup at Silicon Valley Agile Leadership Network

My colleague Linda Francis and I have created an event with The Silicon Valley Agile Leadership Network in concert with Ux Eye for the Developer Guy. We are assembling a moderated panel of respected leaders of “tribes” who are involved in manifesting valuable products and building successful, conscious organizations .

We will be breaking new ground in learning how to work more effectively across disciplines and silos in the enterprise. We will be applying lean startup and User Experience principles to the business itself! Catch this unique meetup coming Tuesday, September 11th, 2012. For more events like this check out  tribalmashups.com

Posted in Uncategorized.

Tagged with , , , .


Agile in the Big Wide World: Part 1 – Bringing People Together with Robots

Small operations rarely need much guidance for the basics. A business like an espresso cart gets such immediate feedback from their environment, from their customers and location they can connect fluctuations in supply, demand, and customer happiness nearly instantaneously because it is right in front of them. They see the delighted (or not) expressions on their customer’s faces as they drink the coffee. They notice when another vendor opens up nearby and draws customers away. Their customers talk to them directly about their degree of satisfaction. The first time  they run out of sugar or cream and they hear the complaints they know they need to ensure that never happens again,and the fix is simple: a trip to Costco.

Larger operations typically exist in a massively mediated milieu. Customers are rarely seen and served at headquarters where many decisions are made. Workers are strewn across the globe in various time zones, most never having met each other.

What can we do to retain the immediacy of a small operation yet obtain the power to serve on a larger scale?

As companies scale there are demands for more and diverse talent to address more diverse needs. Drawing talent from a larger pool helps, but introduces a new problem of collaboration over distance. Several solutions are typically tried:

  1. Create Satellite offices or branches
  2. Establish Audio and Videoconferencing in meeting rooms to extend to those offsite
  3. Bring people in to meet and work at headquarters or a conference facility

These all can help, but have their limitations. Satellite offices typically do not contain a fully independent work group, requiring tedious teleconference meetings to stay in sync. Bringing people in disrupts their local lives, burns a lot of fuel and expense, and  is exhausting to most so that when they arrive they are not at their best.

How many of you have watched expensive video conferencing facilities gather dust in the corner of a conference room? Why is this? I think it is because the work does not get done by sitting in a conference room for an appointed time. It is done throughout the day, in front of a large chart or visual project tracker, by a couple folks at someone’s workstation, in a discussion while getting coffee with workmates. That is where the meeting of minds occurs, through courageous personal discussion and casual osmotic communication.

How to make this happen in a distributed situation?

One unexpected solution I’ve come across is a tele-presence robot from AnyBot a Silicon Valley startup. It can exist with the team, go where the team members go, see and hear what they see all while conveying its perspective to an operator who could be clear across the globe or down the street, at home with a twisted ankle. I’ve tried this out and am amazed at the feeling of being there that this conveys. An operator can use a web browser to log in to the robot, see and hear from the robots location, drive it around, speak through it, display their live video feed, and point at things using a green laser. People seem to accept it readily after the ‘Gee Whiz’ factor wears off.

I can see using this when working with clients who are across the country from each other.  After establishing a strong foundation in person for several days, I could leave behind my trusty Anybot and either go to the next client or return home, attending to the team during certain time slots without requiring them to stop what they are doing to file into a conference room. They would be able to ‘show me around’ to the various workgroups, workspaces and visual management tools just as if I were there. What a great way of being in two or more places at nearly the same time! I’ll have an opportunity to trial this soon and will update you on how that works out.

What do you think? Would this solve any distributed team challenges for you? Would you use it for telecommuting? Serving customers better? What would the pitfalls be for you?

In the next installment of this series I will be talking about the structure of organizations for optimum sustainability in Chaordic times, involving attributes such as robustness, agility and variation.

Posted in Scaling.


New agile game just posted to AgileGames2011: ‘Fair Tradeoffs’

Agile Games are coming to Boston this spring!

Want to learn how to get your team to make safe and sane tradeoffs between business priority and team estimation effort?

Check out my ‘Fair Tradeoffs’ game!

I’d love to get your feedback on this agile game proposal for  AgileGames2011

You can get more details and give feedback on my game at http://uservoice.com/a/1M5xu

Twitter feed is #AgileGames2011

Posted in Insights, Techniques.


Accelerate Sprint Planning and Estimation

One of the most challenging points in sprint planning is gauging what is worth tackling for the next sprint. Product owners cheerfully come up with ordered lists of their favorite user stories, but typically falter when it comes time to make hard choices of what they want ready at the end of the upcoming sprint.

What if a story is large but very desirable? Do you trade it for 4 smaller, but lower priority stories just to get more features done? What if there are many small stories and 1 large one, but the large one is lower priority? Do you squeeze it in by dropping a small story or split it so the higher priority smaller stories can be delivered? Since stories are not immutable and can be split, opportunities for many tradeoffs exist. But how to manage them? How to visualize those tradeoffs?

Inspired by Steve Bockman’s Team Estimation Game, I added another dimension: Priority, and came up with an effort-priority quadrant for facilitating the difficult tradeoff between effort and priority during sprint planning. I tried this out several times with a complex product and diverse team, gaining quick and lasting agreement on planned work for the sprints.

Since no one can properly estimate what they don’t understand, the team reviews the stories in advance with the product owners to get an idea of what needs to be built and what it might take. Ideas for preliminary tasks or steps are appended to the story description to make it more relatable to the development team. Additional acceptance criteria are added as discovered.

To prepare for the estimation, write or print out the stories on cards or stickies so they can be positioned anywhere on a wall or whiteboard. Write discovered tasks on stickies or labels and append to their stories so the tasks can be moved together as a ‘package’ or moved to another story. You could also just write them on the story cards and rewrite them as needed.

Graphical Instructions are in this slideshow:

At closing, hold a 5 minute meeting review (mini-retrospective) with team or just by ScrumMaster and product owner and tech lead for how things went

Of course, the ScrumMaster needs to represent all stories and tasks in an issue tracker, document repository,story map and/or agile wall to reflect effort estimation and updated priority

    I hope this is clear enough for you to adopt this tool to facilitate easier sprint planning. Please let me know what you discover, improvements, advantages and drawbacks.

    Posted in Techniques.


    New Tech Happening in Santa Cruz with Graphic Recording

    Last night I was at the Santa Cruz New Tech Meetup with Artist Elizabeth McClellan and captured this time-lapse movie of her illuminating drawings of the event as well as some interesting photos. Google showed off Google Earth layers http://earth.google.com/tour.html and mashups, PayPal showed off open and micro payment APIs, http://x.com/ and Digital Media Factory http://www.digitalmediafactory.net/ featured their awesome design and production facility and movie/game/music/art making resources. Wine, Upper Crust Pizza (late but worth it) and lots of networking opportunities made for a high value event.

    Posted in Uncategorized.


    Innovation Games® Explores Circles of Influence at Agile Roots

    I just returned from an empowering time at the Agile Roots Conference and saw many fun and useful presentations and workshops. I am an Official Innovation Games® Facilitator, so I was excited to help out with Luke Hohmann’s keynote presentation on Software Powered Innovation Through Collaborative Play.

    After a few minutes explaining the value of games in fostering collaboration, Luke began the Innovation Game® Spider Web, where participants (nearly all conference attendees) were given 2 pieces of paper and a set of crayons, instructed to write their name at the center and draw a circle around it, then surrounding this, to draw the names of the people they interact with at work connecting those people’s names to each other and the participant. The more significant the interaction , the thicker the connecting line.  After this, the participants were instructed to use the second paper in a similar way, but instead of putting peoples names, put their roles or titles. This can be useful for discovering the full milieu in which you work, accenting relationships of control and influence.

    I was walking around the room making sure everyone had supplies needed and noticed the interesting variety of drawings. (there was no example given purposefully). Some drew a single large circle and put the names on its circumference, others created something that looked exactly like a real spiderweb with many interconnecting lines, others dispensed with the circles and just used text. One individual used dots and initials to represent people efficiently.

    That’s the beauty of these games, everyone can work with their own imagination and knowledge in ways that they are comfortable with. In fact I overheard several people commenting on the insight they gained when they re-discovered relationships of influence. and how they were going to work those when returning to work.

    Look for more experience reports in upcoming blog entries.

    Posted in Insights.


    Presenting Illustrated Personas, Skits and Storyboards at Agile Roots Conference

    For the last month I’ve been preparing for a workshop entitled: “Using Skits and Storyboards to explore and communicate the product vision” along with my colleagues, social media maven Amy Lightholder and artist Elizabeth McClellan.  We’ve also been preparing to demonstrate the process of illustrating a persona with the purpose of bringing more humanity into the product vision.

    I’ve learned how much better and more fun the outcome is when collaborating with others.  The organizers of this conference have been so friendly and have such a light touch to what they do, the preparations and coordinations have been effortless and in a true just-in-time lean manner.

    well, flight is leaving now, more later…

    Posted in Uncategorized.