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. 

Disrupting Ourselves - How to get started

My call to arms for an Education Technology Manifesto in my previous was not necessarily overwhelming in responses. Perhaps that is thinking too far ahead. Maybe the mechanics of what agile is in Education Technology operations may be more practical. So, I will dedicate the next few posts to the experiments of agile I have done in my department.  I also want this blog to be beyond technology and how agile can help classrooms and students. Agile in a school and a classroom is not fantasy, in fact, I gave a Scrum crash course to 2 schools and have teachers already using Scrum. One team used to to implement their Positive Behavior Systems for student behavior and another used to to create a new Coat of Arms for their school.  Some of these teachers are using it with their students currently. But we'll dive into that later.

As a recovering PMP, I can not help but also state what is out of scope in this blog. I will not be covering in detail all of the mechanics, values, and frameworks of agile and Scrum. The web is proliferated with these, and you are better served reading their posts.  I will be talking about how to apply and adapt Agile to schools, classrooms, and Education Technology environments. In other words, how I or have seen others apply agile to adding the most value in the shortest time to education. I will share the successes, ideas, and mistakes.

So, let's get started by showing you how I got started. I was caught in a downward spiral of what they call "technical debt" in our small IT Department of 12 staff members.  We had so many projects and so many support obligations. The way we did projects was to form an ad hoc, just in time, project team, and add those responsibilities and tasks to their daily operations tasks. This caused the following issues:

1. Poor quality project deliverables due to being constantly interrupted and pulled by support tasks
2. Poor project management discipline, since the team could not gain a deep knowledge project and product development methods and techniques. In others words, a lack of focus on product development and projects.
3. Poor teamwork, since project team members were not permanent, but temporary for that project. In the Forming, Storming, Norming, and Performing stages of teams, we rarely ever got to Norming stage before the team disassembled.
4. Poor understanding of expectations of performance, since project success and support success were defined differently.
5. Projects often missed important success factors, such as transfer to operations and training, since, we had to get people of the projects and back to their "real jobs" in support. 
6. We fought change and got frustrated when schools and administration had to change the plan, either based on real changes they were reacting to or just simply changing their mind. This created animosity between us and others in the District we were completing the projects for.
7. Poor estimating (mostly due to lack of time for feasibility studies) of project duration caused us to often over commit, which resulted in a choice of getting it all done, but sacrificing quality to do so. 
8. Without defined human resource constraints for projects, we also over committed our project portfolio, tackling too many projects in a year.
9. Poor collaboration with the project clients, since, there was not time for it. 
10. The project management framework I put in place was too heavy for staff who were "just visiting" the project world. It frustrated me and my team with unrealistic expectations and overhead. Support and operations processes our very different than project processes, and both require different perspectives on how to carry out your work.

So, all of this caused technical debt to bleed all over the place. In the end, we spend more time cleaning up the loose ends in support, disrupting our support commitment even more.
To solve this problem, we came up with the following solution.  We would create a permanent and separate project team. In order to stop the cycle of technical debt, we had to be more proactive in our projects. The benefits of this approach were:

• Proactive and quality design and deployment would reduce support issues in the long run. Pay down our technical debt
• Team work would improve for projects in a team with static membership
• We would increase customer involvement and communication
• Fewer loose ends.
• Transfer to operations would be built in, such as training sessions for IT staff on how to operate the service.
• With a static project team, I could better estimate and coordinate our project portfolio.

We had to carve this new team out of the existing. Since projects and the skill sets needed for any given project varied, I could not just pick specialists for the team. Plus, I could not cannibalize the paralyze the support team's performance by removing too many critical skill sets. We had to create a team that might not have the skill sets for any given project, but, could figure it out, and learn what they needed to learn. We needed a creative multidisciplinary team.

We formed this new team incrementally this way:

1. Chose a Project Manager. Someone who could be trained in project management. She would lead, at first, "visiting project team members" on whatever projects were underway. This gave our customers a consistent single point of contact for projects. This in itself improved our customer satisfaction greatly. It also improved the quality of the projects. By the way, we were not agile yet at this point.
2. Our new project manager and I had many discussions on the best frameworks for our projects. At this this time, I discovered Scrum and starting reading about it. We discussed it and we both thought we were not happy with the document heavy waterfall approach we were doing. So, I enrolled us in a ScrumMaster course.
3. We both got ScrumMaster certified and knew this was the right framework. It really embodied the same values of an education environment. Values such as learning, emergence, empowerment, and creativity.
4. We tried it out on the next project. We gave a brief intro of how to do Scrum and the responsibilities of a Scrum team and started using it the next day We did not have a static team yet. By the way, Scrum is the only project framework I have ever seen you could show someone in a few hours, without any project training, and start using it effectively.
5. Our estimates the first sprint were way off, but this is typical when first implementing Scrum. It took about 3 sprints to get it right. But, the great thing was the team was performing better than they have ever have on a project. In 2 weeks, we went up several levels in performance. The combination of having a ScrumMaster on their team, a Product Owner (me), and the team focused, free, and empowered to do their work, translated to immediate and overwhelming performance. It definitely was far from a perfect Scrum, but it was far better than anything else we have done.
6. After a about 2 sprints, we were sold on the effectiveness of having a permanent project team and using Scrum. We all agreed having a dedicated project manager (no longer a Project Manager at this point, but a ScrumMaster) made a huge difference the quality. So, we moved forward and added 2 more members from the support team permanently to the project team. In the end, we also have another half time member that splits her time 50/50 between the project team and operations.
7. In a short period of time, we have made quantum leaps in our relationship with our customers, have superior quality products deployed from the team and our support team are not crippled with collateral damage of post implementation support issues. I will go more into how we did this in future posts.
8. We are in the middle of transforming our IT support team into an agile team.  This is a bit tougher, since we really have to modify Scrum and agile to fit into an operations environment. More to come on how we are failing fast forward in this area.

In summary, start small, iteratively improve, and form a separate team for product and service development. You need a team that can focus on project excellence and innovation without being spread too thin. Too really transform and become innovative we had to disrupt and innovate ourselves first. If we tried to incrementally change the current processes with the same team, we would have failed. The gravity of what is would have overpowered the inertia of what could be. We had to start fresh and small, evolve fast, and capture the success and grow them. Our projects went from mediocre to amazing. Our team went from stressed, to having fun while doing great things.
In the next post, we'll dive into the details about how we work!

Call for an Education Technology Manifesto

I have been an IT Director of 6 years for a large school District in Arizona, and have been in Information Technology for over 15 years. I chartered my career path and skills based on best practices that you find in all the magazines and books. I went from obtaining certifications in my technical trade such as Microsoft certifications to Cisco.  I improved my IT management skills by obtaining training and certifications in ITIL, Project Management Professional, and Support Center Director.  Pretty much, copying the track that of any Director or manager of IT systems in a corporation would have.  Afterall, were not schools supposed to be run like a business? Indeed, I improved the department and our services dramatically by doing so. All of the staff were also certified as Support Center Analysts to understand best practices for support processes and customer service. We instilled those metrics you were supposed to have, like, Service Levels, Average Time to Resolution, First Contact Resolution, Mean Time Between Failure, etc.  We implemented ITIL best practices like Incident Management, Problem Management, Change Management, and  Release Management.

These all helped, our systems were more stable with deep 9's, our ticketing system and service desk personnel were cranking through tickets and solving end user issues. Yet, the staff we supported still were unhappy with us. They saw us as many times slowing down progress, or, disconnected from education. We were doing everything we were "supposed" to be doing, and we could prove it. Teachers and admin staff, and I am sure students, were not seeing value being added. To make it worse, our superintendant would jokingly state that IT (and another student serving department I will not name) was a Black Hole, since we sucked so much money in, but not much back out to add to the core mission of education.  Why? We were working so hard with such dedication, only to be called a Black Hole.

I realized after much soul searching, after getting into the classrooms and talking with teachers and students, that we were operating from a wrong paradigm. We were working from a value system of a corporation, like a bank or insurance company. Afterall, many of the IT books were based around how to manage IT in banks and insurance companies.  Not from the value system of education. Values such as security, compliance, standardization, minimize costs, certainty, and control.  This causes frustrations in an education organization, where the values are creativity, exploration, differentiation, uncertainty, and freedom are needed to have an effective learning environment.

Our approach on IT in schools reminds me of an excerpt from the book by Thomas Friedman, Hot, Flat and Crowded, where the author described a new post 9/11 U.S. embassy in Istanbul that was made so secure that people said that "even birds don't fly there". Well, it also made it so secure that it blocked relationships between the 2 countries. Building  relationships is the main purpose of an embassy, isn't it? The author describes the security of the embassy this way,

"They are also strong enough to deter most visitors, friends, and allies. In fact, when I first set eyes on the new consulate in 2005, what struck me most was how much it looked like a maximum-security prison - without the charm. All that was missing was a moat filled with alligators and a sign that said in big red letters: "Attention! You are now approaching the U.S. consulate in Istanbul. Any sudden movements and you will be shot without warning. all visitors welcome."

Many Information Technology departments in education do the Istanbul embassy equivalent, we make it so secure and strive for reliability and performance, that, we lose sight of what we are there in the first place. We spend so much time implementing projects to maximize compliance of external and internal regulations.  Do we resemble a maximum security prison, also?
It is as if we have our own analogous sign as described by Friedman:
"Attention! You are now approaching the IT Department. Yeah, we undersatnd you want us to add or change something to help differentiate your students learning, but our systems are working now, you'll only mess it all up. Thank you for your request."

Our values are backwards, it should be about education value first. We are not the only one's facing this dilemma. Software developers were frustrated by a similar issue, being constrained by having to use a development process borrowed from other industries, such as construction. It was a wrong fit, with different values, than what software development really needed. Software developers were unhappy and customers were unhappy as a result. So, a group got together to develop a new paradigm that actualized the values of what customers and software developers really needed. This was called the Agile Manifesto, and created a revolution is software development that improved success of software projects, empowered developers, and increased customer satisfaction with software products.

Information Technology Departments need a similar revolution. We need to discover our primary values and principles to add value to the core mission of educators. I propose we develop an Education Technology Manifesto, inspired by the Agile Manifesto.  I submit for your consideration, to gather education technology leaders and build our own, and reinvent ourselves, our departments, and our services. Here is my first shot at it, but these are just my immediate and rough thoughts just to get ideas rolling, for people to affirm, and for people to remove. Here we go:

We are innovating learning, building  and improving the student and educator experience by developing and implementing technology.

Innovate Learning over Business Best Practices

Student Centered over Administration Centered

Classroom over the Server Room

Differentation over Standardization

Learning Value over Compliance

That is, while there is value in the items on the right, we value the items on the let more.

So, what do you think?
Do you agree we need a change? A value realignment? Would you want to be one of the drafters and signatories of an Education Technology Manifesto?