Agile iPad Deployments : Visioning and Bodystorming

In the last Open Scrum Crash Course (see webpage here) I held for other Districts and schools in Arizona, I had a lot of requests to see how we do Agile and Scrum.  This post is an effort to open up our doors to show how we attempt to innovate while having fun using Scrum and Agile techniques. I hope you will find it useful as I post our Agile and playful approach to our big student iPad deployment project in the District.




Develop or Revisit the Vision Statement


First, we co-develop the Vision statement for our iPad project together with the District stakeholders.  Our favorite way is to post the Vision template up on the wall with each participant placing sticky notes in the blanks independently.  We then review the sticky notes, aggregate similar notes into categories, discuss, and gain consensus.  We will quickly refine the wording for each blank based on our consensus. This is timeboxed for 15 minutes, no longer.  We use a very common Vision Statement Template for Agile teams:

FOR (target customer for the product)

WHO (users’ needs) 

OUR PRODUCT IS (the product category)

THAT (major benefit, key functionalities)

UNLIKE (current practice, competition)

OUR PRODUCT (major differentiator)

Our Final Vision Statement.

"For LESD teachers, managed IPads will be used as an educationtechnology device, which provides an engaging experience "at the points of learning". Unlike unmanaged iPads, this solution willprotect student safety and ensure compliance with license agreements."

We had a pretty good debate on who our customer really was, the teachers, the students, administration....

Define User Roles


We developed several roles for the iPad project to help us understand what different stakeholders valued in the iPad deployment.  We use the typical User Story format, As a (user), I want (what), so that I can (value/why). The roles were:

1. iPad Facilitator - This persona for the person who buys the apps, manages vouchers, ensures software compliance for a campus or department.
2. Campus iPad Manager - The person who physically manages the iPads on campus. Usually a teacher or aide. Syncs, charges, inventories, troubleshoots, etc... The Facilitator and Manager could be the same or separate people.
3. "Good" Teacher -  A teacher who uses the iPad for the right educational reasons, while understanding that following policies and procedures are important. (Most if not all of our teachers fit into this role).
4. "Bad" Teacher  - There are always some employees who do not care about the rules and will go rogue. We make these into "anti" stories, stories from a stakeholder which we want to prevent or mitigate.  (These are few and far between, hopefully we have none, but, we have to plan for it).
5. Good Student -Wants to use the iPad to make learning more fun and engaging and follow the rules.
6. "Naughty" Student - wants to sabotage the iPads, use to distract from their education, steal, abuse, use it as a food tray etc..(Unfortunately, we do have a few of these at times. Even good kids have their impulsive moments.)
7. IT Technician - Staff in the IT Department offering technical support for the iPads.
8. Business Office Staff  - Combines several roles here, including the Business Manager and Procurement Director and Staff.  Concerns here are auditing for software compliance and procurement compliance with District policies and State regulations.

We post these roles on a role board with 3 columns. Role, Goal, Value.  As the team went through the bodystorming, it began to fill up with sticky notes, which we then turned into User Stories.

Role Board to Generate User Stories for iPads

Under some of these roles we placed a Responsibility Card underneath, which has 3 columns, Do's, Don'ts, and Support (who/what does this person support).  We filled in the Responsibility card as learning emerged from bodystorming, since, one of the goals of the project is to develop roles and responsibilities for the iPads across the District.

Role with Responsibility Card

Good Teacher/Bad Teacher Roles

BodyStorming 


to Elicit User Stories, Outline Role Responsibilities, &  Develop Processes


A great exploration exercise to elicit stories and understand your constraints is called Bodystorming.

"Bodystorming is a unique method that spans empathy work, ideation, and prototyping. Bodystorming is technique of physically experiencing a situation to derive new ideas. It requires setting up an experience - complete with necessary artifacts and people - and physically “testing” it. Bodystorming can also include physically changing your space during ideation. What you're focused on here is the way you interact with your environment and the choices you make while in it." - dSchool K12 Lab

We create "role tags" for each role that a bodystorming participant will take on. Each participant volunteers and places the tag on them.  You will be amazed at the acting talent in that comes out when people get into their roles!  It is best to have your team and the customer there for their point of view and to have great discussions.

We brought in our configured iPads and iTunes syncing stations so we could truly bodystorm the activities.

We use an artifact I created called, for lack of imagination, "the process table".  I divide the table into vertical columns with painters tape.  On the left side are what we wanted to develop a process for. There are 3 colored sticky notes we used to develop the process and responsibilities. Who? Dos? Don'ts . The colors are not important, it is just a way to quickly look at the table and know what is what. 

I created 7 "Step" columns (Step1, Step2....Step7) that we placed these colored sticky notes in each step of the process. On the opposite side of the table were our Finish lane, with  Acceptance Criteria, in which any process must meet. If the process did not meet the Acceptance Criteria we established, then, we would "reboot" the process, and identify in which Step violated or missed the Acceptance Criteria.  Our Acceptance Criteria included items such as 1)1 App Purchase /Device 2)Must be able to audit for software compliance 3)Can not violate copyright (for music/videos/books).  

Process Table 1

Process Table Pic 2

For example, our first process to bodystorm was how to buy apps though Apple's Volume Purchase Program.   In Step 1: Who? - Teacher who wants an app , Dos?- How do they request an app, Don'ts? - Don't use personal iTunes account on District device . 

A new user story emerged from the discussion as well, which was, "As a Teacher, I want to experiment with new apps, to see if it is a good fit for my classroom" which we added to the Product Backlog.  This will become a process we bodystorm in the future.

Retrospective

This took much longer than I thought to develop the first process. Not because of poor planning or a uncooperative team, but, because every step we took had at least 4 decision paths to take, which we had to try and discuss.  It took us about 2 hours to bodystorm and build consensus on the best process for the District to purchase and deploy iPad apps.  On the other hand, several other processes went very fast once we got through the first.  It was well worth it, not only did we understand the process, but, we understood why the other alternatives were not the right fit. Our team really enjoyed the body storming game. Our retrospective for the meeting:

• What We Liked: Loved the process. Appreciated we got to try each step out instead of just talk about it, which allowed us to bring to the surface what was feasible and make tradeoffs in real time. Enlightening.... Documenting the process is easy since we have it all laid out on the process table in sticky notes.
• What We Did Not Like: One member did not like the "role tags" they put on. I actually liked it, since, I forgot twice I was the "iPad Facilitator", but, I am aging... Maybe I'll leave it to the team next time to decide.  We should have created some "test" accounts before bodystorming (we used our production iTunes and Facilitator accounts).
• Ideas or Insight: The process brought to light many of the constraints we were under. Our solution was surprisingly unexpected, which emerged from real world results.  Great debate on what a user really wanted and how to meet that need.  Once we got one process, some of the other items piggybacked off that process, which made it simple and integrated.  We will definitely do this again.
• What is still Cloudy/Unknown: We did not get through some of the process items we needed to, so, to be continued.....

Developing processes can be fun, engaging, and agile.  I say agile because we built the requirements, iteratively developed the process, and tested the process at one time, a true agile approach.  Please leave a comments and questions and thanks for reading.