• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Examining the Agile Manifesto

 
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The article Examining the Agile Manifesto takes a look at the values and principles of the agile manifesto, discussing each one and explaining why they're important to you as software professionals.

Any feedback would be appreciated.

- Scott

[removed extra space at end of URL so URL renders as a link]
[ March 04, 2006: Message edited by: Jeanne Boyarsky ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"Individuals and interactions over processes and tools" - what I'm missing here is the notion that the use of some tools easily can actively reduce the interaction taking place. The introduction of a bug tracking tool, for example, can easily reduce the amount of direct interaction between developers and management/customer.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


For some reason many people within IT have seem to have forgotten that the goal of software development should be the development of software.



I'm not sure that is generally true. I think some people just don't know how to develop software truely incrementally and iteratively. Consequently they think they can't start building the actual software until they are sure they know that what they will build will be the right thing.
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

For some reason many people within IT have seem to have forgotten that the goal of software development should be the development of software.


And taking this further, in the commercial software business the goal of software development should be to help the business make money and not "just" writing software.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

For some reason many people within IT have seem to have forgotten that the goal of software development should be the development of software.



I've been feeling this strongly lately. We had a perceived quality problem and the remedy was more process steps - documents, reviews, sign-offs. Very much process > people. Nothing about tightening the loop between ideas and software, TDD or just plain coding better. Ouch.

I just read an inteesting paper on the iron triangle of time, cost and scope (I like how Scott draws it with quality in the middle). It relates the triangle as a measurement of success to the very definition of project: a finite piece of work done on time & budget. I'll edit in a reference to the paper if I can find it on my other PC.

If you measure "business value / cost / time" you reward the teams that actually deliver software every iteration. This removes the illusions of fixed scope (change happens) and fixed time and continues as long as it's delivering value.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
I've been feeling this strongly lately. We had a perceived quality problem and the remedy was more process steps - documents, reviews, sign-offs. Very much process > people. Nothing about tightening the loop between ideas and software, TDD or just plain coding better. Ouch.


Funny that you should say that. I just gave a talk this week about the building blocks of perceived quality which is as much about fit-for-purpose (building the right thing) than it is about technical quality. And getting people to care is much more effective than adding process to "enforce" people to improve quality.
 
Scott Ambler
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

what I'm missing here is the notion that the use of some tools easily can actively reduce the interaction taking place. The introduction of a bug tracking tool, for example, can easily reduce the amount of direct interaction between developers and management/customer



Yes, but I'm not sure that this observation is in context for the article. Why do you feel this is an important issue?

And taking this further, in the commercial software business the goal of software development should be to help the business make money and not "just" writing software.


Yes, but I would argue that the same is true of non-commericial software too (although often the goal is to save money).

I just read an inteesting paper on the iron triangle of time, cost and scope (I like how Scott draws it with quality in the middle). It relates the triangle as a measurement of success to the very definition of project: a finite piece of work done on time & budget. I'll edit in a reference to the paper if I can find it on my other PC.


My paper is The "Broken Iron Triangle" Software Development Anti-pattern.

- Scott
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Your footnote link to Two Best Guesses and a Phenomenon was what I read the other day. It talks about using the corners of the triangle as your success criteria.
[ March 06, 2006: Message edited by: Stan James ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What I feel is that many people actually don't see the strong connection between "processes and tools" and "people and their interactions". They say they value the latter over the former, but fail to assess how the tools they use actually influence the interactions that take place. (The current AM-thread on inclusive models might be an example of this phenomenon.)

That's why I feel that *judging* processes and tools based on how they affect people and their interactions can't be stressed enough. Might just be me, of course...
 
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I like the article, the "individuals and interactions" section hints at an issue I think people have forgotten about. Some processes or organizational functions are about risk management. In the case of software development, QA and CM (build mgmt et al) obviously fit into the risk mgmt role. There is nothing wrong with managing risk, but risk management never really produces something of value all by itself, at best it only protects or standardizes something of value produced by somebody else. I think some organizations lose site of that, pour huge resources into the wrong places, and then wonder what went wrong. It is like they believe buying car insurance will magically cause a new car to appear in front of their house.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
An insurance is a rather weak form of risk management - compared to reducing the probability of needing to call upon insurance.

That is, large parts of Agile processes are *also* about risk management. In fact it could be argued that the whole notion of face-to-face communication and rapid feedback is mainly about managing risks.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I like to equate risk with uncertainty. It sucks to leave a plan with big unknowns in it and it makes sense to figure those things out early and re-plan with what you learn. Agile doesn't force you to do that, but iteration planning gives you a neat way to focus on eliminating uncertainty in early iterations and adjust accordingly.
 
Ranch Hand
Posts: 362
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Individuals and interactions over processes and tools. That would have saved Ferrari a bucket full of million dollars. Just give Schumacher a beetle. Point being is that if your competition hires "hamburger flippers" all is well, but if they hire programmers as good as yours then the tools and processes will make the difference.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gerardo Tasistro:
Individuals and interactions over processes and tools. That would have saved Ferrari a bucket full of million dollars. Just give Schumacher a beetle.



I think you missed the point. Nowhere in the manifesto is it said that you should use tools that are inappropriate for the task at hand.
 
Gerardo Tasistro
Ranch Hand
Posts: 362
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:


I think you missed the point. Nowhere in the manifesto is it said that you should use tools that are inappropriate for the task at hand.



I agree. I also never said you should use tools that are inappropriate for the task at hand. My point is that the best F1 pilot isn't going to win without the appropriate tools. I see were Scott is going to, but I believe his point misses the fact that this is a competitive environment (much like F1). You can't compare a pack of non-programmers with a team of SCJP and conclude that tools don't make a major difference.

The funny thing about this is what was going on my side of the screen as I wrote that post. I was with one of our partners working on interconnecting two systems through XML. Mine Java based JSP application. His an ASP. I could only laugh at my situation as I read Scott's link.

I had Tomcat 5.5 he had some form of IIS on W2003. I had Eclipse. He had Notepad. I had breakpoints and the debug mode. He had Notepad. I had MyEclipse IDE to manage Hibernate and JSF. He had Notepad. I had XStream to convert objects to XML and back. He had Microsoft DOM and had to parse child by child. I had Hibernate. He had to parse the strings returned by the database to build the XML response.

The total cost of my tools? 30 buck (that was for MyEclipse). Of course Notepad is also free with Windows, but then again....

I would be tempted to propose an X^2 curve for this model. Say an average programmer will value at 1. 1^2=1 A less than average programmer would value at say 0.5. Not being good and getting bogged down by the tools his performance could be 0.25 (0.5^2). But as soon as your programmers break the 1 barrier things grow incredibly fast. A twice as good programmer (2) could be 4 (2^2) times more productive (up to the limit of sleep and 24 hour days!!! ).

Finally the Individuals and interactions over processes and tools paradigm seems itself to go against Agile. If you pair program soon bad programmers are weeded out (either become good or kicked out) and you hit a development barrier not set by skill.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Gerardo, it's people and interaction over processes and tools. Not people and interaction instead of processes and tools.

Agile methods do not promote avoiding tools for the sake of avoiding tools. Agile methods promote adapting the choice of your tools to your real needs. For example, it's pretty likely that any given "agile proponent" would recommend using Eclipse over Notepad.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gerardo Tasistro:
I also never said you should use tools that are inappropriate for the task at hand.



I understood you to say that you interpreted the manifesto the way that it said it wasn't important to use appropriate tools. Now I understand you to say that you interprete Scott's article that way. Am I correct?

I see were Scott is going to, but I believe his point misses the fact that this is a competitive environment (much like F1). You can't compare a pack of non-programmers with a team of SCJP and conclude that tools don't make a major difference.



And you understood Scott to do that?

I had Tomcat 5.5 he had some form of IIS on W2003. I had Eclipse. He had Notepad. I had breakpoints and the debug mode. He had Notepad. I had MyEclipse IDE to manage Hibernate and JSF. He had Notepad. I had XStream to convert objects to XML and back. He had Microsoft DOM and had to parse child by child. I had Hibernate. He had to parse the strings returned by the database to build the XML response.

The total cost of my tools? 30 buck (that was for MyEclipse). Of course Notepad is also free with Windows, but then again....



I totally agree that what he did sounds inappropriate. And as you noticed, this was not a problem of availability - he could have used more appropriate if he wanted to. So I'd argue that this was in fact a people problem - for some reasons the developer didn't decide to use appropriate tools. The best solution to this problem, in my opinion, is not to prescribe the use of some tool, but to educate the developer so that he chooses to use better tools. Perhaps if you pair programmed with him...


Finally the Individuals and interactions over processes and tools paradigm seems itself to go against Agile. If you pair program soon bad programmers are weeded out (either become good or kicked out) and you hit a development barrier not set by skill.



So you are saying that in an Agile team, the skill levels of the developers will converge? Is that your experience?

Anyway, "people and interactions" is about a lot more than just skill, in my opinion. Perhaps Scott's article doesn't make that clear (or perhaps Scott's opinion actually differs from mine here).
 
Scott Ambler
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Finally the Individuals and interactions over processes and tools paradigm seems itself to go against Agile. If you pair program soon bad programmers are weeded out (either become good or kicked out) and you hit a development barrier not set by skill.



Actually, I&I is at the heart of agile.

You're right though, the true barriers are typically cultural, and they're hard to overcome.


Anyway, "people and interactions" is about a lot more than just skill, in my opinion. Perhaps Scott's article doesn't make that clear (or perhaps Scott's opinion actually differs from mine here).



Nope, I'm pretty clear that it's mostly about attitude. See Personality Traits.

- Scott
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Scott Ambler:

Nope, I'm pretty clear that it's mostly about attitude. See Personality Traits.



That still seems to be mostly about "getting the right people". I think that line in the Manifesto is about much more:

First, it's about how we *treat* people. It's about respecting peoples individual needs, about giving them influence on how they do their work, about stimulating their individual strengths and compensating for their weaknesses etc. pp.

And second, it's about how we foster their interactions. Good interactions do much more than just transferring information - they facilitate learning, foster creativity, align expectations, help building good relationships and trust and so on.

Both of these aspects are *much* more important than what IDE or language you use, no matter how good your developers are, in my not so humble opinion.

To pick up Gerardo's example, what would worry me much more than the other developer using Notepad is the subliminal theme of "me versus him" in the report. That doesn't sound like the best mindest for a partnership to me, so I'd want to find out more about this.

Mind you, this is just an example, and I wasn't there, so I'm definitely not blaming Gerardo for anything here.

But getting a better IDE for the ASP developer wouldn't be the most important thing to think about (although I wouldn't fully ignore it either) to me. If those two (assumedly not colocated) developers have to work together, I'd put much more energy into facilitating the relationship between the two - making sure that they meet face to face every couple of months, including eating lunch together, organizing webcams, suggest remote pair programming - hell, even a photo next to the telephonenumber in the wiki can work wonder.
 
Gerardo Tasistro
Ranch Hand
Posts: 362
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well I never meant to do a "me vs him" comparison. Just state the irony of reading Scott's post at the same time I was having this experience.

Just to clarify a couple of things. We had periodic meetings. We had settled the issues. The XML covered all bases. Yet when I got there there were minor modifications that needed to be done. Yet they were hard to debug on his platform due to the lack of proper tools. That slowed down things.

I can not see one over the other as the manifesto states. Just as the fancy set of tools can give you the impression of being overly powerful and capable of solving everything while lacking the proper individuals will lead you to failure. So will the proper set of friendly, well to get along and experienced individuals give you the impression of tackling any problem. The truth being that without the proper tools they will fail no matter how good they are.

Leaving this behind and focusing on the whole picture of the Agile Manifesto. The more I read into it and examine your (not your position in particular Ilja, your as in yours all) positions the more convinced I am that this has nothing to do with programming at all, but rather with administration and bean counting. I've been particularly interested in other threads about selling "agile" to management. This is particularly true with points 3 and 4.

These points have very little to do with programming and lots to do with administration. The client really doesn't know what he wants. The developer wants to maximize profit by having programmers work as little as possible (so lets not change plans too often). The client wants to know when he'll get his "doesn't know what". We all want to outsource because its the hip thing to do, so few developers are in the everyday know how of the business. The client puts the same people (his employees) who should be working with the developers to do other things aside assist in the development (he also wants to maximize profit). Truth is bad for business. We all like to lie and sound solid than say the truth and not really know when we'll finish because we don't really know what is being wanted (see point 4). So...

We agree to deliver in three months. We sit down with our client, but then their people start getting stuck in other things which are not this solution. It turns out we hit the "oh, yes that too" phase. More intricate things come up. The software has to do more than expected. We need to change stuff and meet again. We already at four months and still expect a month extra work.. The other team (client) has launch of something else in two weeks. Interaction drops, etc., etc., etc.

I think everyone here has been in such spots once (at least). So even in a perfect Agile environment you're bound to hit into complications. Complications that have nothing to do with programming and skills. In such situations tools are the do or die because they define how well you can respond to points 3 and 4 and to a lesser degree 2.

I really can't make a compromise between individuals and tools. They are equally important.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gerardo Tasistro:
I really can't make a compromise between individuals and tools.

And neither is the manifesto suggesting you should. It's "over", not "instead", remember.

Originally posted by Gerardo Tasistro:
They are equally important.


Are they really?

If you'd have a choice between getting one man develop you a piece of software using nothing but Notepad and getting one PC loaded with all best of breed tools but no developer, which would you reckon gets the job done faster?

That's a ridiculous scenario I'm describing but it's not that different from saying that tools and individuals are equally important. The thing is, such comparisons don't mean much without a specific context. The context is what gives us the means and ability to decide what's more important than what.
 
Gerardo Tasistro
Ranch Hand
Posts: 362
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Lasse Koskela:

If you'd have a choice between getting one man develop you a piece of software using nothing but Notepad and getting one PC loaded with all best of breed tools but no developer, which would you reckon gets the job done faster?



Well I recall the comparison was originally done with an inexperienced not inexistant developer, but anyway I'll explain my position.

I believe people can better themselves so a poor developer will become better over time. I believe tools don't become better over time. Notepad will be notepad until you install something better. And no matter how much you use notepad it will continue to be notepad. Yet the programmer will improve over time. Be it with notepad or the best IDE.

Software is cheap compared to developer time. Set a price for a development tool. It will be nothing compared to the monthly wage and productivity of the developer. Contrary to the other points (more to 3 and 4 and less to 2) which seem to counter themselves in time and resources. Documentation seems to take away from programming, negotiation delays colaboration and hence development and sticking to a fixed plan can lead you astray from the real useful objective. But processes and tools? They don't counter individuals and interactions. They foster them.

I also believe tools help you become a better developer. Today's tools do so much they help you keep your mind away from the code and on what the code is supposed to do. Lets not forget a language is also a tool as much as the tools used to develop in the language are. You don't use the wrong language for a project. Why not use the right tool for the right language too?
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gerardo Tasistro:
I believe people can better themselves so a poor developer will become better over time. I believe tools don't become better over time. Notepad will be notepad until you install something better. And no matter how much you use notepad it will continue to be notepad. Yet the programmer will improve over time. Be it with notepad or the best IDE.


Fully agreed.

Originally posted by Gerardo Tasistro:
Software is cheap compared to developer time. Set a price for a development tool. It will be nothing compared to the monthly wage and productivity of the developer.


True. But even the best tools won't make him a super programmer overnight and the biggest problems on a software project's are likely not mendable by better tools--or super programmers for that matter.

Originally posted by Gerardo Tasistro:
But processes and tools? They don't counter individuals and interactions. They foster them.

Exactly, when used right. And I'm sure you've seen organizations where corporate tool selection and prescribed processes are slowly and surely eating away on software development teams' productivity. The statement in the manifesto hints at individuals and interactions being the number one priority and that tools and that, as you said, processes should foster them.

Originally posted by Gerardo Tasistro:
I also believe tools help you become a better developer.


Yes, that might very well be the case, and I agree with that other stuff you're saying. I just think that tools play a supporting role while the people and how they work together are starring the film.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I read people and interactions over proccess and tools through the lense of painful experience. Some processes replace communication with tools. Analysts communicate requirements to developers through a requirements database instead of telling a story. QA communicates bugs to the developers through a defeect tool entry instead of sitting at the app together and asking why it does something unexpected.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Gerardo Tasistro:
Yet the programmer will improve over time. Be it with notepad or the best IDE.



Whether or how much a programmer improves, or even how much he is able to work to his abilities, depends very much on the working environment. Is he sitting in his cubicle, isolated from the rest of the team, or is he pair programming daily with people he can learn from? Is he working in an environment where it is save to experiment, to make mistakes? Is he given the resources to reflect on what he is doing and where he can improve?

All of this, again, is much more important than which IDE he uses.

Software is cheap compared to developer time. Set a price for a development tool. It will be nothing compared to the monthly wage and productivity of the developer.



Very true. And noone is saying that you shouldn't use tools, or that tools are unimportant.

But processes and tools? They don't counter individuals and interactions. They foster them.



I don't see where the "counter" is coming from.

Anyway, some tools foster individuals and their interactions, and some counter them, sometimes. For example, a bug tracking software can easily be used to reduce the amount of interaction between users and developers. The Manifesto reminds us to pay close attention to such effects.

And some processes actually treat developers as replacable code monkeys - if they just use the right tools, and follow the right process, everything will work out fine. The Manifesto reminds us that imposing tools and processes on randomly selected people doesn't work well - you need to carefully form a team, and than let the team select the tools and processes it wants to use.

Why not use the right tool for the right language too?



Please do so. We are all for it.
 
You firghten me terribly. I would like to go home now. Here, take this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic