Montana Code School (MTCS) is a community project that has deliberately used philosophy, ideas, practices, and patterns from the Agile community to teach new programmers to code since it was founded in 2015. This experience report tells its story of how the local business and entrepreneurial community requested it during an agile meeting process, and how volunteers and non-profits got it launched with support from the University of Montana. MTCS teaches new programmers mostly through immersion in group projects with frequent community interaction that includes visits and presentations from developers and business leaders in the community, and demonstrations of student projects offered to the public. Scrum, TDD, and mob programming are some of the most powerful of the agile practices used in classes, though there are many more. As of spring 2017, MTCS has completed eight cohorts in two locations in Montana with two more cohorts in progress (both full time and part time).
1. INTRODUCTION
This author is honored to be a founder of Montana Code School and to tell this story. Our school is an ongoing effort to train new programmers in Montana through intensive immersive coding bootcamps. We explicitly bring in Agile principles and practices as part of the curricula design. The project began by demand from the local business community during a Lean Coffee™ event called 1 Million Cups [Cups]. Montana Code School is formally part of the non-profit business incubator, MonTEC. The school was born with ongoing support primarily from an entrepreneur resource within the University of Montana, the Blackstone Launchpad. My own early involvement in the Agile Software Development community helped ensure we did our best to integrate Agile from the beginning.
The story of Montana Code School is a compelling one for its low cost and our competitive placement and earning improvement statistics. The school has very supportive local business and programmer communities and an attractive location. Although I would love for this report to amplify the success of our small school, the focus of this report will be the ups and downs of starting a coding school using Agile. This report will demonstrate through our own teaching experience how applicable Agile is to education, and it will describe how my involvement in this project matured my understanding of the core essence of Agile and how it supported my independent Agile coaching practice.
2. Before The Beginning
There were numerous people and organizations that can claim part of the origin story of Montana Code School, including the University of Montana, MonTEC, the Blackstone Launchpad and especially its director, Paul Gladen. We were quite lucky to have broad community support. Many local businesses that needed programmers were willing to donate needed startup funds.
My own part in the story begins well before Montana Code School was even a thought, since my invitation to help only happened through donating time and effort in supporting the local software developer community. My first efforts were to start a Java Users Group in Missoula, Montana, which succeeded in holding a few meetings but it happened just before the dot com bubble burst in 2000 and after the burst of the bubble little interest remained.
Most of my success in advancing the software community came from founding and facilitating an annual Open Space Technology conference originally called Missoula BarCamp in 2007 and renamed to Montana Agile Culture House (MACH) in the spring 2014 where we became officially part of the Agile Open program of the Agile Alliance. The end of 2014 I was invited to facilitate the first Open Space unconference for the IT department of the University of Montana in Missoula which was convened in January 2015 and which began conversations for a second UM IT unconference for later in 2015. All of these efforts were a leverage point to bring in Agile concepts into the community, not just for software development as each of these efforts encouraged participation beyond software developers and IT departments. Given Agile says “Customer Collaboration before Contract Negotiation,” any Agile effort, even if it primarily is around software, needs to include the users of the software who aren’t programmers.
Distinct from my local efforts in Montana, I had been working remotely since I moved from the San Francisco Bay Area to Montana in 1998, primarily as a software developer and agile champion. Although I made progress in getting trained, certified, and sharing Agile both before and after a 2008 acquisition, my position was terminated in June of 2014. Rather than seek another position I chose to step out as an independent agile coach and consultant.
3. IN THE BEGINNING – SPRING & SUMMER 2015
Although Montana ranks near the bottom of both population and income statistics in the U.S., it may surprise you to learn that Montana has ranked number one for startup activity for four years in a row as of 2016 according to the Kauffman Index [Boze]. In May 2015 there was a “1 Million Cups” meeting, a mostly weekly community meeting for local businesses and entrepreneurs. The meeting departed from its normal format, which included short small business and entrepreneur presentations followed by questions and coaching from the rest of the attendees and instead used the Lean Coffee™ format. Lean Coffee allows for a democratic process of agenda generation and time boxing of topics based on majority interest.
The Lean Coffee was facilitated by a colleague, Nathan Stephens. Nathan and his wife Jennifer had been the most supportive community members for the development of the Open Space conferences mentioned earlier. Nathan’s exposure to Agile ideas at our conferences helped him choose Lean Coffee for the meeting. Nathan had also helped the Kaufmann foundation host several “Startup Weekend” events around Montana, two of which I played a role as an official mentor. “Startup Weekend” had encouraged many ideas from the Lean Startup movement.
Figure 1: Our 5/2015 Lean Coffee Event notification
This Lean Coffee meeting had about 20 people in attendance and although there were about 8 topics generated, the top voted topic was a programming school to provide more software people to local businesses. Each time the group voted whether to move on to the next topic, they kept voting to talk about a code school for Montana
Within two hours after the Lean Coffee we convened a followup meeting on the University of Montana campus in Missoula, at the entrepreneurship resource center for students and alumni, the Blackstone Launchpad. The followup meeting was the first of many weekly meetings that coordinated the production of a business plan, schedules, logos, and curricula. We found teachers and students, and we were able to successfully open our first cohort the end of September, only four months after conception. It was during these weekly meetings that I proposed we use Agile ideas as part of the delivery process as well as content in the curricula. They even adopted a kanban board for our “Value Stream Map”.
The Blackstone Launchpad was very familiar with Eric Reis’ The Lean Startup book and approach. Although Lean Startup and Agile may not be exactly the same, the use of this approach did make Agile easier for the Blackstone Launchpad to adopt Agile for the code school. Lean Startup means making business hypotheses and proving them with low cost experiments before scaling up. So rather than focus on endless planning and a detailed syllabus, we worked on proving the business hypothesis that there was sufficient demand for an $8000 twelve-week full stack web development bootcamp to pay for teachers, facilities, and any additional overhead on an ongoing basis in at least Missoula. And we planned to heavily discount the first students by one quarter to one half tuition based on grants and sponsorships. We would start small and validate through finding paying customers. Although we had enough community sponsorship to pay an instructor and rent facilities for a class of five, we aimed for ten, and started with twelve students.
There were two primary challenges for using Agile ideas to teach programming. The first was a limited understanding of Agile within the founding team, which put all the weight on me for developing the curricula in an Agile way. I was able to help move this forward a bit with some of the founding team by getting them to read Joy, Inc. The second and bigger challenge was that we had little experience teaching how to program with Agile. I had experience teaching Agile concepts to both programmers and non-programmers, but not to help non-programmers learn to program. Luckily, I was able to find some corroboration that this should be possible based on what eduScrum® reported they were able to accomplish in the Netherlands. I had also witnessed non-programmers pick up coding as part of Woody Zuill’s Mob Programming [Zuill]. But in many ways we would have to develop something from scratch and improve the process as we moved forward.
4. Prelaunch—Early September 2015
Up to a few weeks before we planned to launch Montana Code School in September 2015, we did not know for sure we would have enough paying students to have a successful class. Although the biggest worry was finding enough students, the mostly volunteer team also scrambled to step through some legal hurdles of who would be the controlling entity for the school, and to find a way to maintain a strong relationship with the University of Montana while keeping sufficient autonomy to be agile. And that gave just a little space for the two initial instructors, myself included, to develop the lesson plans.
Our other instructor had graduated from another coding bootcamp in San Francisco about a year earlier. He had had no programming experience before going through a coding bootcamp, but at the time we were launching he was working as a digital nomad making a living doing programming tasks from a laptop as he toured Europe. He had a little experience with teaching programming at his original bootcamp, but not as the lead. And he knew nothing about Agile. We were quite green. My plans were to only teach half-time to give space for developing my new independent Agile coaching and consulting practice, and the other instructor would be full time.
To help with the design of the class, we wanted to learn as much as we could from more established coding schools. Our founding team was able to find some contacts. Although there was some benefit in phone conferences, the best success I had in understanding how successful coding schools worked was a short visit to the Flatiron Code School in Manhattan. It is perhaps one of the best coding schools in the nation with 98% placement of students in programming jobs, with an average starting salary of $74k [Flat]. I went to an open house and saw impressive projects from students who had not yet finished a 3-month bootcamp. I also had an opportunity to chat with the instructors. After that visit it was clear to me that we could also succeed with a very flexible project based approach rather than an overly structured, lecture-oriented class. It might be interesting to note that according to my co-instructor, his San Francisco based coding bootcamp fired their initial instructor for lecturing too much.
Since we collectively and individually had little to no experience delivering bootcamp style classes built with Agile both for the content and the delivery process, it also seemed critical for us to practice teaching before we started our twelve-week class. So, we offered a two-day intensive coding bootcamp a few weeks before the launch of our main cohort. For the two-day class, we tried a very rapid scrum as used by Daniel Mezick in teaching Agile to the author David Logan’s consultancy team with one hour sprints [Logan]. The overall class plan for the two-day class was described in a backlog with three by three inch sticky notes written with markers, which were up on the wall with a todo/doing/done kanban approach. In addition we planned for 5-10 minute breaks each hour, with five-minute retrospectives that usually involved people reflecting on their class experience with each other. We also used some of the concepts from Diana Larsen and Ainsley Nies’s book, Liftoff [LaNi] as well as Sharon Bowman’s Training from the Back of the Room [Bowm]. From the book Liftoff we included a brief purpose exercise in the first ‘sprint’. From Training from the Back of the Room, we added connection exercises to help the students relate to each other and the content, delivered the concepts in fifteen minute or less segments, and gave all the students time to try out the ideas with concrete practice. As for how we tried to use Agile approaches to teaching coding itself, we encouraged the students to work in pairs on a single computer. Some were willing to try a mob programming approach while others stayed with a more traditional front of the room ‘code along’ approach which was less Agile, but which the other instructor knew how to teach.
This first experiment using Agile methods in a classroom setting was bumpy after we got past the basics, mostly due to our overestimating how much the students could digest. We had to slow down our original plans and trim back a simple React tutorial. Yet the difficulties helped prove the value of adopting an Agile approach and a flexible backlog. The short hourly retrospectives helped us refine and adjust our plans as we went. We wouldn’t need to have one-hour sprints for the full twelve-week bootcamp, but this experiment validated the general approach.
5. LAUNCHING – LATE SEPTEMBER – DECEMBER 2015
Most of the MTCS team focused on recruiting students, who continued to enroll right up to the last few days. In the mean time, my fellow instructor and I completed plans for the overall flow of the twelve weeks. But although we had a general plan, we were explicit about adapting to circumstances. We were also very explicit that the class was not a certification of employability. Their résumé would be what they produced during the class as well as the skills they would be able to demonstrate after completing the work.
On the first day after some longer Agile Liftoff processes we described Agile with the Agile Manifesto, placing a poster of the four values on the wall for the duration of the class. We also described Scrum with a simple poster. And we also encouraged a deeper understanding of responsibility with Dr. Christopher Avery’s Responsibility Process [Avery] (which I discovered at Agile conferences) to help them stay out of blame, justify, shame, and obligation.
Our classes were eight hours a day, five days a week during weekdays. Students were encouraged to spend about 90 minutes a day studying outside the class. Similar to how we used a kanban for the two-day bootcamp, we used a larger one for our first twelve-week coding camp. We kept the kanban tickets as a record of what we worked on each day. I took pictures after the last day of class and one of the students made a sad face that I was taking it down. It was a wonderful visualization of all the hard work for the twelve weeks.
Figure 2: Kanban Record of MTCS Cohort 1
We used a simple Scrum model with one-week sprints using a backlog with some large ticket plans and breaking those down into a deliberately incomplete weekly backlog, which would be adjusted each morning into a mostly complete daily backlog. This meant that most of our plans were generated just in time based on how things were going on a daily basis. On Fridays we would either have a “challenge” or “test” that helped individual students demonstrate their progress. And during projects the teams would demonstrate their apps. Then we closed the week off with about an hour long retrospective where the students could give feedback to themselves, the rest of the students, and to the instructors about how the content and the process of the class was working and look at where we might need to shift. We used a number of methods for the retrospectives, primarily involving sticky notes on segments on a wall. Students facilitated two of these sticky note style retrospectives. Several times after a hard week we just sat in a circle and talked. These retrospectives played a powerful role in helping us adjust the pace as needed and to see what experiments we tried were working and which didn’t. Students would also reliably validate our relationship and team based approach.
As for our daily flow, each eight-hour day generally started with the students, instructors, and guests in a circle doing a check-in followed by an improv game. The check-in came from Jim and Michele McCarthy’s Core Protocols [McCa]. The improv games came partially from my own training through Stanford and Bay Area Theater Sports, but the book Improv-ing Agile Teams [Godd] was a great resource.
Perhaps most important was our teaching philosophy. We had at least one external community member visit our cohort each week to present special topics around programming, personal branding, or just their own path into the software profession. Those who taught or mentored any programming topics were asked to read and agree to our teaching philosophy, which encouraged an interactive process of engaging rather than heavy lecture, with lots of hands on experience. We wanted to shift the way they looked at being an “instructor.” We repeatedly referred to our role of instructor as being a “sherpa.” Our job was to be a guide and do some of the heavy lifting. The journey was our students, and they really are the heroes. As instructors we’re just helpers.
The biggest challenges from the launch period were, similar to the two-day bootcamp, learning to pace ourselves. But encouraging a collegial spirit worked wonderfully well. Given the full day of work and a recommendation of about ninety minutes a day of practice after class, the intensity was also quite a challenge. It was important to teach our students about the psychology of flow and to help keep them out of the panic zone. But just preaching the value and science of staying out of the panic zone can not guarantee they will not panic. One student, our youngest, dropped out due to lack of confidence despite many hours of individual coaching and support. And this relates to our second biggest challenge. Given that we were not an established school, and given we were taking a nearly entirely new approach to teaching than any of the students were familiar with, students needed to trust us and the process. Granted, the students were already providing that trust with their non-refundable tuition and three months of their lives. Still, our first cohort had to rely on the confirming statistics of what other coding bootcamps could accomplish to assuage their doubts.
One interesting challenge was trying to bring Extreme Programming practices into the class. Teaching test driven development mostly failed for our first cohort. Describing TDD is straightforward. Our main method for exposing the students to TDD was through exercism.io [exer], which includes programming challenges specified by a series of unit tests. Although this benefited the class, we overestimated the capacity of most of the students to digest the concepts and we did not give them sufficient practice writing their own Unit Tests. Also, JavaScript for web development is usually so tightly tied to the user interface, and UI development is often not conducive to easily creating Unit Tests. During the first cohort, most of our focus the first four weeks was on teaching frameworks like Node, React, MongoDB, jQuery, and more. Since the first cohort we have had more success teaching with TDD, which will be described later in this experience report.
We intentionally invite students to own responsibility for their progress. In part we do this by avoiding grading or certification. But we also ask the students to pay attention to what works for them and their learning. We recommend that each student discover their best modalities, and to play with the balance between group and individual work. That said, we heavily encourage and rely on pair and mob programming.
For our first cohort when teaching pairing and mobbing we didn’t focus on the difference between the two. We taught Llewellyn Falco’s “strong pairing” method and encouraged the “driver” to follow direction from the “navigator” to help make the process of writing code visible so all members of the pair or mob can learn. We mostly encouraged triads and shifts in seating every day or so to mix up the teams. We encouraged regular shifts of the driver but did not attempt to enforce rotations with a timer. Mob Programming definitely seemed easier than pair programming, probably due to the increased safety of having more than just two people, like being chaperoned.
The adoption of pairing and mobbing was certainly not perfect especially in this first cohort. Resistance or simply habit would at times cause the driver to speed ahead and leave out the rest of the team. But despite imperfect adoption, students did most of their work during class hours in pairs or triads and regularly reported the value of this approach to learning. More advanced students were able to deepen their understanding by supporting the less advanced students. And the students in general benefited from explanations from other students who were closer to them in newness to the material. Often students could be better teachers than the formal instructors. And of course, pairing and mobbing requires kindness, consideration, and respect in the team to work well. Practice working in groups helped make their later project teamwork successful.
Pairing and mobbing amplified our own teaching efforts by enabling situational lessons to be more easily spread. At least two would get any particular coaching. What was successfully resolved for one group could be more easily scaled to any other teams that had the same issue. It was especially rewarding to see how natural it was for teams to learn and work in mobs. It organically brings out natural tendencies for collaboration without much formal instruction. It helped us both leverage and grow the students emotional intelligence.
That said, mobbing and pairing also brought out challenges. Even though we used Pair Programming formally as part of the interview process for most of the students before they were accepted into our program, for some it is a hard mindset shift from a focus on individual performance and individual grades as you see in a traditional school or workplace. Both pairing and mobbing make very transparent any issues in the students understanding. They even reveal facility with the keyboard and editor. Despite a strong focus on building trust and safety in our class, insecurity could cause students to withdraw and slower students could bring out impatience in the faster ones. It can be awkward. Yet overcoming these challenges of radical transparency went along with taking weeks instead of years to master programming, a subject many consider only the realm of freaky smart nerds. All these challenges were an important part of the process that helped the students succeed in the long run. We frequently encouraged students to “get comfortable being uncomfortable.”
Figure 3: Illustration 1: Open Space “Marketplace” for Project Generation
We had two rounds of projects, each three weeks long. A critical factor to the success of the class was to move into projects as quickly as possible, and to let the students own their project ideas. I had participated in the “Startup Weekend” events described at the beginning of this report and enjoyed the self-organizing process of pitching project ideas before allowing teams to work out their own membership. When I facilitated the project generation process for the March 2015 “Rural Medicine Hackathon” we used a 90 minute Open Space. It was hugely successful and I suspected it should work for our projects as well.
Figure 4: Cohort 1 Preparing for Final Open House Demos
We used an hour-long Open Space Technology process to help the teams think about the projects they wanted to pitch to the rest of the students. They all reported being very energized and excited after this short Open Space. Then any student could “pitch” any project idea for up to one minute. These ideas were almost always a subset of those explored during the Open Space. Those who pitched then went to different parts of the room and the rest of the class moved around until they settled on four teams with three triads and one pair. This self-organizing process was very effective and led to surprisingly great project ideas and eventual demonstrations. Our first round of projects went from weeks five through seven. For the second round of projects, from weeks ten through to the end we duplicated the project generation process except we assigned team members after receiving first and second team choices from each student. It definitely went smoother letting the students build their own teams, and that is how we have proceeded since the first cohort.
During the projects, we added the three Scrum questions to the check-ins as part of the Daily Stand Up. We would do a demo on Fridays before the weekly retrospective. On the final week, we hosted an Open House to demonstrate each team’s work to the public. Friends and family would show up but most importantly we always had prospective employers from the local business community, and a few prospective students. All were amazed and impressed at the quality of what the students were able to produce in a short period. You can see our statistics on the Montana Code School website. And yes, nearly all our first cohort found jobs in Montana within a few months.
6. SECOND COHORT – FEBRUARY – APRIL 2016
The second cohort we had a few more students and a lot more experience to draw on. It went much more smoothly, and we followed largely the same process we did with the first coding boot camp with a few adjustments. Firstly, we spent a little more time with formal one-on-one conversations with the students. Such an intensive and challenging learning period with so much at stake for the students can be stressful. The daily check-ins and improv games went far to keep the students in communication with us and with each other, but a bit more one on one time was important to stay in touch with their individual needs.
We also did much more drilling in the basics of coding. We spent more time with the unit test driven exercises in exercism.io, and we created our own. I ran a more formal Mob Programming exercise with rotating triads and timed driver/navigator rotations.
During our second cohort, one of the students shared a book, A Mind for Numbers [Oakl] by Barbara Oakley, which continues to influence both my thinking about coaching Agile teams as well as teaching programming. The book speaks of the psychology phenomenon of Einstellung where we can get stuck on a certain way of thinking where trying harder only enforces our active neuronal patterns. Additional mental resources or helpful perspectives hidden in peripheral circuits in the brain can only come to the foreground when we relax our focus. Einstellung was very evident when students struggled. Having science to encourage students to take appropriate breaks or to shift gears helped us better support them. Oakley’s book also supports chunking mastery lessons for math and science because only by understanding one level, can the next make any sense. It’s easy to get the illusion of mastery after watching a video or running through a tutorial. Oakley’s chapter on teamwork shows another way mob programming prevents these mastery illusions. Dispelling such illusions can at times be unpleasant for students. But getting an accurate picture of their own level of understanding is necessary for real learning to take place.
I have been active in the Agile community, especially in Open Space events. One beneficial influence was getting to practice Augusto Boal’s “Forum Theater” at the February 2016 Agile Open San Diego. It’s a process where non-actors in a village solve problems by acting them out multiple times trying different experiments. Since the students so loved the improv part of the class, we were able to add a half-day workshop taught by University of Montana theater professor Jillian Campana [Camp] who had studied extensively with Augusto Boal. After several warmup exercises, students made skits that they could repeat to try things out. There were three skits, all focused on job interviews. This was fun and effective. Professor Campana subsequently went on sabbatical in Egypt, but we did get to try Forum Theater a second time with a teacher from a private school, which was fun but not as well received.
7. CHANGING AND EXPANDING – MAY 2016 – PRESENT
Towards the end of the second cohort, it started becoming clear that there were going to be some shifts in the Montana Code School administration. We lost our full time instructor and some of the administration team at the same time we were also expanding our teaching to be in both Missoula and in Bozeman, Montana. We had found a teacher for Bozeman, but now we had to scramble to find a replacement teacher for Missoula. Luckily, we found a senior software developer with significant exposure to TDD, pair programming, and other Agile practices. He had also been a dance instructor around the world and was able to transfer his teaching experience to our code boot camp.
It was challenging to be facing personnel issues while also managing two cohorts simultaneously that are three hours driving distance apart. The shifts taught that life is about change and an Agile mindset certainly helps with adapting to change. Doubling down on the “Individuals and Interactions” is the best way to prepare for change. During our third cohort, we started having weekly instructor meetings to maintain the necessary alignment. This weekly meeting is ongoing.
We’ve been successful making expenses match income and maintaining our placement statistics during the expansion process. We’ve now graduated five more cohorts since the first three, making our total eight. A part time cohort started in March of 2017 for those who don’t want to quit their jobs for a full-time class. A full-time summer cohort started in May 2017 that is offering free housing for the first time. And we already have applicants for cohorts for the fall in both Missoula and Bozeman.
Earlier in this report I shared some of the issues with teaching TDD, Mobbing, Pairing, and Improv. It might help to give a bit of background about what we’ve tried and learned, and what still needs more experiments. Nathan Smith in the third cohort was much bolder in teaching TDD, and we spent more time solving problems and encouraging the students to write their own unit tests in a single mob. I had also taken a Woody Zuill Mob Programming workshop for the first time at the Utah Pluralsight location, and I led a workshop to more formally practice the use of the timer, and a single navigator to help teach the more advanced students the value of silence and patience even when they “know” the answer. I delivered a Mob Programming workshop to the simultaneous Bozeman cohort. All of this more structured and deliberate practice helped the students get better at programming in general, not just mobbing.
Figure 5: Montana Code School “Mobbing”
I was also fortunate to team up with Woody Zuill the summer of 2016 to deliver a 2-day boot camp built around Mob Programming. It worked amazingly well. One of the students enrolled in our full time class, became a teacher’s assistant for Montana Code School for the Spring 2017 cohort, and now is a full time programmer for a Bozeman software company. We used quite a bit of mobbing to teach the Spring 2017 cohort in Bozeman. The students were more than happy to follow the process with the timer during about four distinct one hour programming kata challenges, though none of them used the timer for their projects. A few of the students longed to use the formal timer rotation, but they were too small a minority to sway their teams.
The Missoula Spring 2017 cohort successfully demoed their first round of projects, but “failed” to have a sustainable pace the final week. When inspecting this failure during a retrospective they were able to embrace a bold experiment for the second round of projects that included collective ownership, “Promiscuous Pairing”, and Test Driven Development with automated unit tests. All our teams produce great projects, but this specific demo day was quite astounding, delivering a multiplatform application with a server, a web app and mobile (both iOS and Android) with a Scheme Lisp compiler “side project” that they all collectively built.
MTCS graduates have become significant champions for our bootcamp. When a company comes to talk about what they do during classes, which happens about once a week, usually they come with a former student that now has a job at that company. The former students are attending and even leading local community programmer events. And our students are usually the teaching assistants since the first two cohorts. One of them, Lauren Nichols, once a manager at a local tavern, helped bring the improv, check-in, retrospectives, as well as ReactJS to the first Bozeman cohort as a teaching assistant in 2016. Now she is a happy full time developer at a Missoula software company. And our current Executive Director, Amrita Greer, was one of my students in the second Missoula cohort.
8. LEARNING ABOUT EDUCATION AND AGILE
The Agile mindset is very applicable to education in general. The front of the room focus of traditional education needs to change. One of our students wondered aloud why all education couldn’t be this way, and given the success of coding bootcamps around the country this seems to be a good question to ask.
What Agile can offer education isn’t necessarily Scrum, Kanban, eXtreme Programming, Mob Programming, or any particular framework. Yes, we benefited from all of them. But what helps most is the elusive “Agile Mindset” in partnership with an ever learning and adaptive Agile community that remembers its values.
Agile is a learning community that keeps learning. Much of what I’ve been able to do to help Montana Code School compete with schools in larger cities has been to apply what I keep learning from attending the big Agile conferences, the Agile Open conferences, Agile Coach Camps, and more. And one thing I love about our learning community is we import learning from wherever we can. This understanding about Agility itself has been extraordinarily beneficial in helping my clients. It’s the community, silly.
The greatest competitive advantage that students can have is not being stuck in a Fixed Mindset (Dweck), but adopting a Growth Mindset. That means that they feel confident they can keep learning. Even though skills are important, knowing they can keep progressing by continuing to learn themselves, especially in a community, makes all the difference.
9. Acknowledgements
Many thanks go to everyone involved in starting the Montana Code School. It took a lot of time, energy, and courage, but we made it! Thanks especially to the original founder, director of the University’s Montana Code School, Paul Gladen, who led us from idea to execution. Thanks to my fellow instructors, Doug Odegaard, Doug Walter, Nathan Smith, Nick Marrucci, Austin Slominski, and all the helpers and mentors, and especially to all the courageous students who went through the program. And thanks to Rebecca Wirfs-Brock for her support and encouragement as my report shepherd.
REFERENCES
[Boze] http://www.bozemandailychronicle.com/news/economy/montana-ranked-first-in-startups-for-fourth-straight-year/article_a01f0e11-4fc8-5e76-bb1e-59e38c151cd6.html
[Cups] http://www.1millioncups.com/
[Zuill] Zuill, Woody, “Mob Programming – A Whole Team Approach” Agile 2014 Conference, Orlando, Florida
https://www.agilealliance.org/wp-content/uploads/2015/12/ExperienceReport.2014.Zuill_.pdf
[Flat] https://flatironschool.com/about-us/
[Logan] Logan, David, “Make Your Meetings Hyperproductive and Fun” http://www.cbsnews.com/news/make-your-meetings-hyper-productive-and-fun/
[LaNi] Larsen, Diana and Nies, Ainsley, Liftoff, Second Edition, Start and Sustain Successful Agile Teams, The Pragmatic Bookshelf, 2016.
[Bowm] Bownam, Sharon. Training from the Back of the Room, Pfieffer, 2008. ISBN: 978-0787996628
[Avery] Avery, Christopher, “The Responsibility Process” https://www.christopheravery.com/responsibility-process
[McCa] McCarthy, John and Michele, The Core Protocols, http://www.mccarthyshow.com/online/
[Godd] Goddard, Paul. Improv-ing Agile Teams: Using Constraints to Unlock Creativity, Agilify, 2015. ISBN: 0993301304
[exer] http://exercism.io/
[Oakl] Oakley, Barbara, A Mind for Numbers: How to Excel at Math and Science (Even If You Flunked Algebra), TarcherPerigee, 2014.
[Camp] Campana, Jill. http://www.umt.edu/umarts/theatredance/Contact/faculty-staff.php?ID=2925
Author’s address: Harold Shinsato, PO Box 66, Stevensville, MT 59870; email: harold@shinsato.
Copyright 2017 is held by the author.
