At the Agile Testing Days the final keynote on the first day came from Elisabeth Hendrickson on Lessons Learned from 100+ (Simulated) Agile Transitions.

Elisabeth Hendrickson reported from her experience with the WordCount simulation. In the simulation the participants are part of a company with a product that counts words, a word counting system. The program is written in plain english as written words. During the simulation, Elisabeth provides the initial working agreements, which are based on a more traditional view. Each team sites in its own workspace is the first rule. The Interoffice Mail Courier handles all communication. Testers & Developers must send status reports to the Product Managers, including how many lines of code written, how many bugs found. Only Developers may create of modify code. Developers deliver code by installing it in the installation tray. Testers must document all test cases to be executed on test case cards. And all bugs must be documented and tracked on bug cards. Testers send the bug cards to the developers, and only the product managers may interact with the managers. Finally, the customer decides whether or not to accept the system. The simulation is split up in iterations, and after each round, participants reflect and adapt the working agreements using characteristics of agile to guide toward increased agility.

What typically happens in these simulations is that since the team deals with the documentation, the computer is pretty bored in the first round. It is not uncommon in this setup that the testers just write test cases, but do not have any test executed by the computer. Basically the company is then setup to not know anything about the system, because it is not executed in first place. From her lessons she explained that no one has shipped any software in the first round.

Another thing Hendrickson learned, was that people add their own complexity and time pressure. Initially she included some tricks like not having complete requirements for the testers. Over time she found out that she had to take them out, since the problems the teams created for themselves were overly complex already. She reported from a team that did quicksort in english language in order to work themselves through the requirements. On time pressure Hendrickson mentioned that the product managers could turn dizzy if the customer was asking for a product demonstration during the first round.

What typically happens in round two, is that the mail courier is being fired by the teams. Another thing the teams get rid of are all the rules that impede communication. The second round is rather chaotic mostly, since all people just do something, but not communicating effectively. She explained the chaos state with the Satir Change Model. She worked through the stages of the old status quo, when an foreign element is introduced, and the team falls into a chaos. While dealing with the foreign element, people try many things, in order to cope with the new element. Over time with practice and integration, eventually a new status quo can be reached. Any transition results in chaos (for a period of time). Another fascinating thing in round two is to hear something like “Things are out of control! We have to get this under control!” which isn’t actually a cry for control. Hendrickson told the story of a team who was asking for a project manager, and convinced a ScrumMaster to do this. After the next round, that person had enough from it already, and stated a simple “I quit!”.

In round three teams start to find structure for themselves. Since this is a process the teams designed by themselves, this step varies to the extent of the variation in the teams. A common pattern is to find a wall where everything is placed on. A single place to take a look on bugs, and requirements. Small changes in physical layout can make a huge difference. She told a story from a team which had physical impediments between the developers and the testers in the simulation room, which prevented the team effectively from talking to each other. When they changed the structure, the team started to work effectively together, as the ice melt. Just placing some tables a little bit different released the bottleneck to their communication. Another story included to have the product manager removed into his own office, thereby the team was setup for way more productivity. Another lesson Hendrickson was to not use communication solutions for visibility problems. Instead of asking “Are we ready to demo?” getting the visibility on the information radiator on the wall helps increase productivity. Project Status is a visibility problem.

In round four the simulation starts to run fully on all cylinders. Teams at this point use tests as an alignment tool. She saw the connection between tests and requirements, but that tests are more than requirements in this regard. Hendrickson also stated that failure stems from dysfunctional systems, not individuals or teams. She explained this from a team where she was warned before the simulation by their manager. This story turned out to be a problem in the organizational system, not in the individuals which knew what to do to large extents. The team had outperformed the pre-organized requirements, and beaten effectively any record of the simulations. The root cause of the problems with the team was that this particular component team was dependent on any other component team. They were amongst the highest performing teams she had the honor to work with, but were put into a bad systems, and thereby penalized.

In summary, teams that struggle hold tight to roles, silos, and separate work areas. These have everything in progress and nothing done, wasting time trying to coordinate work, and get in touch with the customer. Succeeding teams in the simulation drive development with customer-provided examples. They seek customer feedback early and often. They re-shape their physical environment, and they re-invent key Agile engineering practices around feedback and visibility, like Continuous Integration, ATDD, etc. At the end of the simulation, the team holds a retrospectives, and try to find ways to incorporate the learning into their working environment.