Agile 2010 Wrap-up

Unfortunately, I was only at Agile 2010 for Tuesday and Wednesday due to family obligations. But, I was able to catch up with a lot of people during that time and take in a few really good sessions. I also presented a session myself (see prior post) and I got some really positive feedback. Below are some of the notes I took from some of the sessions I attended.

Dave Thomas' keynote on Tuesday

• When you are certified, you are useless, you just now have the body of knowledge in your head but it takes 10-30 years to learn how to use it.
• Certification does not provide confidence... this is what craftsmanship can overcome.
• Practicing leads to sub-cognitive action and muscle memory.
• You have a QA team because you didn't care enough at the beginning.
• If you can't do it with an index card, then you can't do it with fancy tools.

Effective Questions for an Agile Coach by Arto Eskelinen and Sami Honkonen

• Coaches exist to create awareness and responsibility.
• Don't inflict advice, ask questions, invoke change
• Good coaching questions cause exploration (what, when, how much, how many), aim at a descriptive answer, avoid judgment (how, who, why), and avoid an unproductive state of mind
• When tackling problems, use the G.R.O.W. approach (Goal, Reality, Options, What to do)
• Goal - describe desired state, insure it is high enough of a bar, be positive, be meaningful (what's in it for me), be specific
• Reality - are assumptions tested, explore different angles, expose feelings
• Options - existing ideas stated, limitations challenged, "stupid" ideas discussed

Great quote from a session when a team member was distracted - "I'm sitting out for this because I'm in the middle of deploying software... for the president... no... the President of the United States... yeah, we're waiting for Barack to login and accept the deploy." Yeah, he was serious!

Another great quote - "worst level of management" defined as "far enough away they can't help, but close enough to interfere".

Hiring doesn't have to be Random by Rod and Arlo Belshee

• Hiring is the most permanent change you typically make in your organization
• It's expensive
• Candidates have skills (learned), traits (personality), and behaviors (reflections of traits).
• Focus on traits by interviewing for behaviors
• Behaviors are data points for proof of traits you want (they can lie and say they have certain traits, you need examples, the more specific, the more real)
• Best assessed by doing, have them code during interview process
• Before interviewing assess your team for what traits they have. Determine what is required for a new person to fit in, and what you are missing that you need to find in a new team member. (What do you value - must haves, what do you need - additive.)
  
• Focus less on skills, this can be taught.
• Avoid labels, these say more about the interviewer than the interviewee and can lead to legal issues.
• "If you missed it in college, I can train you on the job, if you missed it in kindergarten, not my problem"
• Your team is a system with behaviors within a context. You can modify that system.
• Add a reinforcing capability.
• Balance out an excessive trait.
• Fill in a missing trait.
• Put the interviewee at east so you can collect data. Gang/Panel interviews don't do this, they could destroy your data collection.
  
• Why isn't your team talking about and defining what the team needs in a new hire?

Arlo's story about problem solving (and measuring level of problem complexity):

• A one beer problem is when you and another person go to the bar and drink a beer and quickly uncover the solution.
• 2 beers may help.
• Sometimes, it may take up to 5 or 6.
• After 6, it is clear that you need a higher distillation level.
• Try whiskey, it requires you to pass it around and share it (problem solving included).
• After 6 shots of whiskey, if you haven't solved the problem as a group, it's clear that additional alcohol isn't going to provide the necessary clarity.
• Time to switch to narcotics!!!
• Wait, maybe that's a sign it should be left to the professionals...

It was a great conference, as always, maybe next year I can present again and stay for the whole week.

Agile 2010 Talk: Agile Transitions- Cannonball and Stealth Approaches Exposed/Compared

Description: You've discovered agile and are excited! You are a leader within your team or company. Your next question is "How do I ignite this fire and get agile to take root in my organization?" After experiencing two extreme opposite transitions, I will tell the story of these approaches along with their successes, failures, and lessons learned. One transition occurred in a regulated global 50 company including offshore teams which dove headfirst into Scrum and XP within 3 months. The second is a stealth transition in a small .com startup company that is still ongoing after 3 years.

Time: Wednesday, 11 August 2010, 11:00 - 12:00

I've finished my slides and just have to do a few practice runs. If you are interested in this topic, then I'd really love to have you in the audience! I'm going to set up the talk with an overview of the two company environments and how each affected the potential of an agile transition. I'll then tell both stories, and end with the lessons learned from both. I've put a lot of planning into this one, so it will definitely be one of my best talks yet!

It's coming! (Agile 2010)

You can find my presentation summary here.

Is Agile a more humane way of working?

This was the question asked in the Agile Alliance LinkedIn group, and the question was focused on agile vs. other methods. It questioned whether the manifesto itself was written with the human element in mind, or whether it was focused on efficiency and outcome only (the human element being a byproduct). Additional points mentioned the 40 hr work week (as opposed to more) and sustainability.

The first three responses dissappointed me since they were non-answers.

1. I wasn't there, we can only guess (as if we've never heard the authors speak since then!)
2. I'm not sure, but it is at least more natural
3. Self direction creates a perception control and therefore happiness

Not being one to sit idly when there is an obvious answer, I had to state the following:

Yes!

The 8th principle of the Manifesto - "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."

BTW, many mature XP teams will peak around 35 hours, not 40. Pairing and TDD is very intense. You get the most around 35 hours, and productivity can start decreasing between 35-40. But this productivity is higher than the prior 45-50 hr weeks. I've both seen this and heard about it from others.

Cesario Ramos chimed in also:

The lean and agile thoughts explicitly make human values to be the center. It promotes an environment where every individual can use its potential for developing itself and its company. An environment where people can be part of a team and can contribute to a higher objective.

So in my opinion, YES, it is a more humane way of working. Even if the intentions of the agile approach are just to make more money.

There is that caveat that every idea can be destroyed and that there are plenty of companies that use Agile to get more hours out of their people. But, when I see this, I tell those that are suffering that their pain is inflicted by people, not by trying agile (and they aren't doing agile)!

My Overview of Agile Presentation (to a local PMI Chapter)

I was invited to give a talk about Agile to the Delaware Valley PMI Chapter on January 7th. The audience was going to be filled with local PMP's, some of which would be skeptics, and some of which would have been burned by bad agile implementations. I was worried about how to normalize their knowledge, and I had to do it in less than 45 minutes so there was room for Q&A.

Once I realized that I couldn't cram Scrum, XP, Lean training in along with a proven case study... I decided to go for the overview and provide them what they needed to find out more. I wanted the group to understand the Scrum is Agile, but Agile is more than Scrum.

As far as I can tell, the session was a success. I got positive feedback at the end, and I felt I made the most of our time.

If you want to get a copy of the slide deck, you can download it here. Since I'm not that popular of a guy yet, hopefully this won't overwhelm the daily bandwidth limits of my personal website traffic restrictions. If you get nothing, email me or put a comment on this post and try again tomorrow (and I'll have to move it to another host).

Having been through this experience, if there is anyone in the Philadelphia region that is interested in having me come talk about Agile or some specific piece of it... feel free to contact me. You can find many ways to reach me on my personal site.

We don't want you (yet)...

The Agile Community doesn't need more people who want to "go Agile"; it needs more people to successfully "be Agile".

I guess this is a follow-up point to my earlier post. We need to stop recruiting and start teaching.

Feed a man fish and he'll be hungry tomorrow. Show a man to fish, he'll feed himself.
Teach a man to teach others to fish, everyone will eventually feed themselves.

.... or something like that.

If you are an organization that makes money getting people to drool over agile and obtain certifications or take classes, but then your students can't successfully do agile... you are a parasite.

If you are an organization that makes money getting people to drool over agile and obtain certifications or take classes, and then your students successfully do agile... you are a teacher.

Subtle difference... are you a teacher or a parasite?
History speaks for itself. Go back and see what people have done in your wake!

What if Congress used Agile?

Eric Camulli posted this interesting question in the Agile Alliance LinkedIn group:

Could Agile help Congress with healthcare reform? I'd like to see someone take a stab at applying scrum principles to the "great development project" of our day...

Our country's healthcare "project" could end up looking like many Waterfall projects...not on time, over budget and not meeting customer's needs in the end.

Unfortunately the conversation quickly started to veer off into moral, ethical, and political opinions/viewpoints/jokes unrelated to agile...

But I thought about this a little bit and I did find some comparisons between our legislative system and large companies that aren't agile. Here is what I ended up writing:

I think the real problem with anything going through Congress is that they don't "go to the gemba". They rely too much on research and lobbyists to translate the needs of the "customer" for them.

Congressman act as if they are Product Owners, but they don't have the domain knowledge or "end user" interaction to truly own that role.

So... I guess my solution is that we need to find a way to decrease the feedback loop distance between those affected by policy and those creating it.

Does anyone else have any ideas or insight into this one?

The "decline" of Agile is our own fault...

I've been thinking about this for weeks. I'm still struggling to verbalize it. I could probably white-board it easily face to face; but I'm forcing myself to blog about it to see if anyone in the community reacts.

I'll start with the triggering thoughts first...

1. Martin Fowler gave me a new term at Agile East 2009 last week. The term is "Semantic Diffusion". He described this as the current trend of terminology diversity, dilution, and mis-use as agile has grown. He implied that it is the cost of growth and success of the movement.
2. I had a great conversation with J.B. Rainsberger while he was in Philly that same week. We discussed my thoughts and they intrigued him enough for me to continue pondering.
3. In the last year, I've had many a peer either complain about random factions in our community, or express a "loss of faith" in the movement at large. Frequently this is triggered by some new certification group or consulting firm charging high rates to "help" a group go agile with the wrong intentions.
   

I've come to the conclusion that Agile has NOT outlived its worth, its terms, or its time as seem people have started to imply (I refuse to allow Agile to be a dirty word)... instead, we are doing a bad job in the community at sustaining its applied success.

Now to the core of my point... I summarize it all right now!

By raising the issue of Semantic Diffusion, are we calling out an issue that needs to be guided more pro-actively? Or are we using this as an excuse to accept "the inevitable"? Are we doing anything to cause this problem to grow?

I'm going to state right now that I think we are. We need to stop looking outward for the cause and instead reflect inward.

When I started in the agile community, I worked with several great coaches. These were individuals who had proven experience in Scrum, XP, and other practices. They were "journeymen" with an interest in showing others how to do it. They insured that I learned how to do it correctly. I wasn't on the internet reading and learning about it, I had hands on coaching. Thus, I came up to speed quickly and I had a very positive, thorough, successful experience.

When I think of anyone entering our community, I hope they might learn through this same type of experience. Unfortunately, I believe the opposite is happening more often than not. Why?

Well, where are those agile innovators and early adopters now? Many of those folks have worked in agile for so long that it is easy for them to take these practices for granted. Their Ri level experiences have allowed them to forget the Shu level needs. They've moved on to much bigger problems like Enterprise, Off-Shore, and whole system optimization. These are good problems to solve, but you have to teach several coaches to replace you!

I also hypothesize that every new "generation" in the community learns at a quicker rate. There are more resources available, more lessons documented, more case studies published. If you take the right path, it is easier to get up to speed than in the early days. With this, people more quickly become successful (or not) and the gap between the Shu and Ri level groups becomes wider. When I entered the community, I could work with the Ha level group; but this group is a smaller percentage of the whole now.

When I went to the Agile 2007 conference in Washington D.C. (my first), I quickly learned that I was a Ha level user. As many people were asking me for insight into my experiences as I could find people to ask about theirs. It seemed that there were a small group of people that were innovating, and the rest were split evenly between learning and using. Now I feel as though (based on the community at large), the Shu level group greatly outnumbers the Ri level group due to market hype. The Ri level group is looking forward to innovate and there is not enough Ha level people to support the Shu group. I commonly find myself talking to a Shu level person asking about agile that doesn't know about the manifesto and haven't heard of the many important names or bodies of work in our community. Whoever planted Agile in this person's head didn't do a very good job in my mind.

And here is where the bottom feeders step in! Want to know about agile? Let me re-purpose my old pitches with these new buzzwords and charge you money to learn about something the wrong way. Everybody is talking about it, and you can't find anyone to help... so I'm the best you've got. Slap a few acronyms on your resume and hand you a certificate on the way out and you'll be dying to hand me $1500 to keep up with your peers.

So... if you've been doing agile for over 3 years and you've been successful at it, what are you doing to help the community? Are you bringing your experiences to folks and sharing them? Do you venture into communities where there are people at a different level than you? Do you explain what worked for you, or do you tell them how their approach is wrong? Do you throw the book at people and shake your head, or do you wrap your arm around them and bring them into the circle? Are you too focused on innovating to see who we are leaving behind? Do you focus on everything a person is doing wrong, or do you help them find something to do right? Do they see the benefits after they've tried it, or do they just follow this new set of procedures you've described?

Why does this matter? Because unless you are going to spend the rest of your career working with the same people, you may someday be working with one of these poor lost souls who has been taught everything wrong. You may take a job with a great agile company to only find out that the leadership has it all wrong and make your life one living hell. If you don't want to argue about what agile really means in five years, or have to invent a whole new set of words for the same things that we lost to "semantic diffusion"... then we have to start working on that now. I'm not talking about holding down our turf and fighting every idiot that says stupid things. I'm talking about leading by example, sharing information, proving success, and helping others. These are the same ideals that started the agile movement in the first place.

If everyone is learning faster and the gap between Shu and Ri is getting larger, then we can't expect the people behind us to train everyone that is entering the community. We have to still spend some small amount of time continuing to mentor the people catching up to us. Somewhere in that talent pool is the next Gordon Pask Award winner.

And this is why I started blogging; I wanted to pass along the knowledge that people have passed me. I have now spent a year learning by blogging and sharing by tweeting. I continue to share through Twitter and LinkedIn conversations, but I've been forced to cut back on the blogging due to the recent addition in my family. I'm asking all of you to consider these points and not forget that not long ago, you were also new to agile. People need guidance on how to start with agile, and we shouldn't allow them to be led astray by the snake charmers and other bottom feeders latching on to our community. It is in our best interest to reach back and pull people up with us as we continue to grow. That's my challenge to you!

Semantic Diffusion is a disease that should be fought during the normal lifecycle of a movement. It is a rallying cry for continued guidance and debate with the newest members of our community to insure the tribe moves in a common direction. Do not try to control the community and define it, just get involved enough to make sure you provide opportunities for people to learn from your experiences.

Note: just to be clear, I am not stating that certain people have left their posts. Everyone still hears the voices Fowler, Martin, Poppendieck, etc. I'm saying that as the numbers grow, many more voices need to be added to this core set.

Agile East 2009 by Thoughtworks

I attended this conference Thursday October 29th in Philadelphia. There were two tracks on the agenda; I attended the business track and I brought a developer with me to attend the technical track. In summary, I was not invigorated at the end of the day like the Agile 2009 conference, but this is the cost of fewer sessions to pick from. The content was relevant, but not much was new for the folks like me who have been following agile for over 5 years. That being said, it was a networking opportunity with other agilists in the area. The following are the notes I took, there’s a few good nuggets in here-

Martin Fowler – The Essence of Agile

• Very good job of explaining the “why consider agile” pitch without using the word waterfall or calling out PMI/PMBOK. This made it less combative than other things I’ve heard and was a note I hope I can carry with me during my own conversations.
• Called out the concept of “semantic diffusion”… the current trend of terminology diversity, dilution, and mis-use as agile has grown. He said it is the cost of growth and success of the movement. I like this phrase and will use it moving forward.
• Stated that Scrum = adaptive planning without forcing evolutionary design ... thus Scrum is not good enough by itself. Agile requires adaptive planning AND adaptive technology (evolutionary design) to succeed. I counted that as another vote for hybrid agile, be it Scrum/XP or other.
  

Martin Fowler – The Value of Software Design

Great overview of Technical Debt. I’ve never seen it to this level of detail and I found this to be the most valuable talk of the day. His mention of recent debates with Uncle Bob Martin on this topic was civil and talked of their similarities instead of their differences. His short impersonation of Uncle Bob was hilarious (“Thou shalt not name your variables improperly…”)

Discussed the concept of tradable quality

• lower quality = faster = more features sooner
• UI & defects - visible to user
• good modular design - not visible to user
  

Proposed the “Design Stamina Hypothesis”

• no design - over time, more effort to get more done
• good design - over time, less effort to get more done
• each start out the opposite of this, but cross and become true within weeks (much sooner than most assume)
  

Discussed accidental vs. essential complexity

• Accidental - caused by sub-optimal design
• Essential - chosen, prudent
• Both are technical debt in his mind
  

Likened technical debt to a mortgage metaphor

• the creation of technical debt is the principal
• the interest is paid every time a new feature added
• with every new feature you should decide to pay interest (build on top), or pay principal (go back and fix core)
  

Explained the cost/value of technical debt

• interest payment cost = story estimate - story estimate if debt was fixed first
• principal cost = estimate cost to fix principal/issue
  

Causes of Technical Debt

• You don't know how to do good design = reckless, inadvertent debt
• Ship now, fix later = prudent, deliberate debt
  

Debt is not right or wrong, it exists; the question is how do you deal with it?

• Being reckless with your debt is like maxing out your credit cards

Martin Fowler – The Controversial Topic of Diversity in our Industry

There is a lack of diversity in profession (Women, African Americans)

They under represented compared to population… Why?

We have a problem, especially when you bring in badly treated history for these people

This is a power issue, what do we do about?

• Don't shift imbalance of power in wrong direction with inappropriate actions
• Humor only works for lower power people towards greater power people
  

It is important for our profession that we care about the professionals in our space (both peers and customers)

• Software development is a leading role in the world!
• If we block access to these minority, then we lose access to potential talent
  

Carl Ververs – Change Leadership

If you have followed Linda Rising, Esther Derby, Diana Larsen, Dale Emery, or some of Alistair Cockburn’s work on teams, people, trust, communication, psychology, etc… then this session was a repeat of pieces of their work I’ve seen in Agile 2007 and Agile 2008 or their books or blogs.

That being said, many people in attendance that day were new to agile, and this was a great session for them!

Joseph Zenevith – Agile Estimation Patterns and Pitfalls

If you have heard about agile estimation (as a process), but are new to agile and trying to implement it… this was a good session to help you get started and avoid the pitfalls. Discussions around sprint zero, sizing, etc.

Ross Pettit – The Financial Implications of Agile

This session was over my head (and most of the other attendees based on the body language). Thank goodness they did this over lunch. That being said, it was perfect for a CFO or anyone focused on how projects affect the profit margin of the company. I took a few notes-

Capitalization - Agile projects have a higher % of potential capitalization than traditional PM

• capitalization = good = helps profitability
• Forrester claims that agile projects are 40% cheaper
  

Cash Flow – agile projects don’t mortgage the future by deferring integration, testing, NFR’s

• Less “balloon payment” surprises at the end of the project
• Story/Backlog Item = $ turned into a result (not $ turned into a % effort complete)
  

Yield - a story is a focus on maximizing yield vs. containing cost (invest in the right stuff)

Volatility – investors hate since agile since it isn’t predictive/deterministic

• old belief system is false though, so it is about education
• agile projects will fail faster, this is a risk mitigation
  

New Exposures – failed projects and lost people can’t be capitalized

• can cause a liquidity problem
• solvency is a problem if people are lost (lost investment)
• mitigate by aligning finance planning to iteration delivery and diversify investments
  

Greg Reiser – Redefining App. Dev. w/ Offshore Agile

Because I have experience in this area, I didn’t take any notes. My personal experiences were on par with their discussion. The main message- Make sure you are conscious about going down this path. It will not save the amount of money you believe up front, it can provide access to talent you don’t have, and it can be done (but not easily).

One thought that popped into my head as they were talking: How do you minimize / mitigate causes of technical debt in the offshoring model? Do you review the all code? Woah… someone should tackle that problem!

Tiffany Lentz & Manu Tandon - Applying Agile in a Non-Technical Area of the Org

This was one of the main reasons I wanted to go to this conference. Unfortunately it was a disappointment. It was a case study (I never find these as helpful as other sessions) and I missed that it said “applying” in the title instead of “convincing”. I need ways of pitching Agile to non-tech people. The session was about Scrum and a PMO setup for two teams that included non-software people (but many of the same roles you’d find on a scrum team).

One quote I liked: think of work completed as consumables downstream, not deliverables! (Interpretation- make sure people are supporting something, not just checking work off!)

The PMO had an interesting approach; instead of mandating process, they mandated required practices with multiple ways of achieving them. Examples included: estimation by the worker (not manager), work must have acceptance/done criteria, prioritization by the customer (not mgr). Because of this approach, “business value delivered” became an important discussion point within teams, unprompted and on its own.

Agile is not a metric, it's a journey...

As ridiculously fluffy as that sounds, it is true! You can't measure your team's agility and say, "Yup, we are there!". It is a mindset. All of the agile approaches (XP, Scrum, Lean, etc) are simply schools of thought.

Jai put up a very good post which triggered this discussion:

... Then he added that if you are not doing pair-programming or continuous integration, how can you say that you are agile. There I got the idea that what he was confused at.

Sometimes it is hard for people to differentiate and digest the differences between the Agile practices and many of the XP practices. They somehow get mislead by the idea that the XP practices etc are part of Agile. And Agile enforces these practices with it.

Many interesting comments are starting to come in, but mine was this:

I’ve dealt with this myself. I try to explain that the manifesto was the result of many people with different ideas on how to solve the same problem. The manifesto is the solution to the problem strategically. The “denominations” of agile are tactical approaches to solving the problem. Scrum is product and schedule focused, XP is engineering focused. And oh yeah, many of them have converged over the years.

Contrasting XP/Scrum with Kanban, Crystal, Lean, etc also tends to help. When people can see the common outcomes from the different approaches, it starts defining Agile by the results and not the chosen methods.

Follow the discussion further here.

Agile or Lean, which is the bastard child?

I'm kind of tired of these debates since they don't really do more than the Mac vs. PC debates. Who cares which came first? Does coming first confirm value? superiority? inferiority?

Anyway... Mike Alber posted to the Agile Alliance LinkedIn group the following question:

Agile and Lean Software Development - an Oxymoron?
What do you believe - is Agile is an instance of Lean, or together are they are an oxymoron?

My response:

They are both journeys towards the same end goal with slightly different paths. To me it is like asking if driving from Florida to Maine on I-95 vs. Rt 1 is the same or different.

Yes they are different. But they are both going in parallel and towards the same ultimate goal. They even cross and overlap each other quite a bit. It also seems their start was about the same also.

I really like what Matthew Chave had to say:

1 of 2 ways to go here.....

1. Agile - throw your processes away and start again....take Scrum and XP and implement them....

2. Lean - use lean techniques to remove the waste from your process......

What happens if you do 1......well you probably fail as its too much to do in 1 go......

What happens if you do 2.....you gradually improve your process and in the pursuit of "perfection" gradually refine your heavy-wright process to become something that looks a lot like Agile......

Moral of the story (and to quote Martin Fowler on the topic):

"You can't really talk about them being alternatives, if you are doing agile you are doing lean and vice-versa. Agile was always meant as a very broad concept, a core set of values and principles that was shared by processes that look superficially different. You don't do agile or lean you do agile and lean. The only question is how explicitly you use ideas that draw directly from lean manufacturing."

Pot of Gold at the end of the rainbow...

Many of us get our agile information from many sources. InfoQ tops most of our lists, conferences and specific blogs have their followings, and specific groups have their own blogs or websites. I tend to uncover lots of odd nuggets by setting RSS keyword scrapes on Wordpress.

Today I learned about a whole new area I've been out of touch with.... email groups in Yahoo. Historically I've avoided Yahoo groups because my Yahoo experiences have been problematic, but I also didn't know what I was missing.

If you are like me, you want to see this. Mark Levison invested some time for our benefit to document the best Yahoo group agile lists out there including a description of each. It's like I found the pot of gold at the end of the rainbow! Hopefully this will help you as much as it might help me!

Agile Maturity Model & Scrum Success Story...

I wanted to make sure my readers had the chance to review these two links, so I'll share them here:

• Ryan Martens over at Rally talks about IBM's (Scott Ambler's) proposed Agile Maturity Model. It's a good read, I agree almost perfectly with his statements. My take on these topics is this: once you box and define agile, you lose the magic. Agile is about inspect and adapt. Definition for the mainstream removes the adapt part (it just sets a straight goal) and then inspection is unnecessary because the definition allows you to falsely believe you've attained your goal. (Hint: The goal keeps moving as you get better!)
• Samir Bellouti posted a great experience report about his team's successful first year of Scrum implementation. I'm no longer a strict follower of Scrum, I tend to blend various agile approaches, but I believe that if you don't have a coach or resource to help you through implementation, then Scrum is a great recipe to start with. It's most documented and supported and will allow you to figure it out on your own with the published works available. This story is an example of how it SHOULD turn out and notes the value provided to the business.

Folks, agile is not easy! Just like dieting to lose weight, going agile is hard work for a more efficient and valuable outcome.

It's okay to be a zealot!

I was starting to think I'd been coming on too strong recently. Too much faith in the agile ways, not enough compromise.

In some ways, I was right.

You can't coach or mentor if you don't listen to others. You can't sell an idea if you don't mold it in a way that adds value for your listener. You can't be the catalyst for change if you ignore where people are coming from.

At the same time... it's okay to have strong beliefs. It's okay to KNOW that your way is better (assuming you've experienced and proven this before). Life experience is about learning and growing. Wisdom is about sharing that with others. Knowledge is only valuable if it is passed along.

Uncle Bob posted a retort that will probably start yet another flame war between the agile community and a non-member who didn't think through his words completely enough. But his points about being a zealot, and it being an okay thing, are very interesting.

We are a problem only if we start to believe our views are the final perfect answer.

Friday highlights...

In case you didn't see them:

1. Achieving Agility Needed for Business Survival (Info Q) - 8 values & ethics, along with a good comparison between agile and the restaurant business.
   
2. Accounting for bugs the agile way - part II (ASD) - simple summary by Jack Milunsky of how to handle bugs in your process... yes, they are on the sprint backlog... no, they don't add to velocity.
   
3. The Ideal Workspace (Cohn) - what is needed for a team (of developers) to fulfill their basic workspace needs?
   

Failure condition...

People have beat this topic around for awhile now, and I have seen some interesting content about what will force an agile approach to fail... but I've never seen such a simple boil-down of this topic for both agile and waterfall side-by-side.

Thanks to Udayan for posting this simple chart.

Summary: unstable requirements + unstable team = FAIL!

I wish I worked there...

Actually, I'm [probably] on a cruise ship in the middle of the Caribbean right now... so I'm in no position to complain. But, there are days where I ponder if it would be more fun to work a specific role for a company that is successfully agile, or to work in a company-wide Process/Project Coordinator role like my current one where I can constantly infuse agile concepts into the business in a stealth manner.

I'm undecided...

But, if I were to look for an agile company... it might be a little bit like this.

The Agile Salesman...

Many of us find ourselves explaining Agile to others. What's good about it? Why to do it? How it helps?

The problem is that many of us have been burned by waterfall so badly that we take a "waterfall sucks and agile doesn't" approach. Unfortunately this approach doesn't work because it just leaves a bad taste in people's mouths and we then justify it with the concept that you have to experience agile to truly get it.

I've been following Seth Godin lately since he is a master marketing guru and his viewpoint provides insight into how to sell a new idea. Today he wrote a great post about how to pitch a concept. He uses the metaphors of gravity vs. evolution and how quickly these concepts were "sold". Here's a snippet:

Tactic 1: Try to tell a story that complements an existing story rather than calling it out as false.
Tactic 2: Try to make the 'proof' as vivid and immediate as possible. Like an apple falling on your head.

This is why I like Mike Cottmeyer's recent work around bridging the traditional PM's point of view with Agile's (he has a bunch of posts, so keep looking past this recent one if you are interested). Instead of saying waterfall stinks, he explains how agile enhances.

Agile is a Chinese Buffet...

James Shore has put out an article called the Decline and Fall of Agile. Within the past 2 weeks, I've seen it referenced in many places, including here on InfoQ, and it has definitely sent tremors through the community. Some people have misunderstood his intentions. This has led to many people talking about what languages and labels to use when discussing their agile experiences and whether using these labels properly matters.

Here's a quote from James's article:

It's human nature to only do the stuff that's familiar and fun, and that's what has happened with Agile. People look at agile methods as a chinese menu of practices, choose the few that look cool, and ditch the rest. Unfortunately, the parts they leave out are the parts that make Agile work.

Here's my opinion-

1. If you are not experienced in a successful agile transition that covers more than one denomination (XP, Scrum, Crystal, Lean), then you are at risk for making incorrect assumptions about what you can change or discard from the practices and still be successful. You either need experienced mentoring, or you need to follow the rules until you know why you do things and what adaptations will increase the value of Agile in your environment. You can't understand value without a baseline. You need to try the things unfamiliar to you to understand their value.
   
2. If you are experienced in a successful agile transition, then you MIGHT be able to adapt agile practices and patterns to a specific environment because you have experience and the foresight to see anti-patterns and other issues as or before they occur. You have to constantly take into account that your environment is unique and adapt accordingly.

To the chinese buffet metaphor-

1. If you've never been to a Chinese buffet, then you don't know what you like or don't unless you try it. You don't know which sauces belong on which items unless someone tells you.
   
2. If you have been to this Chinese buffet before, then you have a good idea what makes a good meal for your tastes.
3. If you have been to a good Chinese buffet before, but not this specific one... you might not realize that this one has very good versions of things you didn't like somewhere else unless you try it again.

Shu, Ha, Ri folks... Shu Ha Ri!

How do I know if I'm Agile?

There are a lot of discussions around Agile and the minimal requirements. I agree that there are many in the industry slapping the agile name on their process because of the positive association. Of course, this only leads to the dilution of the term's value.

There are also many who are pushing back on this and taking too strict of a tone and painting a black and white line. To them, you are either in or out. Of course, these are the same people who will acknowledge it takes months for a team or organization to grow into agile... it's not an overnight transition.

Taking that into account, I typically look at it through one of these lenses:

• The organization is not agile, and does not care to be
• The organization is interested in agile, but does not know enough to pursue it yet
• The organization is going agile without knowing it due to internal coaches who dare not utter the word "agile" for fear of ruining the current momentum
  
• The organization is striving towards agile intentionally, but can not call itself agile yet because it has too many areas to still work on.
  
• The organization thinks it is agile, but this is limited to what it knows
• The organization is a leading example of agile, but now the burden is on them to keep pushing the envelope
• The organization states they are agile, but are lying.

Note how the last bullet accounts for the groups who jump right in without taking the journey down the path.

I've seen tests for agile before, like this nokia test for agility. But personally, if you are just trying to get a simple start to it, I prefer using Cockburn's Crystal test. My group has shifted points 1-6 to a positive position, and now needs to work heavily on #7 before saying we are almost agile.