Agile teaching thoughts

I come back from an event organized by Institut Agile (Paris). It was a first workshop on what could be done to leverage Agile learning in initial formation. First, we have shared visions in the afternoon (think big, too big some would say ;)), and we had not enough time to talk in detail about action plan (act small).
I have to say that I appreciate that type of event, mostly for point of views diversity, which leads to lots of exchanges.

Then in the evening, we had some experience feedback from Claude Aubry, Jean-Luc Lambert, Frédéric Dufau-Joël and Alexandre Boutin. Lots of interesting feedbacks, I keep in mind :

• Avoid lecture, prefer interactive course, use lots of games (role playing)
• In France, we have the challenge to change student mindset, which has been inculcated in until they get to (under-)graduate level. They have been too much protected and now they are not enough autonomous, confident and too naïve about reality and scared by errors, they need to be given sense of responsability and to let them do errors without reprimands
• Avoid compartmentalized course, integrate them to make a coherent whole teaching project
• Take care (avoid) of individual grading, encourage team collaboration and so team grading
• Give real projects to lead using learned techniques

My current vision of Agile teaching

From our discussion, I would summarize the vision to adopt through answers to the following questions (it is my point of view, not necessarily shared with every members of the community) :

• Why do we need to teach Agile ? To share Agile spirit that promotes fun, motivation, responsability, commitment, questionning..much more than techniques, it is a mindset. In the end, it would result for sure in a world with much more common sense than the one we live in.
• Where do we like to go ? We need to influence public authorities, teaching program management through "lobbying" and why not leverage fundamental research in this field (even if I think it is partially covered with several human sciences and computer science researches)
• What is the content to teach ? We have to build sort of referential of Agile practices and techniques and requirements to be able to understand Agile.
• How do we teach Agile ? We need to share teaching practices, to make more and more experience feedback (in fact, to apply Agile principle to our approach...).
• Who is targeted ? Every student that could be involved in an IT project given its initial formation, from the "classic" software engineers to management/commercial profiles (and even any student if we want to spread only the Why...).

Things I would like to dig

First, I would like to start teaching Agile with small courses. But then, I think it would be great to build incrementally a teaching project around following axes:

• Around technical, behavioral and methodological integrated/related courses,
• With lots of practice and games rather than lecture,
• The whole applied through real projects that are needed by their customers (not fake ones)
• With implication of professionals strongly related to teaching staff (ex: close relationship between almuni and teaching staff)

Now it is time for action. And I will continue to participate to this new community for sure. Thanks to all participants, I enjoy this moment.

Specialization in Agile (part 1) : other visions than hyperspecialization

I would like to write a post on this subject for a while (amongst lots of other…), and a post of Mike Cohn about Agile in the Age of Hyperspecialization reminds me the subject (in addition it is also a recurring subject at work for me). I wrote some comments on his blog, but I would like to detail a little bit here.

First of all, I am not confortable with the analogy done between manufacturing activities (or buildings and civil works) and IT industry, which basically leads to reduce developers to “simple” workers that could work in a production line (cf. Ford, with respect for manufacturing workers)…and I think that’s a point that is totally missed with hyper-specialisation.

I prefer other visions more suitable to our industry. In this first post, I will talk about “cultivate your code” analogy, “mentofacturing”, and feature teams approach.
Then in a second post, I will dive into an illustration of what could be stereotypical organization nowadays with “hyperspecialization” and my vision (shared and applied in my team), which is best aligned with Agile and Lean principles from my point of view.

“Cultivate your code”, a refreshing analogy

Classic analogies applied to IT industry are with buildings and civil works or manufacturing. But IT industry is fundamentally different from these industries. I will expose some arguments of another analogy, called “cultivate your code” I discover through Benoît Gantaume (in French but page translation can help non French speaker).

We often mimic processes of buildings and civil works. They are justified by the fact that once you have built a building, it is very hard to change it, it will not evolve as much as an application will. So they need to make lots of studies, to check every details before they lay the foundations. At the opposite, in software, it is very important to be able to build an application that can evolve quickly and potentially in depth (i.e not only on the surface). Moreover, an application that is not evolving will degrade through surface maintenance only, that’s why Benoît Gantaume compares it to vegetal with lots of comparison of day to day activities with those we can see in a garden (I let you read his post). The main idea is that a garden needs constant cares and a software is comparable in this way.

We like (in IT industry) to use manufacturing wording, notably industrialization. Note also that products are completely different, in manufacturing, products are designed once and built several times on production line. Software is absolutely not in the same case, it is unique, designed once and built once. About industrialization, we apply recipes of the XXth century (or even XIXth) with industrialization through (overly-)manual production line adapted to IT through hyper-specialisation. We do not use enough tools and automation at the service of individuals in IT whereas it is far more simple and cheaper than in manufacturing (installing software versus building robots). These arguments are not covered by Benoît, but I think it is like using the good tools to maintain your garden, rather than using only your hands. Even worst, we often use tools that constrain individuals, as if you would try to dig with a rake…

“Mentofactoring”

I heard for the first this word at USI 2011 event (for those understanding french – even if you have an english traduction also – here is the webcast). It was presented by Vincent Lextrait. He started writing a book and first chapters are available at http://www.mentofacturing.com/. I try to summarize key points, but encourage you to read at least home page, which give a good overview.

The reasons why Adam Smith advises divison of labor was based on different parameters than those that characterize work today. First, there was a shift with computers, that minimize cost of loosing time by switching tools. Second, there is far more variations in intellectual productivity than in manual productivity. Third, there is far more interpersonal dependency in intellectual activities than in manual ones.

It concludes that management (and so work organization) of these kind of activities cannot be the same as in classical industries (buildings or manufacturing typically).

Feature Teams

I read this from Craig Larman and Bas Voode book on Agile scaling about organizational tools http://bit.ly/oFtSAM, and specifically in chapter Feature Team (accessible here). The authors focus on Lean manufactoring in their book (finally even manufacturing has new vision…). It is really well explained, I will just paraphrase some part.

The main idea is “one single cross-functional team that completes end-to-end customer features”. It is justified by Lean theory : “In lean hinking, minimizing the wastes of handoff, waiting, WIP, information scatter, and underutilized people is critical”. They also insist on the fact that each team member has not only one speciality, each one has primary skills, but with help of other team members, each member can complete an end-to-end customer feature (reference to “generalizing specialist” introduced by Scott Ambler). Moreover, learning is at the center to share skills and knowledge.

The difference between Feature Team and Feature Project is also very important. With Feature Team, you have less organizational noise due to needed coordination when several Feature Project are involved on one application. It also capitalize on a group that learn and does not break up at end of a project. And third, a Feature Team has shared ownership of code, process and skills.

 

This three visions illustrate other visions than the mainstream that advocates hyperspecialisation. Next post will focus on an example.