Hi, ... Can I ask if you assign tasks to people in the planning meeting? For some reason it sounds to me like you do. I d recommend against that practice and
Message 1 of 53
, Aug 2, 2009
> > Are there other developers on the team? Are they working in the same
> > codebase and do they make reasonably good estimates?
> They do. They have all been working here for several years though.
Can I ask if you assign tasks to people in the planning meeting? For some reason it sounds to me like you do. I'd recommend against that practice and only pick tasks in the daily Scrums (and signing them up there).
This way everyone can participate in all estimations, and the differences in people's skills are averaged out in the overall velocity. Effectively the task estimates become "relative" estimates and thus would technically also have a "velocity" (but ignore that in reality :) ).
Pairing up was also a very good recommendation to speed up this guy's learning.
> I should also mention another issue with the task cards. In the sprint
> planning we split larger stories into tasks. Usually the more experienced
> developers do this. If he does it he usually splits them into 2 cards
> analysis and implementation.
Ouch... Sounds like mini-waterfalls to me. Instead, try to think, at that stage, the overall design for the story and pick the tasks from that design. Everyone should participate in this activity.
> They never get updated during the story. He
> says he would really like to be able to know before hand exactly what tasks
> should be done but all he can do is try stuff until its done. Eventually
> the story is complete, and we ask why he didn't update his task cards he
> answers "because up until 5 minutes ago I had absolutely no idea if it
> would take 5 more minutes or 5 more days, or whether my current strategy
> would work or i would have to undo it all and start again"
This is all very reasonable, given the context.
Again, "sounds to me" like you are developing a little too early. I'd clearly differentiate between "research" and "development". To me, development is turning pretty well understood stories into concrete code (which is subject to definition of Done). Research is turning loosely defined stories into "pretty well understood" stories. If possible schedulewise, I'd recommend doing those in different sprints. The research can be considered either as "spikes" (stories which don't deliver any code) or as a reserved budget of time in each sprint (like the 10% time reservation for "grooming" the backlog, as suggested by Schwaber).
So, I'd ask the developers to collaborate with the PO a little in advance to do some research on stories that are high enough to be potentially included in the next iteration. I'd recommend doing simple technical tests and some simple design work, so that they actually can effectively split the stories into tasks in the planning meeting.
Effectively, this approach should kill majority of the "because up until 5 minutes ago I had absolutely no idea if it would take 5 more minutes or 5 more days, or whether my current strategy would work or i would have to undo it all and start again" arguments, because exactly those things should be found out in the research part. Just challenge the team to think what is the fastest and least time consuming way of answering those questions, and then doing that and nothing more. There is no guarantee against surprises, ever, so "over-research" is not likely to be very useful to you.
Process Development Manager, Agile Coach (CST)
Digia Plc., Finland
Message 53 of 53
, Aug 6, 2009
<<I'd be interested in talking more to you about this sometime. You'll likely have to step down to ground level for that conversation though... and I'll take off my scientific dress-up clothing ;-)>>
Well, that's probably one of the side-effects of using scientific terms: a scientist may be listening and assume you're talking about science ;-) I'll consider this discussion over by now (and I do consider it's way off-topic for us to continue it on this list), and, should we ever have that discussion again in the future, be sure I'll try to do it in a less pedantic and over-the-top way.
The thing is, take these amazing ideas out of the domain of pure science theory, throw them to the masses and they allow people like me to see the world in entirely different ways. And that is a wonderful thing.
I'd be interested in talking more to you about this sometime. You'll likely have to step down to ground level for that conversation though... and I'll take off my scientific dress-up clothing ;-)
Pablo Emanuel wrote:
I didn't intend to sound rude, I'm sorry if I did. I haven't read the book, and I have no reason to believe it doesn't get to valuable conclusions. My only point being that terms like Quantum, Chaos, Self-Organization and Complex Adaptive Systems are ways to make a theory sound scientific, even when the reasoning itself doesn't ever come close to the theories whose names are being used. For instance, the arguments:
Self-organized teams are more efficient because self-organized systems like ants and ecosystems have proven to be efficient.
Strange attractors are not adaptive, but they they do cause a system to change, sometimes in unexpected ways, hence we need to embrace our fools.
are just fallacies dressed in scientific terminology.
IMO, the connection between Agility and Chaos is close to zero. Chaos requires exponential expansion (sensitivity to initial conditions), I can't see how it may happen in a SW dev team.
The only way I can see the concept of chaos being used in this context is in a more metaphorical sense, of learning from dynamic systems that both too much regularity and too much chaos are too robust, and systems at the edge of chaos have better chance of adapting. But, to get to the same conclusion, we could use other analogies, such as the four elements (that's used, for instance, by Harrison Owen, the creator of Open Space Technology), with, IMO, more meaningful consequences (e.g. besides the Earth-Air axis - order X creativity, we have the Fire-Water axis - assertiveness X emotional safety).
Subject: Re: [off-topic] Re: [scrumdevelopment] CAS [was Developer barely estimates...]
To: email@example.com Date: Wednesday, August 5, 2009, 5:32 PM
judging only by the author's bio, I may be wrong, but my bulshit-o-meter is beeping. Not that the book's conclusions are necessarily wrong, but probably the mathematical concepts are being applied well beyond their original context and meaning. Chaos is one of the most abused terms these days, second only to quantum.
I must infer from what you wrote that you're trying to apply concepts from one domain you know only superficially (dynamic systems) into another (team dynamics), and you're being mislead by some words that, although having ordinary meanings, are overloaded to mean very specific things on the specific domains (this is what the Jains call Sabdanaya - mistake one concept for another only because they have the same name). Since this domain is exactly the domain I've studied for 6+ years (my unfinished PhD thesis was about the formation of infinitely many attractors and persistent 0-Lyapounov exponents near high-codimension homoclinic bifurcations) , I felt obliged to clarify some of these misunderstandings.
Strange (AKA chaotic) attractors do not "draw order to themselves". They're called attractors because nearby orbits (inside the attractor's basin) converge to the attactor (so, the only thing they "draw to themselves" are orbits), and they're called chaotic because, inside the attractor, orbits diverge exponentially (= positive Lyapounov exponents), which leads to the so-called butterfly effect (points that start very near end up being very far, exponentially fast). What's said about chaotic systems having order is mainly because of the fact that the exponentially expanding behaviour in terms of individual orbits implies that probability distributions converge exponentially to a Sinai-Ruelle- Bowen probability distribution. That is, if you start with an arbitrary distribution of probability (e.g. the same probability to be in any part of the space of events), and iterate it (i.e. given that a point had that given probability distribution in the beginnning, how probable is it to be in this certain portion of the space after a certain amount of time), it will converge to a specific probability. In other words, dynamic repulsion leads to ergodic convergence.
Of course, I've only wrote all of this to give a hint on how much theory is there on the subject, and that chaos, order, strange attractors and other terms have well-defined meanings, and they have very little to do with the use you make of them. If you want to say something about high-creatitivy- low-organization individuals being necessary (or at least beneficial) to the team, please don't use terms that have nothing to do with it. I've proposed a more meaningful metaphore (the four elements) that is more in line with the intended use of the terms. If you describe your high-creatitivy- low-organization individual to an astrologer as a Airy person, he will understand it; if you describe him as a strange attractor to a dynamicist (such as myself), he will have a hard time trying to figure out what the heck you're trying to say.
Regarding your statement about CAS, I definitely agree that human beings are CASs, which *does not imply* that systems composed of human beings are a fortiori CASs. Distributed organization does not equal self-organization. A system exhibits self-organization when the high-level order emerges *from the system itself*, not from his components. If the order is imposed to the system directly at the high-level, it's not self-organized. One example of a human system that *is* a CAS is the economic market - each economic agent, individual people or companies - is acting on very local objectives, but a high-level order (cyclic crises, etc) emerges from this multitude of individual acts. One example of a human system that *isn't* a CAS is a team of software developers. All the order in the system comes from people trying to impose order to it, regardless of it being one central organizer or several people, each one giving his individual contribution. It would be self-organized if each person decided to do something other than develop software in a team (e.g. type good-looking ASCII art, and show it to the greatest number of people) and somehow, those individual actions fitted together nicely to form a software development team.
I could go on for hours on each of these topics, but I'll probably settle for including it on our list of things to discuss face-to-face over a couple of beers someday.
A strange attractor "draws order to itself out of seeming chaos". Strange attractors are not adaptive, but they they do cause a system to change, sometimes in unexpected ways. Chaotic systems need them if they are too converge towards any form of order at all -- and I am talking inherent order, not imposed order. A system with imposed order is no less chaotic (perhaps more) than one without, it is just buried.
You lost me a bit in your science and new-ageism, but I challenge the idea that software development teams have nothing to do with CAS. I'd argue that every system that includes humans is a CAS.
Pablo Emanuel wrote:
just an off-topic correction to your post - strange attractors are not "adaptive". They're dynamically robust, since all their Lyapunov exponents are non-zero (exponential repulsion inside the attractor and exponential attraction outside the attractor). Adaptation (in the sense of complex adaptive systems) require (stable) Lyapunov exponents equal 0. That's why complex adaptive systems are said to be "in the edge of chaos" (periodic non-chaotic attractors have all Lyapunov exponents negative, chaotic [strange] attractors have a mix of positive and negative exponents and adpative systems have one or more 0 exponents). I would also have to argue again that software development teams have nothing to do with Complex Adaptive Systems, but that would make this off-topic post way too long.
Other than that, I patially agree with your post, and that has something to do with the blog post I wrote in response to Ilja. Poka-yoke, lean methods, Scrum, or any methodology whatsoever are related to the element Earth, whereas creativity is related to the element Air. Too much order is not desired when you need creativity to bloom (that's probably what Nietzsche had in mind when he wrote "One must still have chaos in oneself to be able to give birth to a dancing star"). However, Air alone doesn't generate concrete results, so you do need Earth's methodology to transform Air's ideas into tangible outputs (put too much Earth too early, and you are too far away to chaos, put too little too late, and you're deep into chaos, in the right time and quantity, bingo, you're on the edge of chaos).
This appears to be another example of a good manufacturing idea becoming a very bad idea when applied to a creative process. There is, and can be, no such thing as a fool-proof process in software development. Complex Adaptive Systems are full of fools -- they may be the strange attractors required by the system for growth and adaptivity, for evolution. Embrace your fools, let them loose! Please don't proof against them.
Pablo Emanuel wrote:
actually, the Lean concept of poka-yoke (http://en.wikipedia .org/wiki/ Poka-yoke) is about the process *not allowing* people to make mistakes. Not in the sense that the process requires that people doesn't make mistakes, but that the process must help people not to make them. Examples of the application of this principle to SW development are Intellisense, TDD, Continuous Integration and automatic code generation. The process should prevent people from erring, and should they still err, must spot the error as soon as possible.
From a root cause analysis point of view, the error has two main causes: people make mistakes, and the process let them do it. Both causes should be addressed - people must be trained (or replaced, when the availability of people that makes substantially less errors doesn't justify the cost of training), and the process must be made fool-proof.
I haven't read that book yet, but I would assume that Petri slightly misrepresented the Poppendieck's position. I'd think it's much more about a process needing to *allow* people to make mistakes. A process
that requires people to be perfect simply is flawed. (I'd also say that a process should help people spot their mistakes and learn from them.)
> > > But that seems odd too. People do make mistakes -- all the time, and it is > equally imbalanced to blame the process for "allowing the mistake". What I > liked about your original post was that (I thought) I saw you taking that
> incident on its own merit, listening to the back story, and offering an > alternative viewpoint. To generalize and say that people don't make > mistakes seems that it might foster a different kind of blame culture, and a
> stunting of personal growth. > > My mistakes are mine, I may not like them, but I can choose to own them. > > Tobias > > > > Petri Heiramo wrote: > > >
> Hi Tobias, > >> That is an interesting, and very humane analysis of the >> situation. Thanks for offering this alternative viewpoint. I >> think many of us could benefit from looking beyond the "problem
>> individual" towards the process that is causing that dysfunction. >> New kinds of solutions then offer themselves. > > It's not actually my viewpoint :). I recently read the Implementing Lean
> Software Development by the Poppendiecks, and they very much spoke for > people not making mistakes, but the process being faulty for allowing such a > mistake to happen. I just applied it to the situation in question :).
> > I sincerely recommend that book to everyone here. > > Yours, Petri > > > >
------------ --------- --------- ------
To Post a message, send it to: scrumdevelopment@ eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment- unsubscribe@ eGroups.comYahoo ! Groups Links
Your message has been successfully submitted and would be delivered to recipients shortly.
Changes have not been saved
Press OK to abandon changes or Cancel to continue editing
Your browser is not supported
Kindly note that Groups does not support 7.0 or earlier versions of Internet Explorer.
We recommend upgrading to the latest Internet Explorer, Google Chrome, or Firefox. If you are using IE 9 or later, make sure you turn off Compatibility View.