The following are instructions handed out to participants at a recent workshop I ran. The stated goals of the exercise are to create a micro-service based calculator, a patently absurd goal. The real purpose of the exercise is the allow the attendees to learn for themselves how to self organize, providing only as much guidance as proves necessary. The results are described below the handout.
Welcome to ICC, Incremental Calculator Corp. Today you are going to build the first ever micro-service based massively scalable calculator.
Features - in value rank order:
Constraints – ICC’s CEO recently subscribed to a trade journal and has been reading up on all the latest trends. As a result, he has mandated the following constraints:
Definition-of-done for each feature after the first sprint must include unit tests and Behavior Driven Development tests running green. The tests must assert expected behavior for both success conditions as well as failure handling.
Bonuses are offered for each of the following:
The “rules” are described as follows:
<end of handout>
What I intentionally did not do was give specific direction on how the teams should be organized, formed, or anything else that self-organizing teams should figure out for themselves. I was richly rewarded by the results.
The "Bonuses" were a deliberate attempt to lure the teams into competition vs. collaboration.
Results from 4/11/15 workshop:
Sprint #1: By the end of the sprint (45 minutes) the attendees
In sprint one's retro it was brought out that a lot of time was spent getting everyone to the same place in terms of MVP. For instance a lot of time was wasted trying to work out session management to accommodate multiple clients. YAGNI.
What they ultimately did not do (yet) was show any working code. The reason offered was that the other parts they were reliant on were not ready yet. It was pointed out that each team mocking the part they were dependent on from another team would have allowed some/all to show demonstrable progress.
Quotable moment: One participant observed that in a single 45 minute period they have accomplished what large companies are often unable to do after a months time.
Sprint #2: By the end of the sprint the attendees …
Some struggling with github and git was observed. Made it clear participants must reach out when they are stuck. We talked about time-boxing a problem to prevent it’s becoming a sinkhole.
Advised teams that they needed to be planning for integration by actually talking across teams. All communication after they split up into teams had been entirely intra-team. Lunch was used as an opportunity to bridge the gaps between teams.
==== Lunch ===
Sprint #3: Breakthrough – some exchange of APIs and subsequent learning and adjustments. Also demo-able code (a single operator button and two input fields) worked locally but did not have a working network connection feature yet.
Also saw some learning about the mechanics of sharing a repo among teams, e.g. jars that were unfit on any system other than where they were created.
Pull requests were offered as one method for managing the repo, along with much more inter-team communication in general. Agreeing on conventions/policies for what constituted acceptable packaging for a pull-request was discussed.
Notable learning: Using a virtual card wall (Trello) was attempted, to manage the work and to report bugs. What actually happened when a “bug” was reported (verbally): the participants instead walked over and talked to one another and quickly eliminated the problem. No problem remained to track. This resulted in a retro discussion about the priority of “bugs”.
Sprint #4: Big jump in demo-able code – all four operators worked locally, on the client; only one operation was wired up to invoke the server connection. The communication succeeded at a network layer but apparently not at the application layer. An unexpected reply was received.
All four operations passed local BDD function tests on the server. Problems with round pegs and square holes persisted in the exchange of code. More getting up and moving to another table to talk other teams, was reiterated as not only allowable but highly desired.
Getting closer, and cross team communication is now common. Network communication is working a now the server code returns http response codes as well as messages to indicate results or complain about what’s wrong.
It’s 5:10 (we started at 8am) and I can’t get these people to leave; they really want to show results (which was never the objective). I’m feeling very good about how the day went. The participants seem to share that feeling.
If you feel any of the above has value for your training/workshops, please feel free to copy all or any part. I would ask only hat you give attribution and reference this post.
Thank you, Bob Allen