Actually agile by its nature needs to be formal to prevent from falling into chaos.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Now, Agile processes presume that such formality is suboptimal, that the team needs to define and follow a set of agreed upon practices, but that those practices also need to be adjusted on the fly based on current needs.
Reid - SCJP2 (April 2002)
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Originally posted by Ilja Preuss:
First I'll have to explain what I mean by "formal". The best definition I've found for this context is "being in accordance with rules explicitly established prior to use." (Gerardo, if that is not what you meant, please clarify.)
Originally posted by Ilja Preuss:
Now, Agile processes presume that such formality is suboptimal, that the team needs to define and follow a set of agreed upon practices, but that those practices also need to be adjusted on the fly based on current needs.
Originally posted by Ilja Preuss:
So an Agile process isn't, at its core, a set of roles, documents and workflows that an Agile team follows - it is a set of values and principles that guide the team - supported by a set of practices that are a good starting point to implement the values and principles, and that the team can use to derive it's own set of practices.
Originally posted by Ilja Preuss:
So an Agile team certainly will have some ceremonies that are closely followed, and that team members take care of that their partners keep true to. But those are not followed because of formality - because it's the process that says you should do these things. It's because the team members feel that it's important to do those things to reach their goal.
Originally posted by Ilja Preuss:
Speaking of formality, especially if demanded by some regulation, I think it has a high probability of reducing the teams Agility. The reasoning is simple: the formality reduces the teams ability to choose the optimal set of practices, and as the formality is defined by someone outside the project, it has a high probability of not being optimal and thereby producing waste.
Originally posted by Ilja Preuss:
Formalities also most often define a form of communication that isn't face-to-face, and might even *replace* face-to-face conversation that would take place otherwise. Again this will cause a drop in Agility.
Originally posted by Scott Ambler:
As to the FDA example, having worked in a couple of organizations where this is applicable I took the time to familiarize myself with the regulations. Nowhere in them does it say you need to be inefficient, however, the so-called process experts invariably tend to interpret them that way.
Reid - SCJP2 (April 2002)
Originally posted by Gerardo Tasistro:
But the lack of formality can free the team's ability to choose sets of practicies.
Leading to the case of spending more time choosing than doing. Without a formal lockdown of these practices you might end up producing nothing.
Yes, but here the problem isn't formality. It is the improper choice of ways to communicate. You could very well be formal about "we have to have face-to-face conversation".
If you have a bad leader that establishes a formal requirement of means of communication which are not "face-to-face" or which replace "face-to-face". It is not an issue of "formal", but an issue of "bad leader". The same bad leader can, ouside a formal setting, establish bad requirements. And without a formal lockdown. He can soon enough change those for another set of bad requirements.
Or better yet! Going against all invariance studies, norms and procedures. He can change a bad requirement to a good one and at the same time change another bad requirement he set for yet another bad one. Half-way down the road nothing works (as usual) and he (erroneously) concludes both changes were bad. Leading to a change of both the good and the bad.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Gerardo Tasistro:
I think that while you might use informal UML or informal documentation or come in casual wear instead of suite and tie you are definetly formal in your process.
Your UML might be informal but you do make diagrams (diagram making is a set process of a formal procedure you have, along other things you listed in a post a while back).
You have a formal set of TODOs while the doing of them might not be so formal.
To better exemplify this I think I'll turn to genetic algorithms. Which is something I find similar to the Agile case.
True, very true. But the fact that they're not written down doesn't mean they're not formal. If those sets of values, principles and guidelines were not formal then Agile could very well "mutate" to non agile or cascade development or better yet sheer chaos.
If these "ceremonies" are not formally established then how do the team members know (in a crisp way) what they are?
Without a formal established set of "ceremonies" how does the project leader know everyone is pulling in the same direction?
By talking to the team regularly. For example in the daily stand up meeting.
While an experienced programmer like you will know this an unexperienced one can not. The unexperienced one will require this writen down or worked at. But the fact that its on paper or not doesn't make it less formal.
As a matter of fact, we just got a new team member this month. I guess he will learn most of this simply by working together with us. Why shouldn't he? He is sitting with us in the same room, most often together with one of us on the same computer, pair programming. How would he *not* learn (and at the same time influence) how the team works that way?
Without these "formal" guidelines an agile developer can start to "reinvent" the processes in the name of agility. Thus spending enormous time in senseless ventures with a label of "solution space exploring" or something like that.
He could do that. But what would he tell at the daily stand up meeting, where everyone shortly explains what he did, and plans to do? Wouldn't he have trouble explaining to the rest of the team - and the stakeholders - what is spending his time with?
Without a set of "formal" rules in agile development the "eternal designer" can get away with it. If his concept of agile development is like a genetic algorithm which allow anything to change including the algorithm itself then he can alter the "set of values and principles that guide the team" and the "set of practices that are a good starting point to implement the values and principles".
No, he can't. The set of practices is defined *by the team* and validated by the development of Running Tested Features. A developer who doesn't contribute to a working feature at the end of the iteration had a hard stand in an Agile team.
Some programmers are just lazy and they think they can cut corners by calling it Agile and skipping processes.
Those programmers need to be educated, or separated out. Often the former will suffice.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Out of curiousity, Scott, in the situation you described was the resulting process ever audited? I've heard other stories about attempts to lighten the process burden for regulated development before, but when you ask the question "so, how did the audit go?" the answer has been "we haven't gotten to that point yet".
<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Originally posted by Gerardo Tasistro:
I find it odd that you say it isn't formal yet compare Agile with a system which has rules.
You quote a site which establishes a mechanism for this. http://www.xprogramming.com/xpmag/whatisxp.htm
Please note the "core" tag before "practice". Meaning it is not an addon feature, but a central part of the system. The author is clearly establishing formally what XP is.
There has been a long period in XP where the discussion has been around what you have to do to "be XP". Early on, I thought, and others of us thought, that you had to do all the practices to be doing XP. For the past three or four years, though, I've been saying that there is no meaning to the phrase "doing XP". XP is not the kind of a thing that can be done or not done. XP is an understanding that one has, to some extent.
[...]
To me, XP is a set of notions that inform my actions. [...]
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
That is a page for beginners to XP. People need (and typically search for) cook book approaches to things they are new to.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |