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!