Again, conversations give me a zillion things to write about.  The recent conversation that has cropped up again is my various viewpoints of the Agile Manifesto.  Not all the processes that came after the manifesto was written, but just the core manifesto itself.  Just for context, here is the manifesto in all the glory.

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Several of the key signatories at the time went on to write some of the core books that really gave Agile Software Development traction.  If you check out the Agile Manifesto Site and do a search for any of those people, you will find a treasure trove of software development information.

My 2 Cents

First off, I agree with a few people out there.  Agile is not Scrum for instance.  Do NOT get these things confused when checking out Agile, or pushing forward with Scrum.  As David Starr points out in his blog entry,

"About 35 minutes into this discussion, I realized I hadn't heard a question or comment that wasn't related to Scrum. I asked the room, How many people are on an agile team that is NOT using Scrum?

5 hands. Seriously, out of about 150 people of so. 5 hands."

So know, as this is one of my biggest pet peves these days, that Scrum is not Agile.  Another quote David writes,

"I assure you, dear reader, 2 week time boxes does not an agile team make."

This is the exact problem.  Take a look at the actual manifesto above.  First ideal, "Individuals and interactions over processes and tools".  There are a couple of meanings in this ideal, just as there are in the other written ideals.  But this one has a lot of contention with a set practice such as Scrum.  There are other formulas, namely XP (eXtreme) and Kanban are two that come to mind often.  But none of these are Agile, but instead a process based on the ideals of Agile.

Some of you may be thinking, "that's the same thing".  Well, no, it is not.  This type of differentiation is vitally important.  Agile is a set of ideals.  Processes are nice, but they can change, they may work for some and not others.  The Agile Manifesto covers the ideals behind what is intended, that intention being to learn and find new ways to build better software.

Ideals, not processes.  Definition versus implementation.  Class versus object.  The ideals are of utmost importance, the processes are secondary, the first ideal is what really lays this out for me "Individuals and interactions over processes and tools".  Yes, we need tools but we need the individuals and their interactions more.

For those coming into a development team, I hope you take this to mind.  It is of utmost importance that this differentiation is known and fought for.  The second the process becomes more important than the individuals and interactions, the team will effectively lose the advantages of Agile Ideals.

This is just one of my first thoughts on the topic of Agile.  I will be writing more in the near future about each of the ideals.  I will make a point to outline more of my thoughts, my opinions, and experience with the ideals of Agile and the various processes that are out there.  Maybe, I may stumble upon something new with the help of my readers?  It would be a grand overture to the ideals I hold.

Agile is the popular process du jour these days.  Every time I hear "Yeah, we do Agile" or "I know Agile, been doing it for years" I cringe.  These statements are spoken with the idea that Agile is this steadfast, unchanging, unalterable, single process that everyone is following.  It is often spoken without any knowledge of the history of Agile, the people who signed the manifesto, or what the true ideal of Agile is.

Agile is always changing, will always be changing, and we'll most likely all be new to it all the time.  Agile is something that flows differently for each group that tries it, but there are core tenants that must be met.  These tenants aren't part of a "process", but could be, they aren't part of a "method", but might be a result.  The point is, nobody really knows Agile, they know their team.

...or maybe they don't know their team if they think they know Agile?

That is something to seriously ponder.  So how does one know when they're talking to someone who really does adhere to the Agile Manifesto.  This is actually the simple part.  Generally they won't even mention Agile at first, but instead they discuss processes almost immediately.  Things they do to enable the developers, things they do to maintain velocity and keep things upbeat and positive.

Some of the first signs that a shop is truly Agile can be summarized by the answers to a few questions.

1. Does the team always have working software?
2. Can you regress and refactor quickly?
3. Do iterations ending or burn down charts stop velocity?
4. How many hours a week is the average?
5. How often does the team have to work excess hours?

...and one of the most important questions of all...

6. How often does your team get to speak with customers?

Does the team have working software?  If it doesn't, it's probable that they are not Agile, or not quit Agile yet.  A team needs to have working software.  The only lgeitimate excuse I've ever heard is, "we started yesterday and are a few days away from working software".  But even then, there should at least be some paper prototypes, or discussion notes with the customer about the proposed working software.

Once there is working software, how fast can the team regress and make changes?  How fast can the team refactor?  How often is the technical debt paid down?  This is a major sticking point that I hear a lot.  Teams must maintain testing, regression, and the ability to refactor.  The team must refactor regularly and keep the debt paid down, if not, there isn't a reserve entity out there to pay down the technical debt or provide a stimulus!  Without these things a team is running rough of Agile.

At the end of iterations does the team stop completely, take a breath of fresh air, and prepare for the hike up the mound of progress again?  If this happens, something is definitely wrong.  Iterations aren't supposed to break progress, merely reflect and maintain veloctiy.  This is where I've become more and more a fan of lean style or kanban style.  The hard stop that iterations often incur is very detrimental to velocity and sometimes even to morale.

Speaking of iterations and mounds of progress, how many hours are worked for that progress?  Are the hours consistent and maintainable?  If not, they should be.  Beware the other inconsistency of trying to apply 40hr work weeks to everyone.  Some people can do 40 and some can do 50, the key is to maintain velocity and maintain morale.  If one person does 50 hrs per week, great, make sure they're not burning themselves out.  Make it easy for them to maintain that.

The customer?  "What, we have to pay attention to the customer?", is a statement I heard recently.  I can't help but just look down whenever I hear this, at least when it is spoken seriously.  The development process and software process should NEVER get disconnected from the customer.  The industry as a whole learns this lesson over and over and over again each year.  We should all now know, we must stay in communication with the customer.

With all those thoughts, I leave this entry with a question for everyone, "Is your team really Agile?"

In my humble opinion, as long as a team is working on acheiving and getting these key points in place, all is good.  If not, the team should probably reflect a bit on what the end goal is.

For efforts were I've seen Agile, a good close to true Agile Process in place, I've seen solid progress and generally good success.

Everything else has generally been a complete failure.  Schedules aren't met, money objectives are screwed up, projections are lost, quality is crap, and the list goes on.  When I say Agile I don't mean pair programming, or scrums, or reducing defects, or any of that.  What I mean is a good solid mix of ALL those things.  Without measurability, without continuous integration, without solid developers, without some pairing (i.e. at minimum regular communication), without daily stats/scrums/stand ups/or whatever one calls em, with defect reduction, there really is not progress.

For the life of me, I cannot figure out what the resistance is to Agile Methods.  I understand there is this whole bandwagon issue, that people tend to shy away from bandwagons when the posers start pushing the ideas.  But I must say, look past the hoopla and find out what Agile really is, read about what the processes were designed to combat.  There is a reason they exist, there is a reason why these methods are better in almost every way than anything else that has come up in the industry.

If you can't join an Agile team, read about them.  If you can't run an Agile team, read about running them.  Eventually you'll find yourself in better shape to get into or run an Agile team.  You'll also find yourself becoming more and more of an advocate for the specific processes, ideas, and the intentions behind what is outlined ever so simple and eloquently in the Agile Manifesto.

...

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

...

On that note, we developers have recently fallen down more over a few of the key elements here.  Customer collaboration and responding to change have taken a back burner priority lately and that, simply put, sucks.  We've slowed because of it, mind you, we had to back track on design and implementation for some major pieces of the application with refocused us on working software.  The problem is, we inherently missed interactions and iterations because of it.

Basically we've slid right off of a solid path toward a good Agile effort.  We're working to get it back in line and I need to tighten the belt and quit being a slop about it.  The developers, including I are primarily responsible for making sure things go well and we need to get back to that.  We need to make sure we get back on iterations, we need to make sure we have the collaborate and the good response to change.

Over the next few (that's 3) weeks we'll be getting things back on track.  Just a minor derailment, no train wreck at all really.  But here are some bullet point items that we're planning on doing to get moving faster once back on track.

• Brown Bag Lunch - Basically we're planning to cover topics to explain functional pieces of code that have been built but others might not be familiar with.  i.e. If someone built some cool service factory tweaks, they would do a quick 10 minute description, we'd discuss, eat some good grub, and then commence to refactor were appropriate to properly utilize the service factory.
• Code Review - We started this somewhat, but we need to extend it to some honest to goodness pair programming code reviews.  Doing on the spot fixs, refactors, etc to really get things understood and cleared up so no confusion occurs.  This will also be a good time to get into practice for KISS, DRY, YAGNI, and other checks of that nature.
• Working to clean up and provide a well defined installation file for regular drops for customers/boss/users to play with, test, and provide accurate feedback with.
• Clarify the need, or lack of need at this time for separation of concerns (SOC) past were we have them separated currently.  Along with that we'll be defining better our boundaries around coupling and our acceptance of were we'll be tightly and were we'll be loosely coupled.

...I'll have more on all this, some of the descriptions, conversation points, and other information in regards to the above Agile Manifesto and how it relates to project success.  I also want to, along with another million topics, write up something in relation to coupling...  hopefully I'll get to it all at some point.