As an Agilist, I have watched Agile move from small teams of developers to larger and more encompassing activities in the organization the following fact began to emerge.  Agile is not for development, not ‘real’ Agile that is. Most of the projects I have seen are over in 6 to 8 months or between 12 and 16 iterations.  Most teams don’t start to to really hit their stride until around the 6th to 8th iteration.  The team members trust themselves and each other, the IDE they are using is smooth, CI is usually in place and the team is pretty self sufficient.  ScrumMasters are sitting around looking for work and the PO is moving along. more »

Somewhere along the way Agile – and Scrum in particular – decided (or forgot) the fundamental difference between incremental work and iterative work.  For some reason that is not clear to me, the two terms became synonymous antonyms where one was all good and the other all bad and at the same time could be used interchangeably.  Admittedly my recollection of this is skewed from being addicted to the scrumdevelopment group for which I am going to find a 12 step program.
But that is another Blog.
Back to Incremental and/or Iterative. First they are neither synonyms nor are they antonyms but most of all they are not interchangeable.  Incremental work is work that can reliably build upon the last deliverable or the last iteration.  It lives in charted territory.  For that reason it is fertile ground for all the neat things one can do with Lean and CMMI stuff like that.  In addition to these good ideas there are other processes, fads and gimmicks that also purport to make things better smarter cheaper faster easier and brighten your teeth while turning your hair back to the color it was before it fell out.  They may but the jury is still out and the panel may be in need of CPR in order to survive.
Now the strange thing is that iterative is all about what incremental isn’t and that is because iterative work is work that in all likelihood will be tossed out or only snippets of it will move forward.  Iterative work is the land of fail often fail fast and succeed quickly. It tries very hard not to be repetitive because the odds are you don’t have to keep on making the same mistakes over and over.  It is for that reason incremental processes like Lean and CMMI come out looking like those fads and gimmicks and this may be why some people are leading thinkers to accept that iterative is bad.
Sorry, would you mind taking that down the hall and seeing if some there wants to swap a bridge for that idea?  Iterative is the innovation engine.  In ‘the Day’ it was what we called the BIG R for research.  Of course this is back in the dark ages when R&D was valued and people actually worked using things like Scrum and Agile before it was copyrighted and marketed and certified.  Believe it or not people actually used to get paid to make lots of mistakes and hit it right once or twice in their careers.
So what did we know back then that has been lost due to modern management techniques and an economy that suffers from quarterly A.D.D?  First you iterate until you stumble across something that works and then you incrementally improve it until you totally screw it up.  If you work for a really good company someone will have been mucking about iterating on how to do it in a much better way and you will be able to latch onto it and claim you are doing best practices.
I hear something coming in from left field!  Let’s do both at the same time and that way be innovatively efficient!  Now, let’s cut this one off at the pass.  No you cannot do both at the same time because it is task shifting (a no no for you incremental lean types out there) and it is BORING if you are a dyed in the wool iterative worker.  Can you shift between the two types of work?  Sure, that makes sense as long as you work in a place that knows the difference and applies the appropriate metrics to it.  OOPS there are not many metrics in iterative work other than the Edison algorithm (success was measured in finding out how many items made lousy filaments for light bulbs and the answer was 8000 with only 1 failure when bamboo kept on going, and going, and going.)
So if you want to debate this come to the Agile conference and see if this actually makes it as a discussion.  Better yet go make great comments on it at the agile2009 site.  But until then remember that Incremental and Iterative are a fork in the road for Agilist and make sure you know where you are or you could get killed.

I have spent a good portion of the last 15 years trying to go back to the future. For the first 15 years I worked in companies where Quality was paramount and their common approach shaped my thinking and actions. Names like Fisher Price, Parker Brothers, Eastman Kodak, Wang Word Processing, speak to the power and importance of quality. With their respective demise I also learned another important lesson about quality. It is not just about how well the product is built. It is the value the product adds to a customer’s quality of life that separates a fad from a staple. This, it turns out, is the one item I have found that moves business and management to understand the importance – to their success – of having quality at the front of the train. more »

I guess the most recent spamit was ‘that straw’. Some beltway bandit spending a lot of flash money to make it sound like they had ‘the answer’ for a mere $500 and your soul to some highly regarded, deeply entrenched, piece of BDUF tool. I do not doubt for a second they will be successful on this side of the chasm, because we all buy into the notion that if it is in a PowerPoint, then it must be true. What a line of preprocessed plant food comes out of those projectors these days. There was a time when the Agile community had stuff to say because everything that was talked about was based on experience not on flights of logical fantasy. Gee we even had a name for it – hmm how that go, Empirical versus Deductive analysis. more »

This post is an excerpt from an on-going conversation at http://tech.groups.yahoo.com/group/agileleadership.

I have been asking for comments and perspectives about leadership, traditional management, Agile Leadership and so on.  The thread is well received and i wanted to bring this element to this community as it begins to address places where all sides seem to converge.

Glen Alleman wrote:

I’ve started speaking of non-agile project management is bad (or poor) project management, since responding to the emerging situation is part of good project management – as defined in PMBOK. Therefore not responding is bad. I’ve started using “conventional” to distinguish the processes used in many locations to great success. Agile and Conventional are certainly different. Non-agile is non-functional and therefore a nonstarter for success.

Ron Jeffries responded:

Would that more people believed that.

From my perspective;

I think Agilists differ from conventionalists in that they put Respect and Leadership over Rank and Management, and make this distinction transparent.

Perhaps one of the key attributes of an Agile Leadership environment is the passing of the leadership position to the person the team trusts most to address the issue. This fluidity, seen in ‘self organization’, pair programming, and most dynamically in planning sessions seems to become the bonding agent of the team.

Now does this translate into organizations. I think the answer is yes, but the result is a new management process that goes to the top of the management and stakeholder organization. We have mentioned “Corps Business” and some of us have delved into OODA, the three block war, and I have seen some organizations make steps toward this.

What I think I am seeing is the trust component of leadership and followership extend into the management of the organization and manifest itself in Management retain Control of the plan and teams of people at the lowest level in the organization take over Command of the situation. The Middle part of the organization exists to serve both those above and those below by clearly defining, the mission statement and the commander’s intent; advising those above on the capabilities and limitations in meeting those statements and intents and removing the impediments facing the teams as well as shepherding the solutions to the needs and requests of the team as they encounter unpredicted, emergent challenges.