RE: [agile-usability] Re: Real data
Standing ovations, great arguments.
What has been bothering me for a some time now, is that agile methods - by definition – are development methods. They integrate testing which is nice. But they don’t necessarily provide best fit for all projects and don’t cover all areas of business systems development. (On the other hand Agility is a mind-set that should be embraced at all levels by the organization that wants to utilize any agile method.)
If you are in highly regulated area or safety critical area, you can’t stop your iterations at some point where you think results are satisfactory. You have to match the requirements exactly or you’d be in trouble.
If you are developing a very intensive sw where usability and effectiveness rule, such as call center sw. You could go two ways 1) Agile method with usability tests in each iteration measuring the quality (technical automated test wouldn’t measure real performance and give any indication of business value) 2) develop the effective user interface by prototyping with various methods in agile iterations. Then pass the prototype as blueprint for development. Development could then be done to specification in theory by any method. If development is done with agile method, you’d then choose the most critical parts, enabling architecture and start building those. Then start getting value from those and move on to build next phases etc. IMHO, either works. In real life, the goal of business owner “As a business owner of call center, I want my employees to have most effective call handling software” won’t be filled any random array of fields on UI. The necessary fields are also known before hand. Why would programmer have discussion about whether we’ll put the address field there or not. Without it SW would be useless. You can and you should be agile on many levels. In a case like this, screens and functions where you’d handle system parameters and other stuff used only by few and occasionally could be done directly with programmer and product owner. No need for usability specialist there. So, you should be also agile and prioritize areas where you need special effort.
Some agile practitioners are so “Agile” that in my opinion they are not a least bit agile and lean. What do you think of following, partly imaginary example. When renewing insurance claim handling software you can run into following situation. Current system is technically old and it’s necessary to move it into modern architecture. Functionally it does everything it has to except for a few new interfaces. All use cases, information models and test cases exist from previous development project. What does many agile SW teams do in this situation, is that they throw away existing use cases and business rules documents that tell exactly what fields are necessary and how data is supposed to handled according to regulations and policies. They throw away the class model and test cases. Then they start to create a backlog from scratch. That is muda (as in lean) if anything. You already kinda had one… use case diagrams tell you who uses which use case (=as a “who”) and use case document’s short description should contain roughly same things as user story… and rest of the document tells you the fields and details that you need in later iterations, for example. If I order a sofa table from carpenter and I already have model in mind, I expect carpenter to do it to my specifications. I’m not really interested if he’s using manual or power tools as long as the result is what I wanted.
Oh, another thing. There’s quite a little conversation about usability anymore. Most seem to be around just agile or agile vs Godzilla or something like that… disappointing.
- In firstname.lastname@example.org, "Larry Constantine" <lconstantine@...> wrote:
I hate to interrupt the entertaining exchange between George and Glen, both of whom I like and respect very much, but I'd like to offer a response to your questions, if I may.
(1) "What if CMM level 5 and RUP practices actually worked significantly better than agile ones? Would that mean we should switch horses?"
It seems as if the question presupposes people have to make a mutually-exclusive choice of one process or another. The phrasing of the question also appears to reflect an assumption that "agile" was invented out of whole cloth without any reference to other methodologies or real-world experience. In fact, the authors of the Agile Manifesto included individuals who had extensive experience in IT methodologies, RUP in particular, and their knowledge and experience in this area informed the results of the Snowbird meeting. There's no question of switching horses, because we're not on any particular horse.
Members of the agile community are familiar with the processes you mention, and we apply them as and where appropriate in our work. Some agile practitioners have been deeply involved in combining and complementing different methodologies and frameworks to try and achieve the best possible results for their clients. Jeff Sutherland, one of the creators of the popular agile process framework, Scrum, has combined Scrum with CMMI in large organizations, with good results. Hilel Glazer is another who has combined these two schools of thought successfully. David Anderson did some work in using general agile methods alongside CMMI before he turned his attention to adapting ideas from Lean Manufacturing to problems of software development and organizational improvement.
The needs and the current reality in any given organization are unlikely to be identical to those of any other organization. There is no one-size-fits all version of "agile" that we try to impose on every situation. Even when we determine that agile is appropriate for a given client, we have to adapt agile methods to that client. It is also quite normal to incorporate elements of other processes and other schools of thought when crafting a process that works well in a given situation. There is no inherent conflict between any of these processes or approaches. There is no "contest" to be won or lost on the basis of published studies.
I think we also have to keep in mind the particulars of each situation. A process that helps a team of 3 develop a quick-and-dirty web site is unlikely to be very useful in managing 200 subcontractors in a program to develop a new military aircraft. Conversely, a process appropriate to the latter situation would be needlessly formal for a team of three people who are building something with a very low cost of failure. A process that helps teams create business application software in an environment where the stakeholders aren't certain what they need, but just have a general idea for a business initiative, would probably include frequent and short feedback loops to enable everyone to try out interim results; that sort of process would be cumbersome in an environment where requirements are well-known and stable. Conversely, a process designed to build from well-known, stable requirements would be useless in the former case; it would cause very long lead times.
So, what we need to do - and what we already do in the agile community - is to choose appropriate processes and adapt them to each situation. We don't have a cookbook.
Here is a different angle on the same question. When you say that one process works "better" than another, I suspect there is an underlying misunderstanding. No process "works." A process is only a tool; a means to an end. People work; processes do not. Therefore, it is a non sequitur to say "Process X works better than Process Y." It is meaningless to say, for example, "CMM works better than agile," because neither CMM nor agile works at all.
If a process is a tool, then what are the characteristics of a good tool? I would say there are two: (1) The tool is appropriate to the job at hand; and (2) the people using the tool use it properly.
I have a very nice hammer in my toolbox, along with several other tools. The hammer does absolutely no work. It has no knowledge, skills, initiative, or ambition. However, it is available to help me do work, when I determine that it is the appropriate tool for a job. From that point forward, it's up to me to use the hammer properly so that the end result of my work will be satisfactory. If the end result is not satisfactory, I cannot blame the hammer. If I do a bad job with the hammer, I will not solve anything by buying a different one.
I have an assortment of tools in my professional toolbox, as well. Some of them are conventionally associated with "agile." Some of them are not. The ability to judge when each tool is appropriate and then to use it properly are my professional skills.
(2) "Or would it mean we should revise agile to incorporate the best parts of other practice traditions? (And maybe shed some baggage at the same time?)"
This is already a fundamental aspect of the agile approach to work. A published study would not somehow trigger this behavior. Continuous improvement is a fundamental value of agile thinking, just as it is for Six Sigma, Lean Manufacturing, and CMM. Personally, I interpret that to mean that the ultimate goal of the agile community is to out-grow the need for the word, "agile;" to out-grow the need for a special buzzword to describe a certain way of thinking about problems, because that way of thinking has become ingrained and natural.
I've noticed that in recent years most companies I visit are in a very different "place" than most companies were ten, fifteen, or twenty years ago. The methods we now refer to as "first-generation agile" were very effective at addressing organizational problems that were common ten years ago. Today, we often find a company is in much better shape than that, and their needs are different. Many companies are still operating in a 1980s style, too. We need to choose the appropriate tools from our toolbox for each situation, and we also need to keep our tools sharp and clean, and add useful new ones as we discover them.
Agile is continuously being revised to incorporate newly-discovered useful practices and to improve the existing practices. On the technical side, consider the ways in which test-driven development has evolved in the past ten years. It is a far more mature practice than it was when the word "agile" was first coined. We now take a test-first approach to requirements, resulting in executable requirements developed collaboratively with non-technical stakeholders. At the unit level, the behavior-driven approach has superceded the original implementation-focused approach. I don't mean to suggest everyone does these things, but they are leading-edge practices.
On the Process side, consider the changes in agile methods in the past ten years. RUP called for iterations of no particular length, but typical implementations set iteration length at about 3 to 4 months; sometimes longer. Scrum initially defined a 30-day iteration length, on the assumption that it would fit nicely with the typical monthly business cycle. As these methods were employed in more and more situations, we learned that shorter iterations tend to produce better outcomes (in cases when an iterative approach was appropriate to begin with). Five years ago, the canonical agile iteration length was 2 weeks. Today, a one-week iteration is quite common. At the one-week iteration length we begin to find the traditional agile ceremonies are taking up too much time and not yielding the value they were originally intended to provide (for the best of reasons - the original problems that called for those ceremonies have been solved), and we move toward an iterationless process based on continuous flow rather than on time-boxing. I'm confident that as time goes on, smart people will continue to make improvements in agile practices. There is no end to improvement, and there shouldn't be.
We have a wide range of approaches at our disposal, and we can apply them selectively depending on the needs of each organization and each team within an organization. I see it as a continuum of improvement. When we incorporate new approaches, we don't retire old ones; we don't "switch horses." Each agile practice is designed to solve specific problems. Each organization is different, with different problems and different degrees of readiness for change. So, as we have revised agile over the years, we have retained earlier flavors because they are still useful in selected situations.
Similarly, we routinely combine selected agile practices and ideas with elements of CMM, RUP, Lean, Six Sigma, and other schools of thought. This is already part and parcel of agile practice.
(3) "Or doe the agile community have the TRUE answers, regardless of the facts?"
This doesn't sound like a sincere question. Instead, it implies you hold some negative assumptions about a large number of people you don't know, and whose work practices you don't understand. Rather than asking others whether they hold beliefs that contradict facts, I suggest you ask your own bathroom mirror.
I see that you follow your name with an aphabet soup of credentials. Based on the substance of your questions, and particularly this final question, I'm not impressed.
Capgemini is a trading name used by the Capgemini Group of companies which includes Capgemini Finland Oy, a company registered in Finland (number 1628142-5) whose registered office is at Niittymaentie 9 – 02200 Espoo.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
- Hi, Jon,
Jon Kern wrote:
> ok, maybe it is silly to debate the term...I've never found creating software to be a "one and only time" no matter
> George it's a free country, use method anytime you please :-)
> I personally will only use "method" when I want to describe some way
> that I achieve something over and over. Often in an abstract sense,
> often in a step-wise way. Often because the "something" is a desirous
> end goal, and one that I (or someone else) wants more than one time.
> I would not describe the /ad hoc/ "how" of the one and only time I will
> ever do something as a "method" if it is not.
how small the program. There's a lot of similarity between writing one
line of code and writing the next.
And I've observed, that people generally continue to do something
somewhat in the fashion they've done it before. Thoughtful people will
consider the result their achieving, and modify their actions to try to
improve some aspect.
I've never seen anyone continue to approach the work as if they'd never
done anything like it before, choosing some completely different way of
working. And I've never seen anyone carefully follow the recipe in a
process manual. At best, a process manual gives the worker some ideas.
It's the process people actually /do/ that has an effect. If you and
Scott and Glen want to reserve the word "method" for officially blessed
procedures, go right ahead. It won't change a thing.
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org