Podczas niedawnego Agile Festivalu gościł w Poznaniu Alistair Cockburn, jeden z twórców Manifestu Agile, autor książek poświęconych m.in. metodykom zwinnym, przypadkom użycia jako metodzie opisywania wymagań czy rodzinie stworzonych przez siebie metodyk Crystal Clear. Zadaliśmy mu kilka nurtujących nas od dawna pytań ;-).
Przeczytajcie, jeśli interesuje Was:
- czy w projektach Agile wystarczające będą use cases o objętości karteczki post-it?
- czy ma prawo zadziałać połączenie „Prince outside, Scrum inside” (przydatne np. w projektach dla instytucji publicznych),
- czy ScrumMaster powinien przymuszać Zespół do korzystania z autonomii?
- co ma Agile do psychologii behawioralnej?
- o ile efektywniejsze są projekty Agile od waterfallowych?
- czy warto zmieniać ScrumMastera co każdy sprint?
- czy wszystkie tezy Manifestu Agile (2001) są wciąż aktualne?
Pozwoliliśmy sobie nie tłumaczyć wywiadu na polski:
Dominik Zyskowski: You’re a strong advocate of expressing requirements in the form of use cases. Use cases originate from waterfall approach, where there is a lot of time to do the analysis. Don’t you think short user stories that fit a single post-it card are enough for scrum teams because all unclear issues can be explained verbally?
Alistair Cockburn: This is a great and wonderfully misleading question that contains perhaps six subtopics! First is the mistaken presupposition that use cases originate from the waterfall approach; second is the implicit accusation that everything that originated before 1995 is automatically suspect; third is the disregard for the „oath of non-allegiance”; fourth is the mistaken declaration that all unclear issues can be explained verbally; fifth is user stories on cards are enough for scrum teams; and finally comes the actual question, whether use cases have a place on agile projects. What a great question!
Probably it would take an entire article to go through all six aspects of the question in proper detail, but let us at least take them briefly:
1. Use cases do not originate from the waterfall approach, but came in at the same time as we were „inventing” agile. They were first presented in modern form in 1987 to the OOPSA conference, where the dominant languages at the time were Smalltalk and C++, and most people worked in what would now be called an agile fashion. I learned of and included use cases in the IBM Consulting Group methodology in 1992. The methodology was already incremental, iterative and adaptive (and user-focused) before I added use cases and object-oriented languages to it. This was possibly, after Tom Gilb’s Evo methodology, the first agile methodology formally written down. It was by today’s standards fully agile, with deliveries recommended in the two- to four-month range then (a period still considered adequate for most agile, non-web-deploying companies). Indeed, at that time, people who wanted to resist using use cases refused on the basis that they were too closely associated to incremental-iterative OO projects, and not suitable for mainframe and waterfall projects. It is odd to me to now see the reverse accusation made :).
2. There is odd thinking in our field that every technique used before X years ago is no longer applicable. The object-oriented crowd in the 1990s similarly declared all project management techniques from pre-1994 obsolete, ignoring that incremental, iterative, user-centric, risk-reducing project management techniques had been in use for decades.
3. Please (re)read Oath of Non-Allegiance: „I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.” Just because an idea originates from elsewhere does not mean it has no value. On the contrary, we need to be extremely vigilant that as new paradigms replace previous ones, that we pluck out the valuable and still-applicable elements of the previous paradigm. In this case, even thinking that use cases originated with waterfall should not make them inapplicable.
4. Much though I am generally in favor of face-to-face and verbal rather than written communication, it is not always the case that unclear issues can be settled verbally. That excellent rule of thumb applies for small projects of perhaps 3-20 people. These days we see projects with dozens to hundreds of people, in multiple locations, multiple time zones, with multiple languages and multiple cultures, and with many critical individuals who are so busy as to not be available to answer questions in person. In other words, as they say, „Your Mileage May Vary.” As one example, the widespread difficulties in understanding and communicating the very short XP-style user story are what prompted the invention of the „As-A..I-Want..So-That..” style user story that is so popular these days.
5. There are situations where user stories are sufficient, and I was the first person outside of XP to defend them back in 1998. However, more often, these days, I see projects with morale problems because of the insufficiencies with user stories: sponsors don’t know how much it will cost to deliver a product or when it will be delivered, the business people can’t keep track of what all the pieces of the system do, and the test people don’t know how all the pieces fit together at the end or what has been left out.
6. It is these things that use cases address. A properly written use case occupies less than a single sheet of paper, ties together the understanding across the organization of what is being built, lets the business people select what to build next and be sure nothing critical is being left out, provides them a scaffolding to research tricky policy questions and corner cases, and provides a context for the testers to reassemble the pieces as they are completed. For UX designers and for those programmers who care, they provide a context of usage that reveals the purpose on the mind of the person using the system. The use cases can then be broken into user stories for development in very short iterations, and even written on post-it notes for those people who don’t want to read the contextual information in the use case around the user story.
Use cases have a very different purpose in life than do user stories. They are two different tools for two different purposes, and should not be confused.
Dominik Zyskowski: Do you think that it is possible to realize public/government software projects with agile methods? Usually these are fixed-price projects, where customers require tons of documents and formal procedures must be obeyed. What is your opinion on the „Prince outside, Scrum inside” approach?
Alistair Cockburn: There is no problem with Prince outside, Scrum inside, as far as I can tell from the little I know. I, and others, have used agile approaches on fixed-price contracts to good advantage. There is a more difficult challenge with public and government projects, however, namely that the regulations for contracts require or pressure into the fixed-price, fixed-scope situation, making some of the more interesting contracts unusable. Many people are working to find new bid and contract formats to get past this, but it seems a difficult topic for a long time to come.
Dominik Zyskowski: In ScrumMaster circles you can often hear that teams want to be told which tasks to do and how. This is contradictory to the foundations of Scrum which promotes self-organizing teams, but the reality is a bit different. Do you have any advice for ScrumMasters? Or maybe there is no need to encourage the team to use their autonomy?
Alistrair Cockburn: It does indeed seem odd to some of us that programmers want to be told which tasks to do and how. However, many programmers seem to, and this causes consternation amongst project sponsors, product owners, ScrumMasters and team leads, alike. I don’t know of a way to get these programmers to change, and so it becomes a matter of developing the maturity and independence of the individual programmers.
Jakub Bocheński: Many topics that you tackle on your site (e.g. “The dance of contribution”) seemingly fall into the area of interest of behavioural psychology. I’m curious if the claims you make are backed up by some particular scientific studies?
Alistair Cockburn: Some are, some aren’t. The graph on communication efficiency was one I drew, and then found substantiated by other research in the communications field (whew). The idea of software development as distributed cognition originated in the anthropology research book „Cognition in the Wild”.
„The Dance of Contribution” was an original research (after all, I do have a PhD and do my own research), which is why it was published as an „article” and not as a „blog” entry. As far as I know, it is unique in its focus on collaboration on the minute-to-minute level
Thank you for knowing so much about my web site :).
Jakub Bocheński: Most people who use agile methodologies assume it is obvious that they yield better results. Are there any metrics which demonstrate in what specific areas and how much better those results can be? A cursory Google search finds only commonplace metrics that are very often gamed, idosyncratic (particular values are heavily tied to a project/ organization) or not useful for comparison with traditional methods (e.g. it’s obvious TDD will lead to higher test coverage) Keith Braithwaite had a very nice presentation about measuring impact of TDD in terms of cyclometric complexity. Though not ideal, it’s a step in a good direction, I think. Can you recommend some similar material?
Alistair Cockburn: Quite a number of people from relatively large organizations (SABRE and BMC comes to mind) have published quantitative results about improvements from using agile approaches. Since these are in the literature, I have never occupied my time with collecting them. I suspect it would take quite some effort to find all those studies, even though they have been published.
What I find more compelling is when a sponsoring executive who is pulled through six months or so of an agile effort, says, „I would never go back to working the other way.” This is not a matter of 10% or 15% productivity gain, this is a gain large enough that he or she would jeopardize their company by reversing direction. There are also examples of companies that have come to dominate their industries by being so responsive to market forces that they eclipse their near competitors. Here I am thinking of REA.com in the current Australian real-estate market, and Rand Merchant Bank in South Africa in the late 1990s, which grew so fast that by 2000 it has purchased the First National Bank of South Africa, become First Rand Bank (and then having to decide what to do with all the non-agile projects in the groups they acquired!).
Krzysztof Urman: Recently on your page there was a discussion about ScrumMasters. Does a self-managed team really need a coach or any kind of „servant-leader”? If all team members are responsible for their work, why is one person distinguished? Maybe SM should be changed in every sprint?
Alistair Cockburn: Haha: I started answering that question on the site and then stopped, didn’t I? Good catch. As far as I know, the ScrumMaster did not originate as a coach or leader of any kind in the early 1990s, but that this aspect has grown particularly in the last 10 years and teams have adopted Scrum. I like to think of the ScrumMaster as „Chief Impediment Remover” and not coach, and know a few ScrumMasters who work this way to good effect. Your other suggestions are on-target: Teams that have been together for a while sometimes report both rotating the position, and eventually getting rid of the position entirely.
Krzysztof Urman: You are one of the authors of Agile Manifesto. Do you still agree with all of its theses, values and principles after more than ten years (Agile Manifesto was signed in 2001)?
Alistair Cockburn: The values are still sound and I still agree with them. I don’t think we ever had total agreement on all 12 principles, and don’t to this day. I think each co-author of the manifesto has reservations about different ones of the principles, that some other co-author holds dear. You might find it interesting to see if you can tease out of the various co-authors, as you see them, which ones they have trouble with :).