You can’t learn agile software development from a book any more than you can learn to perform a one-handed jump shot without repeatedly tossing a basketball in the hoop. You can read a book about the basic idea, you can read a book to get started, and you can read a book about refining your technique, but in the end you have to practice.
A basketball player performs drills to play better in the game. In technology development, we can perform workshops to get better at our main business — delivering software.
This is true whether you are a developer, designer, project manager, or, perhaps most importantly, a customer or an executive. It is particularly important for executives to appreciate the advantage of agile methodologies, and the best way to come to that appreciation is to see it in action. The lowest-risk way to do this is to perform an exercise that can be done in a single afternoon with any group of willing participants.
A successful workshop will do two things:
- It will surprise the participants with how much can be accomplished within a short time.
- It will convince people that evaluating early iterations is invaluable for making adjustments for the next iterations to achieve the best results overall.
This workshop may be treated as a learning exercise that doesn’t attempt to produce anything beyond experience. The participants may be unknown to each other, in which case it will be a good team-building exercise, or may be an existing team. One could even choose goals which are a valuable work product for an existing team valued by an existing customer.
Structure
The shortest reasonable workshop is comprised of three simulated “sprints.” Each sprint has the same structure, which represents the actual structure of a software sprint. In order to fit the workshop into three to five hours, each sprint must be very short — 30 to 60 minutes. Nevertheless, your participants may be surprised what can be accomplished in this short time, if you, as the master of ceremonies, can effectively enforce a disciplined structure.
Although one can always adjust the agile process to suit your needs, I recommend being strictly dictatorial in your workshop around timekeeping and the structure of the sprints. The overall structure is:
- An introduction and explanation of the process
- Sprint one
- Sprint two
- Sprint three
- A retrospective and reflection.
This means that there must be a rigid agenda, with sprints one, two, and three beginning precisely at the planned time.
Each sprint likewise will consist of:
- A period of writing stories on notecards
- A development period that focuses on interaction between the customer and developers
- A demo
- A sprint retrospective which focuses on the process
- A break before the next sprint begins
The time allotted to each of these activities will depend on the overall timeframe for your workshop. In general the demo and the retrospective for each sprint can be done in five minutes each and the story writing period can be five to 10 minutes.
Teams
You can have one, two, or three teams -- but if you are running a workshop for the first time, I recommend starting small. No matter how many teams you have, you must enforce a precise agenda for each team. Every workshop participant should participate in all demos, and you should organize your agenda around consecutive demos.
I prefer not to have the teams compete, but to give each team a different goal. It is even better if these goals are complementary.
The teams consist of two clearly distinguished roles. The customer gets value from using what is built, but does not care how it is built. It is critical that to remember that the customer is the end-user, not the person funding the project. For example, a CIO of an agency is the executive in charge, but is rarely the customer, except for dashboard and reporting projects. It is imperative, especially in government work, to always seek to interact with the actual Customer as early in the process as possible. In the case of a learning workshop performed as an exercise, the customer may be an executive who simply wants to see how agile can work for them, or could be a true end-user of an existing team. In many cases, the customer is not a technologist, and in all cases they should have no opinion about how to accomplish something.
The second role is named developer---by which we mean designer, coder, writer, or more generally, maker. The ideal team size is one to two customers and two to four developers. If you have more than five developers, there will be natural pressure for it to devolve into two teams, particularly in such a short workshop.
Roles
Each participant performs one and only one of the following three roles:
- Customer
- Developer (designer, coder, writer, maker)
- Master of ceremonies and coach
The master of ceremonies/coach
The master of ceremonies/coach enables the rest of the participants to learn by performing key responsibilities.
Prepare the participants
The master of ceremonies must coach the customers ahead of time so that they are prepared to drive their teams. The customer must have a clear goal in mind, and sufficient willpower to direct the team appropriately. If the customer doesn't have one ahead of time, the master of ceremonies/coach must work with them to develop a goal.
Provide an effective physical workspace
They must also enable teams to collaborate effectively by making sure that the physical space is appropriate, there are appropriate refreshments available, and the office supplies are readily at hand. Notecards and pens are absolutely required. A whiteboard or flipchart for each team is valuable for “scribing” the sprint retrospectives and the final workshop retrospective. Finally, they must make sure that the computer and audio/visual facilities are properly prepared. Not all workshops will require computers or audio/video space, but larger ones may.
Preparation of the non-physical workspace may include establishing ahead of time a shared file storage, ideally with version control and easy web viewing, open to all participants, such as those offered by a shared code repository on GitHub. This makes it easy for people to collaborate, leaves a history, and produces a durable record of the workshop product to be used later.
Enforce a rigid schedule
Enthusiastic teams will want a little more time to improve their demo. The master of ceremonies/coach must not succumb to pressure to deviate from the pre-planned schedule. If a demo is less than impressive because a story is not done, this is a learning experience for the team.
Coaching during the workshop
Coaches should make make sure that stories are written down on notecards during the story writing phase. However, even more important is that the progress of the development team during the development phase be immediately and constantly shown to the customer, who may make adjustments in priorities at any time.
Coaches may also provide guidance on agile techniques during the workshop. However, this is probably the least important of his or her responsibilities. If they can enforce the schedule, he or she need not be a terribly experienced agile practitioner. The Teams will learn by doing, and if they have properly prepared the customers and created an enabling space, the Teams will learn from their failures and/or enjoy their successes based on their own merits.
Enforce responding to the customer
The paramount responsibility of the master of ceremonies/coach is to insist that all work be shown as soon as possible to the customer and that customer changes to direction and priorities be immediately respected by the developers.
The customer
The customer is the most important role, and demands preparation. The customer is considered part of the team. The customer must bring to the workshop a clear idea of something that they would like to have produced within the workshop and an ability to flexibly set priorities and give feedback based on progress.
The customer must be prepared to participate in a story-writing process that is motivated by a clear goal. This goal need not be precise or detailed. However, the customer must have in mind what they want and be delighted when progress toward this is made. He or she must be prepared to help the group articulate very small steps towards the goal and compromisingly choose priorities for steps that team can accomplish. The customer must be prepared to converse with the developers and make a rapid prioritization based on a quick estimate.
A tester or auality assurance person is considered a customer for the purpose of such a workshop. An executive who wants to experience agile development should probably play the role of customer, because the most valuable thing that can happen in the workshop is for them to come to appreciate the power of being able to make iterative changes to development based on what has been learned from rapid, early development.
The developer
The developer may be a computer programmer, a writer, a designer, or anybody else who is making things. The reason the developer role must be clearly delineated from the customer is that the developer must not be a bully. That is, developer have a a monopoly on making things, so they can easily slip into asserting their own ideas about what should be made. This is the one thing that developers should not do. They must cede all control over what is made to the customer.
It is, however, the developers’ job to teach, (in this case very quickly) the customer how much time it will take to make any given story that they ask for. The developers must provide quick estimates on the spot. They do not have to be accurate, or confident -- they need only be honest.
Example team goals
You can run three-sprint agile workshop around a goal of producing a valuable end product. However, you may prefer to simply treat it as an exercise.
When I did this many years ago in Mumbai with three teams, I used the task of building an online calculator. This is a good exercise, because one can easily imagine a very weak calculator with features being smoothly added to create a powerful calculator.
Looking at great teaching books can provide good ideas for projects. For example, a currency conversion calculator sounds simple, but has some interesting challenges. This was an effective example from Kent Beck's book Test Driven Development by Example introduced shortly after his seminal work Test Driven Development. I have not run a workshop around it, but I believe one could run an effective five-hour workshop around this exercise as well.
For a group of participants that did not include strong coders, I might plan goals easier to program or which involved no programming at all, such as creating a simple blog with GitHub Pages or WordPress.
If I had a group of program managers, I might have the developers essentially be writers, and suggest goals such as “Build a website that informs people about the benefits of regular exercises.” In all cases, I would work with the customers ahead of time to make sure they had a clear idea of what they wanted to accomplish, but were open to change based on what they got from the developers in the First and Second Sprint.
The surprise pivot
In order to demonstrate the value of agile development in a fun and challenging way, you should prepare ahead of time a little trick to play on your teams. This is a “pivot” away from what they were originally thinking to a new mandate driven by the customers. Such changes are major risks to government software development. Sometimes these are actually driven by regulatory changes, sometimes by a changing technical environment, sometimes by discovery of a new opportunity.
The pivot should occur in the third sprint. If possible, it should relate the multiple teams that you have to each other. It is important that you coach your customers ahead of time about the pivot, so that they can correctly communicate the new requirement to your teams.
Things that can go wrong
To some extent, things going wrong is helpful, if the team can learn from it. Here are some things that can go wrong:
- The team can fail to break the goal into small steps that can be executed within the limited time of one sprint, so that they have nothing to demo.
- Developers can be bullies and impose their own desires on what gets built.
- Customers can fail to assert priorities.
- The team can fail to simplify their goal enough to get anything done within the workshop.
- A team can be so large that it is difficult for them to coordinate work within a sprint. If you know you have that many participants, you should increase the number of teams to keep the team size smaller.
- The team may devote too much energy to thinking about the final product in the third sprint and thus fail to do good a good job presenting functionality in the first demo. A team that does this will also be stung by the surprise pivot, which will likely cause some of their work to be wasted.
Your turn!
If you’ve made it this far, you might be looking for examples or more information. You can read more about a recent workshop I led at 18F as a team-building exercise. The case study has example goals, projects, and pivots to give you ideas for your own workshop.
Another option: Bring on 18F as a coach
18F has recently created a new pilot line of business called 18F Consulting which offers agile coaching and other services at cost-recovery prices under the Economy Act. If you’d like assistance or you’d like us to run a workshop for your team, please get in touch!