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?