Experience Report: Agile Development Apprenticeship at NMHU

Introduction

In the beginning was the idea - a community dedicated to mastery of the software development art, sharing the vision: "software by people for people."

Just as a snowflake requires a nucleus to spur the formation of its intricate crystal structure - a catalyst was required to spur the formation of the desired community. Education (and re-education) is a fundamental need for a new community and there is a long history of schools - from the Greek academy to the Tibetan gompa- being the focal point of extended communities.

The nucleus for our idea was a new degree program at a small (3,000 students) public university - New Mexico Highlands University in Las Vegas, New Mexico. The program was radical in almost every way, beginning with our core values as expressed in our logo.

The program logo (shown below) captured the fundamental concept that software development was a disciplined art dedicated to reality construction¹, using software as a platform, practiced by human-centric teams of diverse, passionate people bonded by their shared efforts. The premise was that if healthy relationships could be maintained among the concerns listed on the edges, teams would exhibit software development superiority, leading to the central promise of the program - development teams capable of delivering 10 times as well as their average counterparts.

Why tell the story now, two years later? Because computer science educators and society in general need to hear what can be accomplished when people set their hearts and sights on a higher plane. When students are inspired to choose mastery as opposed to satisficing and given the tools to realize their goals, their common struggles act as bonds that build the very community that leads them to overcome the adversity inherent in such an endeavor. Even non-academics can benefit from some of these lessons since, in the end, both educational institutions and software development organizations constitute value shops² - both provide problem-solving services that require customization for each client’s unique situation, whether it’s a learner pursuing increased knowledge or a customer pursuing improved performance.

Come into our apprentice shop - the door to our reception room is open. Scheduled spikes, reading group meetings, and visiting luminaries are posted on the door. Note the microwave oven to the left and the monitor to the right of the door. Passersby could stop to watch a looping PowerPoint presentation of our latest adventures and upcoming events, even when the apprentice shop was empty.

Our Program

The groundbreaking New Mexico Highlands University Software Development Apprenticeship (SDA) program was situated in Las Vegas, NM, a small town of 15,000 people at 6,500 feet above sea level at the edge of the rugged Sangre de Cristo Mountains. The mountains provided visual metaphors for the almost insurmountable obstacles facing the program, the rewards that come from reaching the peak, and the beauty inherent in the people that chose to join in the climb.

The prevailing cultures in northern New Mexico, stressing familial obligation, coupled with extensive regional poverty forced these students to confront life-work balance issues at a much younger age than many of us. One result: students ready to make a difference in their own lives and the lives of those in the community. These students also understood the concept of a family and a community at a deep level allowing them to recognize the potential benefit accruing from becoming a member of the community we were establishing. Their willingness to pursue a sense of shared identity was a powerful resource for us as we began the arduous task of building a community centered on the SDA ideals. The official definitions of those ideals, displayed in the logo and captured in the SDA handbook, were:

X*10 (mean times ten), referring to the well known fact that some developers are ten time better than average - our goal for all our graduates

• People - reminder that our goal is to serve people and that developers must be respected as people
• Systems - we enhance business and social systems, not simply produce artifacts.
• Agility - we are interested in results not formalisms
• Craft - we recognize the development is an art form not a production process
• Software - the medium in which we practice our art

We wrestled with defining competencies that respected standards advocated by external bodies like ACM and IEEE³ , while remaining true to our own convictions. We accepted the association competencies as an important subset of the total. To that subset we added dozens of competences in several areas that transcended those associated with technology and practice - ignoring the fact that we were setting expectations for our students that far exceeded any other academic program in the world. Essentially we were expecting our students to complete six years of education, much of it at a level typically reserved for graduate students, while acquiring significant experience in real world development all in the four years set aside to obtain a bachelor degree at a typical university. Mapping our expectations with all of their cross-disciplinary and curriculum-independent lessons into a typical college program almost proved the undoing of the program before it began. Everything we did required a variance of one type or another, from allowing multiple courses to be scheduled at the same time in the same room taught by multiple faculty to the physical space requirements; but the attitudes we hoped to instill would only emerge from applying non-traditional pedagogical patterns emphasizing responsibility, feedback, collaboration, and the invention of new ways to look at a problem.⁴

To that collection of proven pedagogical patterns, we added a few ideas of our own consistent with systems thinking⁵ and authentic leadership⁶, in support of our goal to minimize the gap between what we believe the world should be like and what it actually is like. A great deal of planning went into defining the environment in which our apprentices would work. Although the white boards, rounded tables, rolling chairs, painting, and wiring arrived late, it was all designed to foster collaboration, as the following picture suggests:

Our Apprenticeship Model

Our first efforts revolved around establishing an identity for our program - our apprentices wore logos on shirts with colors indicative of their progress through the program and were paid to work on commercial software projects accordingly. This is the structure we used:

• Novice Software Developer
• signified by a tan shirt
• starting point for all apprentices
• earnings - $xxx/hour on subsidized projects
• primary goal is exposure to industry vocabulary and tools, as well as enculturation
• Apprentice Software Developer
• signified by a forest green shirt
• achieved after 75 competencies (or equivalent) are demonstrated
• earnings - $xxx+2/hour on commercial projects
• primary goal is supervised application and further development of fundamental skills
• Senior Apprentice Software Developer
• signified by a sunrise purple shirt
• achieved after 150 competencies (or equivalent) are demonstrated
• earnings - $xxx+4/hour on commercial projects
• primary goal is independent application and further development of advanced skills
• Supervising Apprentice Software Developer
• signified by a sky blue shirt
• achieved after 225 competencies (or equivalent) are demonstrated
• earnings - $xxx+6/hour on commercial projects
• primary goal is leadership development and integration with external software development organizations

A competency as referenced here means demonstration of level iii capability, where the levels of achievement were defined as:

1. Concepts and vocabulary ("book learning");
2. Application of knowledge under supervision and direction (analogous to laboratory work in a science curriculum);
3. Independent application (analogous to field work, case studies, etc. in other disciplines);
4. Application in novel situations (analogous to internships);
5. Ability to mentor and direct others in the subject area;
6. Ability to create materials and tools (curricula) that can be used by others to teach the competency area; and,
7. Ability to make an original contribution to the discipline in the area addressed by the competency (invent a new tool, algorithm, idea, concept, etc. (demonstrated with presentations to professional conferences/journals).

Because students could register for anywhere from three to fifteen credit hours each semester on their way to fulfilling the 64 credit graduation requirement, we had to allow for individualized progress through the program. To accomplish this, we invented the concept of competency-levels, where each semester credit hour corresponded to 15 competency levels. The goal for one semester credit could be achieved by mastering 3 competencies to level 5, 5 competencies to level 3, 15 competencies to level 1 or any combination in between.

Students were expected to create an Individual Education Plan (IEP) indicating which set of competencies they planned to achieve in the current interval (usually 8 weeks, or two intervals per academic semester). The main constraint was that the competencies included in the IEP had to reflect⁷ knowledge and skills relevant to the client project to which they were assigned.

The curriculum, as a result, was not predefined. Faculty had to prepare and deliver educational modules in response to the collective IEP’s of the students instead of pre-defining a syllabus. When the IEPs require curricular modules outside the expertise of the faculty, outside masters (world famous professionals) came to campus to work with the students.

Diverse clients were solicited to provide work for the apprenticeship portion of the program but there was no guarantee that the needs of customers would be sufficient to cover the entire spectrum of competencies defined. To supplement customer projects, we would applied for grants that would allow us to define our own internal projects to cover any gaps occurring because of the current customer mix or because the competency area was not a "hot topic" in the commercial world, e.g. artificial intelligence, non-standard languages like Squeak/Smalltalk, and experience with embedded software that was of little interest to our initial customer base.

Given the fact that competencies were derived from vastly diverse categories, as indicated by the following table, students were never at a loss for selecting topics for their Individual Education Plans (IEPs):

Our Tools

Instead of standard textbooks we relied on, and required students to acquire over time, a multi-disciplinary "professional library" comprising books from a wide variety of perspectives. A short sample of our first semester booklist included:

• Code Complete (2nd Edition) by Steve McConnell
• Object Thinking by David West
• Agile Software Development with Scrum by Ken Schwaber and Mike Beedle
• The Non-Designer’s Design Book (2nd Edition) by Robin Williams
• Java Modeling in Color with UML by Peter Coad, Eric Lefebvre & Jeff DeLuca
• Extreme Programming Explained: Embrace Change (2nd Edition) by Kent Beck
• The Mythical Man-Month by Frederick P. Brooks, Jr.
• Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
• Analysis Patterns : Reusable Object Models by Martin Fowler
• Writing Effective Use Cases by Alistair Cockburn
• Agile Software Development by Alistair Cockburn
• Systems Thinking by Jerry Weinberg
• The Psychology of Programmers by Jerry Weinberg
• The patterns literature written and edited by Linda Rising

Some (like the The Mythical Man-Month) were recommended as classics, while others (like Agile Software Development with Scrum) were recommended because the program required application of the content. (Scrum was our project management approach for both academics and projects - competencies as Product Backlog and IEPs as sprint backlogs with retrospectives for continuous progress). Still others (like Java Modeling in Color with UML) were recommended because we felt they offered a glimpse into how creativity could be applied to industry standards to generate more useful tools - in this case, the use of color to identify archetypal patterns and broken or anti-patterns.

The non-SDA courses required for a Bachelor’s Degree included:

• The standard core curriculum of liberal arts courses
• Electives where the SDA strongly recommended specific choices, e.g. Technical Writing to fill an English elective and Anthropological Research Methods to fill a social-science elective.
• Courses defined by SDA but taught by other departments, e.g. Postmodern and Hermeneutic philosophy.

By encouraging students to do their studying for all courses in the SDA facility, we hoped to continually reintroduce inter-disciplinary ideas into everyday conversations. Our weekly reading groups provided another venue for discussing multi-disciplinary ideas. On Wednesday afternoons or evenings, we met to discuss books on exciting periods in software development history (like Dealers of Lightning or The Dream Machine) that were required for the program, websites on influential figures like Ted Nelson and Jason Lanier, personality profilers like Meyers-Briggs Type Index (everyone took the test), and essays by people like Alan Kay ("The Early History of Smalltalk"). Sometimes, meetings were held in the coffee shop, sometimes in the lab, sometimes during the day, sometimes over dinnertime (because of the need to accommodate student course and sports commitments outside the program).

Our Community

Twice each semester, we held an investiture, a ceremony to present students who had achieved a new status with their shirts and business cards showing their new level, as well as to signify everyone’s renewed commitment to our Code of Conduct by their signatures. The pictures below do not show students because of university policy, but do provide a glimpse into the investiture ceremony.

Alongside investitures, everyone’s favorite events involved program outsiders coming in for anywhere from three days to a week to share their specialized knowledge. Some outsiders are well known in the industry - people like

• Linda Rising, who taught retrospectives and writers’ workshops both by example and in theory
• Ron Jeffries, who not only taught Extreme Programming practices using both Java and Squeak, but who introduced techniques for healing dysfunctional teams in the middle of a 24-inch snowstorm
• Charlie Poole, who reinforced TDD concepts by introducing FIT (the Framework for Integration Testing) an acceptance testing tool, and pair programming alongside students developing client software

Others were better known at the local level as respected practitioners in Minnesota - people like

• Dion Stewart, who helped set up programming and server environments at the onset of the program
• Jeff Goodman, our most exuberant cheerleader, who encouraged students to appreciate the experiential education they were getting and threw a little Access database design in for good measure

The benefits extended beyond our classroom to our customers - a New Mexico state government agency, a local non-profit mini-conglomerate, and one of the school districts in the city of Las Vegas, NM. The Office of the State Engineer was able to send several of its development staff along with our client manager to participate in the sessions provided by the luminaries. This led directly to the implementation of Scrum and TDD in state offices as a means of delivering functionality on regular cycles to a customer base weary of long periods between releases.

Our Daily Academic and Project Life

Between major events, we concerned ourselves with the running of the apprentice shop, starting off every week with a planning meeting where we introduced the curriculum for the week and the teams (run by student scrum masters) met to discuss their client commitments, and ending every week with a retrospective - emphasizing appreciations, opportunities for program or team improvement, and experiments to be tried for the next week.

Daily team meetings sometimes happened asynchronously because of student schedules, but someone from the team was always available to answer questions about project status and what was needed next. Our eWaters team had a scheduled stand-up meeting every day at 12:30, but since people could rarely make it, the white board became a primary source of information. The photo below shows the backlog for setting up the development center - installing BEA WebLogic and Informix, ensuring the build scripts would run in Eclipse, and configuring the server to access the database. Above the tasks are the scheduled work sessions with individual students, along with the URL to our program wiki, where students were to log their daily journal entries (always advocated, never quite achieved).

Academic spikes (our term for class sessions) addressed mastery of content required for application in projects that week - usually delivered at least twice because of the need for accommodating student schedules. The white board above shows a typical week’s spike covering Java applets and applications, writing data to files and then to databases, to illustrate how applications can be implemented iteratively and incrementally. These spikes were highly experiential, often involving two or more students sitting side-by-side. We found that exploratory lessons that were not highly structured worked best with two students at separate workstations sharing ideas and screens until they came upon something that looked like it would fit their needs. Structured activities or actual work sessions, on the other hand, were often best accomplished in pairs, particularly if one of the members was more at least slightly more experienced than the other. In our experience, encouraging students to pair with different people is imperative; otherwise, one student may always be doing the driving, while the other becomes more passive. This was especially noticeable in our environment (though not always true) when one member was a male and the other was a less experienced female.

Pairing was not limited to students, however, as faculty pair-taught the academic spikes, demonstrating the kinds of interactions we expected between the apprentices as they worked - pointed, but not destructive, critiques of what was being communicated; appreciation for novel ways of interacting with students and ideas; intense engagement with the here and now as it transpired, often using humor to soften the blow.

Pairing with customers proved to be the most difficult problem of all (except for pairing with university administrators). The most successful engagement involved maintaining PCs in the computer labs of the local school district because the tasks were discrete, could be executed in parallel by groups at multiple schools simultaneously, and were both well defined and within the capabilities of all apprentices. Nearly as successful was the project to upgrade the JSP code for the Office of the State Engineer, located in Santa Fe, 60 miles away. Once again, each task was discrete, achievable, could be accomplished either synchronously or asynchronously. One of the advantages of this project was that the apprentice shop reproduced the customer’s development environment, so all of us were involved in installing application server software, configuring connection pools, executing version control, building and deploying code with ANT scripts of significant complexity, and clarifying requirements.

Our third project required SDA to deliver a complete financial and marketing package to a non-profit mini-conglomerate, designed to provide employment and services for a wide spectrum of the local population, over a three-year period. This project featured "greenfield" development of an enterprise resource management program to handle order management, inventory management, a web site, and accounting functionality. Its members met at 5:00 p.m. daily to discuss their progress and estimate the time required for finishing the remaining tasks. This project occupied a very committed team for almost the entire year, and at least one piece is still operational. It proved to be the most complex for a variety of reasons - lack of customer availability, conceptual difficulties for novice developers, intra-team tensions, and the same serious technical decisions about platform, process, roles, and responsibilities that any commercial development organization would face. The members of that team, however, gained invaluable experiences in project management, social interaction, governance, and customer relations that could never have been reproduced in the absence of a "real" team project for "real" customers.

Learning from our Learning

All of these daily experiences became grist for the weekly retrospectives, held each Friday in our team room designated for small or intimate gatherings, to evaluate what we had learned - what we shouldn’t forget, what we wished we could forget, and what we should do differently the next week. Generally, retrospectives followed demonstrations of the week’s work and an hour-long shared lunch - sometimes pizza, sometimes a giant Subway sandwich, and sometimes a potluck feast featuring homemade chili with corn chips. Occasionally, students brought their young children for this part of the day. Priming the relationship pump this way encouraged honest discussion when retrospective time came. On cue, some people would rush in to grab the softest seats on the couch (left of the door below), while one of our talented musicians might be sitting in the far corner picking away at the classical guitar we kept there for just this purpose - mood music for retrospectives!

Each weekly retrospective had its own character - initially, they were very focused on logistics (since the program had started with no set class times, no furniture, no computers set up, and no defined communication channels). There was too much uncertainty for some students, so they dropped the program and enrolled in more traditional programs. Those who stayed steadily improved their ability to analyze, articulate, strategize, and apply solutions for the problems discussed in the weekly retrospectives. Tools like the timeline on the living wall shown below kept emotions and reactions from being neglected at the weekly retrospectives.

Comments such as "Well, we know that Wednesday’s academic spike was a waste [because we had evaluated it immediately], so there’s no point in going there again" give a taste of the candid nature of the feedback, which was complemented by genuine appreciation expressed in actions and words to each other, the faculty, and visitors involved that week. Faculty from other departments visiting the apprentice shop when both instructors were absent were astounded that the apprentices would hold their own retrospectives and make suggestions for the following week without being physically led through the exercise by their instructors or graduate assistants.

Results

These opportunities for leadership, combined with the lessons learned through readings, coursework, and project work, directly contributed to the employment of several apprentices. One is currently managing the international effort to decentralize a bank in Australia (admittedly, she had a lot of previous experience, but she credits SDA with giving her the tools - especially Scrum and use cases - and confidence to undertake such a challenging adventure). Both of our development customers hired SDA apprentices to continue the work started in our program. Several apprentices already had part-time jobs while they were in the program, and they continue to apply the lessons learned about management, social interaction, and technology.

One of the apprentices has since moved to Minnesota to take a job applying the testing skills he developed in New Mexico - he will be helping other Minnesotans learn how to use FIT, a skill he developed working for the Office of the State Engineer under the tutelage of Charlie Poole. Another transferred to a Canadian university nearer his home to complete his M.B.A. and capitalize on his extensive knowledge of keeping machines up and running under all kinds of circumstances. The poster children for our program were a young man and woman who started the program not knowing how to cut and paste using Microsoft Word, but left the program capable of developing web pages, applying CSS, writing JSP code, and rudimentary Java code. Other results were not so positive. One graduate assistant had to be removed because of irreconcilable differences. The program itself was canceled by then NMHU president, Manny Aragon, who has since been dismissed from the University. Most of the apprentices have dispersed, but a core group of six continues to work on projects with customers while waiting for the program to be re-started at another college in Santa Fe. The others continue to maintain close relationships with people from the program and will likely rejoin us once we are are again underway. (We expect to have the program operating again as early as spring, 2007.)

Significance

At OOPSLA 2005, several principals of the pedagogical patterns community met with us to discuss how their existing patterns lined up with the patterns we had applied and which patterns required for the successful implementation of an apprenticeship program might still be missing.

The resulting pattern distribution seemed to cluster around three dimensions - Community Interaction, Social Interaction, and Learning - as shown in the diagrams that follow (blue nodes have not been written up as patterns, while pink nodes exist, and hexagonal nodes are pattern languages rather than single patterns.

Apprenticeship Patterns - Community Development

Apprenticeship Patterns - Social Interaction

Apprenticeship Patterns - Learning

Subsequent studies in systems thinking⁸ seem to substantiate our belief that these three dimensions are common to all social systems and that a fourth dimension our workshop virtually ignored was the external interface to the stakeholders that constituted our marketplace; e.g., potential students, university administrators, community leaders, and even potential customers (existing customers were included in our community). Although it is unlikely that paying more attention to this dimension alone could have saved our program, it does suggest that future programs ignore it at their peril.

In the time since the apprenticeship program was cancelled, we have pursued systems thinking as a way to generalize the patterns we discovered and have found that most, if not all, of them do apply to teams, departments, and organizations that have a desire to improve their current capability level. Our findings have been documented in a tool called autochthony, but that’s a story in its own right.

At the same conference our students delivered a unique presentation that was part theatre and part panel discussion as part of the Educator’s Forum. The audience was alternately appalled by the radical changes we had made (not at our acting skills), envious that we had gotten away with it, and admiring of our success as evidenced in the knowledge and abilities of the students.

We have garnered significant interest, and support, from the Agile Alliance, both because we emphasized agile principles in the program and because we successfully applied agile principles to redefine the educational process. An avid interest in joining a re-instituted program in Santa Fe as faculty, visiting mentors, and/or students was pervasive among attendees at Agile2006 in Minneapolis last month - when the re-initiation of the program was just a conversation piece at social gatherings.