Bedtime Scrum

"Bedtime Scrum" with my 3 year old daughter

The Problem

My 3 year old would not stay on task to go to bed in time. She would get very distracted ( I think this is a genetic trait inherited from me) which caused her to stay up past her bedtime and make Mommy and Daddy exhausted.

The Solution

We know kids are visual, tactile, and crave empowered. Well, then, Scrum to the rescue!

The Bedtime Scrum Artifacts

On a Sunday night, I quickly made a Bedtime Scrum Board with 3 lanes, a Yellow Light, Green Light, and Red Light. Yellow =To Do, Green =Work In Progress, Red =Done.

I went to the computer and downloaded pictures that would represent her bedtime tasks. We started with storytime, brushing teeth, pajamas, and goodnight. It grew in later iterations to include her Flintstone vitamins, milk, and potty.  I posted the board (easel sticky paper) on her wall , at her height, so she could move each picture.  

The Bedtime Scrum Events

Bedtime Sprint Planning: We scan over all the items in the Yellow column that we need to do for bedtime. I ask her if she can do it all, which has always been a big "Yes!".

The Sprint: She gets to choose which item moves to Green (Work In Progress). I will have to talk to her about some items she chooses if there is a dependency. Such as why brushing her teeth might not be a good idea if she has not finished drinking her milk.  She loves moving the pictures and does not let me touch them. If I encroach on her territory, she races to the board, rightfully exclaiming, "No, Daddy, I want to move it". 

The Review: Once all the items are in Red (Done), I ask her what she has accomplished. She'll reply,  while pointing to each picture with pride, "I put on my pajamas, I drank my milk, I read a story...I did a lot!".  

The Retrospective: I congratulate her for a Bedtime Scrum well done.  I may also suggest something we can try different or improve for tomorrow.

The Bedtime Scrum Results

I believe she enjoys the process because she gets to pull which activities she does, making her more empowered.  She is noticeably more on task and more self-directed.  She will often start pulling a task from Yellow before I even prompt her. The great benefit is that I do not have to nag her to get these tasks done, she is eager to to do it so she can move it to Done herself.  If she does start geting distracted, I ask her what is in Green still or what can move to Green.  I am sure this helps Daddy stay on task also.

What's Next and Insights

My wife would love for me to change how it looks, since it is just a quick and dirty prototype to see if it would work. She has been patient with me since it has been effective.  My next honey-do project is making the board look nice. My daughter wants to color some of the pictures, which will make it more "hers".  

Bedtime Scrum demonstrates how Scrum and Agile is a very natural way to work.  My daughter did not attend project management class or a Certified Scrum Master certification to do it. We are highly visual and tactile and work best in an environment that enables self-empowerment. Agile is so easy, even a 3 year old can do it!

Try this with your young kids and students, I would love to hear your results. Good night, sleep tight, and don't let the bed bugs bite.

Values Driven Retrospective

"Values-driven leadership realizes its full potential when espoused values are embodied by leadership and embraced by the entire organization. This allows for an authentic and sustainable business culture to emerge." -Center for Values-Driven Leadership


I recently developed a highly visible measurement of how the team is living it's Agile values to ensure we sustain and improve.  We used this as part of our monthly department wide Retrospective to ensure we remain value driven.  It also serves as a highly visible reference to reflect on our actions and commitments throughout the day.

Agile Team Values Gauge

Objectives
To continuously improve your team and your work through value-driven Retrospectives.

Dependencies
You need to have defined values that the teams have committed to prior. We use the Agile values of Commitment, Openness, Focus, Respect, and Courage (See Scrumallance.org Code of Ethics) .


When
We do this every monthly staff meeting during a part of the meeting we call the Retrospective, where we discuss how we are progressing as a team. You can do this during any regular meeting or during your Scrum Retrospective.

How

1. The facilitator provides a quick overview of the team values.
2. The facilitator takes a value, and asks the team, to get an initial pulse, "How do you feel we are doing in value x". The facilitator asks the team to rate the value from one to five, using the Fists-to-Five consensus technique.  Make sure to try to get the team to vote all at once, since, some members may be unconsciously influenced by another's vote.  You could also use Planning Poker instead of  Fists-to-Five to gain consensus.
3. The facilitator polls the the group if there is a significant variation in the votes. For example, she might ask, "For the '5's', Why did you vote 5? For the '2's', why did you vote 2?". Allow a short time for discussion, but not too much. Keep it to about 1-2 minutes.
4. Now that the team has a deeper understanding of others perspectives, ask the team to vote again on the value using the  Fists-to-Five. Ask the team to commit to a number from the second round. If there is a significant divide, such as half 4's and half 5's, I take the lower number.
5. Change the dial on the Value Gauge Card to the number agreed to.
6. Do this for each value.
7. Once you are done each value, ask the team: "Which value do we want to improve on until our next meeting?". Gain commitment from the team through discussion and visual vote, such as  Fists-to-Five or thumbs up/thumbs down.
8. Ask the team "What is the one thing we can do to improve living this value?". Stress that it is just one thing, since this brings focus and increases success of the improvement, rather than tackling too much and failing.
9. Allow the team to discuss. Gain consensus and commitment to what the team will do to improve by the next Retrospective/meeting. Phrase the commitment into a Believe Statement: The Believe Statement format is: We Believe in [insert value], therefore we will [insert what we do] .  For example, our team's "Believe Statement" was "We Believe in Courage, therefore we will have a team building get together so we can establish a safer environment to be courageous with one another. "
10. Write the Believe Statement and post it in a visible place for the team.  I prefer placing the Believe Statement on to the Value Gauge Card so it reminds us of our current status and that we are doing something specifically to improve it. It is also handy so that you do not forget to review your results in your next Retrospective.
11. Review your Believe Statement/Goal and the results the next meeting and then repeat the process.

Variations
360 Degree Leadership Feedback
After we completed this as a Team, I quickly went through it and asked the team if I, as the Director, was creating an environment that fostered these values. We went through the same process of rating and creating a one Believe Value Statement Goal.  This allowed some great feedback for how I can improve for the team and also provided a great example to foster, in what the book "The Five Dysfunctions of a Team" calls, Vulnerable Based Trust.

Apply it in the Classroom with Students
You could easily use this in the classroom with students, as, well. Many schools use the 6 pillars of Character  for character education which could work very well in a Classroom Retrospective. A future post, perhaps.

Summary
My team really enjoyed the Agile Team Values Gauge game. It brought some issues to light, but, more importantly, what we were doing really well.  As we go through several iterations of this retrospective, it might be useful to have a chart plotting our progress over time.

Please try it with your teams and let me know your results and your modifications to it. I think you will find that participants will appreciate talking about their values, their integrity in living their values, and that it provides a good guide for developing Team Working Agreements and other team decisions.

John Miller
The Agile School Blog
CSM, CSPO, PMP, [insert other self important initials here...]

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.