The Agile Movement and Practices

W@H: How would you explain the Agile movement to WikiNews readers who aren’t familiar with the field?

FRANCESCO: The Agile movement began with the objective of making software development more effective and concrete: these two qualities translate into opportunities for companies to make more profits.

Whether it’s favorite application or one that you use everyday at work, who hasn’t at least once thought to themselves: “Okay, but if it could only do this one other thing, too…”. Today, client and user requests for change is the primary demand that software developers and marketers must respond to. And they must be able to respond quickly to these demands because it translates into significant economic and competitive advantages. That’s why being reactive to change becomes a determining factor when a company decides to put its primary services online.

I’ll try to be more specific: when market demands change, a successful company has to immediately adapt to this new business, and this means they need a development team (ed. a group of programmers who work together on the same software) that can make those requested changes quickly – with high quality and at low cost. Today we can’t afford to think of software as some kind of static product; its value lies in its being able to achieve a state of continuous change.

Teams often resist change. Not on purpose, but because they don’t know how to manage it. Not understanding how to manage change causes them to fear it. Agile Methods provides a strategy to effectively respond to change through a series of individualized technical and organizational practices (emergent design, pair programming, planning game, etc). By learning how to manage change, development teams change their perspective and begin to see it as an opportunity and not as a problem. And that’s how you reach the ultimate goal, which is to work in a way that’s rewarding, to share the vision with the end user or the client, and to bring economic advantage to the company.

W@H: But is this just “shop talk” for people in the industry?

FRANCESCO: Not at all. I’d say that it’s really about common sense. The underlying principle of Agile Methods is that the development process, the way we work, can achieve a state of continual improvement if the people who working on it are all members of the same team interacting effectively.

W@H: Programmers are often withdrawn types who like to ‘fly solo’, and cooperating means communicating with others. How do you help programmers in the different teams you work with to overcome this obstacle?

FRANCESCO: When programmers have a distaste for communicating it’s because they don’t think it’s worth their while to be communicative :). This happens in teams where, when someone tries to communicate something, they get criticized by the manager or other members of the team. So this is not only a negative experience, it can also lead to all-out frustration. Then everyone ends up being afraid to communicate. To put it simply: they feel it’s not worth their while. It doesn’t take long before it begins to seem like there isn’t much need to communicate at all. But by not communicating, the team is coming up with sub-optimal solutions and the level of frustration of the individual team members continues to grow. The programmer’s main job is to solve problems. In order to cooperate to find a solution to a problem, to explore new ideas, the threshold for embarrassment has to be lowered. How can you reach this point if "Luigi, as usual, is unable to do this well"?

All too often during work in teams problems become personalized. Every comment seems to spark off personal attacks. The threshold for embarrassment rises and this is an obstacle to finding simple solutions to problems.

How do I help them? I, too, was once an expert in not knowing how to communicate. Over time I’ve learned that you need to be “hard on problems, soft on people” and that it’s useful to see problems as opportunities for improvement. As a team, when we share a series of objective principles, it becomes easier to recognise when these principles aren’t being followed in the work we do, and criticism will be directed at the action that violated the principle and not towards Luigi’s presumable lack of ability. If I’m able to express this the right way, cooperating and communicating become worth my while because it brings personal benefit. It’s a kind of enlightened egoism.:)

W@H: So is this how you’re able to gain control of people’s emotional nature?

FRANCESCO: The objective isn’t to control emotions; the objective is to be effective.

W@H: How do people react to personal changes?

FRANCESCO: The initial reaction often isn’t all that simple. All of us would like to hear that we can obtain huge advantages with very little effort. But it doesn’t work that way. It’s important to the tell the team from the very beginning that even small changes are only achieved through significant effort. It’s the continuity of these small changes that produces improvement in terms of productivity. If people clearly understand this, their motivation is greater and the risk of disappointment is reduced. Companies gain by investing in the continuity of small, individual changes.

THE POMODORO

W@H: What is the "Pomodoro"? Is it being used in the fields other than IT?

FRANCESCO: The Pomodoro Technique is the name that I gave to a practice that I’ve been following ever since I discovered that I wasn’t studying effectively and I decided to improve the way I worked by making my mind work better. The main objective is to collect useful information (in a simple, uncomplicated way) about the way that I work, in order to make observations and use this data to find ways to improve. The technique is based on a very simple tool: a kitchen timer. My first timer was shaped like a tomato (pomodoro in Italian), hence the name of the technique. From when I first wrote the paper, I’ve seen the technique used successfully in range of widely differing contexts: software developers, conference organisers, musicians, architects, lawyers, etc. But I was most amazed to find out that there are children who happily use the Pomodoro to do their homework. And I always love to hear from adults who have gone back to school and are using the technique to study.

W@H: When they call you to work as mentor to a team (in this case a mentor is a trusted advisor, who acts as an experienced guide for the development team, intervening to suggest a general outline to follow. Unlike a coach, a mentor does not have responsibilities directed at the team or the projects in progress. Ed.) is it the team itself that calls you in for help?

FRANCESCO: Yes. In fact, this is absolutely essential. Being a mentor means enabling teams to learn how to improve their work process by themselves. This is what makes mentoring different from consulting. Only a team that is aware of its own problems and understands that they need to learn how to use effective tools for improving their work process will feel the need to call on a mentor.

W@H: So can we say that one of the fundamental differences between traditional software engineering and Agile Methods is that in Agile the development process puts people first?

FRANCESCO: That’s correct. In Agile Methods every team member contributes to improving the development process. Anyone who is interested in a successful project is considered to be part of the team, so the client is considered a team member, too. It would be like a manufacturing industry where the factory workers, project managers, customers and sales staff all worked on the same production line to find the best ways to organise themselves and to produce the final product. This self-regulating ability is what distinguishes Agile teams and it requires responsibility and knowing how to cooperate. That’s why people have a primary role in Agile methods.

In traditional software engineering it’s often just the opposite; priority is given to processes over people. Processes are imposed on people, who have to adapt to them. The feelings of depersonalisation and de-motivation that this can produce are evident, and in the end company productivity suffers. It’s interesting to note that often this adaptation to the process ends up producing a kind of schizophrenic phenomena: developers experience two different but parallel processes, the one that they should be using and then the one that they actually use.

Making people the "factor of primary importance", as Agile Methods do, is the best guarantee to be able to react to changes, even drastic changes, whether requested by clients or dictated directly by the market. This is because it’s the team members themselves who are able to see opportunities for improvement and adapt their work process to the changes in the environment around them.

W@H: A people-centered development process, that values and promotes its members skills and experience. But how does it work?

FRANCESCO: In Agile Methods the aim is to find a win-win solution where the developers are working under the best conditions and with the best content and companies are making more profits. How does this happen? In an Agile team, every member can contribute to improving the work process. Every team member takes on the responsibility for completing entire functions – they aren’t assigned them by someone else. Team members know that they can propose new ideas and be creative in their ideas. These ideas will be exhaustively critiqued but it’s criticism that’s constructive and respectful. Working together with another developer in pair programming means increasing product quality, learning from someone who may know more than you, or discovering something new from looking at things from a different point of view. The programmer can communicate his development problems without feeling embarrassed, knowing that the team will help him or her through. Making a commitment to producing software that is comprehensible to everyone. And most of all, making software that grows and evolves through test-driven development.

All of these things translate into fewer bugs, greater overall flexibility and consequently a lower cost for making changes. Managers are able to reduce activities related to control – because the team is now interested in improving itself – and, even more importantly, managers can stop trying to motivate other people. The team becomes motivated by the work content itself and the process they’ve all agreed to follow. Everyone works with a greater sense of satisfaction and company productivity and profits increase.

W@H: Is Agile a philosophy of life?

FRANCESCO: I think that in general, it appears more and more evident that the ability to successfully respond to change is becoming essential, and not just in the field of software development. The values and principles of Agile Methods offer an effective solution to responding to change by supporting communication and simplicity, placing value in individuals and their contributions, and putting the focus on responsibility and cooperation. Which is all part of achieving concrete objectives, solutions that work.

W@H: I’d imagine that to be able to organise such complexity through simple behaviours you’d have to really know your stuff.

FRANCESCO: You have to know the principles and know how to put them into practice. And, if you decide not to put them into practice, you have to understand the consequences of that decision. These are all things that can be learned.

W@H: Earlier we said that in the traditional approach to development there is someone who immediately makes design decisions, and the programmer’s job is only to translate the analysis into code, but now we’re talking about programmers making their own decisions.

FRANCESCO: To be able to “embrace change”, the structure, the design, has to follow the application’s functions in a continuous way. In today’s world, where change, even drastic change, is a primary factor, these same structures must be constantly put up for discussion and remodelled as necessary. This is what makes emergent design "emergent". It’s a little like when we used to play with Play-doh as kids: with just a few movements we could turn a boat into an airplane. In the same way, an Agile developer makes a structure emerge by recognising it, instead of imposing a rigidly-defined structure from the start, which carries the risk of later not being able to modify it in any way. This characteristic of malleability is the quality of software that the Agile developer must measure up to everyday.

Traditional approaches have specialized roles: the analyst, the designer, the programmer, the tester. With Agile Methods there is a sort of de-specialization: the Agile developer takes on all these roles. But it’s precisely this ‘all-inclusive’ aspect that enables the developer to be responsible for an entire function and to bring it to fruition, making all the appropriate decisions of the analyst, designer, programmer, tester. An Agile developer, as ‘just a programmer’ now has to make responsible and informed decisions. This contributes to increasing motivation and fulfillment in his or her job.

W@H: Have Agile Methods been applied to fields other than the IT sector?

FRANCESCO: In the manufacturing sector lean production has evident similarities to Agile Methods. Toyota is the most relevant example. The team is involved in working together to eliminate defects and improve the work process; that’s what I think is the most significant element. The relationship between lean production and Agile Methods is interesting because we tend to think of the manufacturing industry as something completely different from the production of something intangible like software.

W@H: This year there were 250 attendees at IAD 2007; last year there were 180. It would seem that in Italy something is beginning to get moving, something is changing. Do you think this increasing interest is a positive sign?

FRANCESCO: Yes. Besides an increase in number, interest is moving beyond programmers and students who were initially merely curious about the novelty of Agile Methods to business managers who are interested in capitalising on the economic advantages that these methods can bring.

W@H: Is it true that you have a wood-burning oven for making pizza in XPLabs?

FRANCESCO: Yes. Since 2000 the XPLabs Collaborative Engineering Center, the original headquarters of XPLabs (a remodelled farmhouse in the countryside near Sutri) has hosted teams that want to learn how to become more effective using Extreme Programming (XP) and Agile Methods. On Tuesday nights we would hold a weekly chat with the XP-IT mailing list members: that’s how we got the idea of cooking together. We tried to do it applying the principles of XP and it was a lot of fun. After a while, our playful spirit attracted the attention of many pioneers in the field. The Center has hosted many methodologists in software engineering, including Ward Cunningham – the creator of Extreme Programming and Wiki. No one ever skirted their duties on Tuesdays, everyone pitched in to chop tomatoes or take on the task they chose for themselves, just like they would in a real Agile team. The pizza oven was a natural evolution of this practice:).

WIKI

W@H: Do you know Wikipedia and Wikinews? How do you use them?

FRANCESCO: I know them and I use them often. As I said, the idea of Wiki was conceived by Ward Cunningham, the father of one of the Agile Methods. Wiki applies an emergent design concept to collecting information. The emergence of concepts and definitions in Wikipedia is markedly similar to how Agile developers grow software.

W@H: Wiki@home is “citizen journalism”, a collection of interviews of famous people or experts carried out by normal people like myself and then posted online. What do you think of it?

FRANCESCO: I think that it’s a simple way to achieve direct and effective communication between the interviewer and readers.