Thursday, November 5, 2009

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.

Tuesday, November 3, 2009

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.

Monday, October 5, 2009

Best Of- you've listened to me ramble for over a year!

For those of you who follow this blog, I apologize for my recent calm. I've tried very hard to provide you value, and you've rewarded me with wonderful support, great conversations, and plenty of good feedback. But... in case you haven't heard, I do have a good reason. Before her arrival, I knew this might happen and tried to combat it with my pre-written Quote Series... but I underestimated how long it might take to regain normal life flow (this topic was raised in my last personal retrospective).

I've had the energy and sleep to continue absorbing from the community; but the only thing I've been able to contribute back is my agile focused Twitter stream. It has been over a year since I started blogging and I'm pleasantly surprised by the traffic and global coverage of my visitors. Until I can get back into the rhythm of things (hopefully in the next month), I wanted to leave this "Best of Agile Commentary" list in case you joined me on this journey mid-stream.

Top 10 blog posts in the last year based on your clicks (in reverse order)!
  1. Participate in change, don't expect it to happen Agile is not just about managers changing
  2. Cadence... I used a metaphor of cadence from the military to understand stand ups and feedback loops in agile
  3. What is Shu Ha Ri? An overview of Shu Ha Ri… a very important learning principle
  4. What is sprint planning about? Focus on the core intent behind sprint planning
  5. Shorten your iteration... One of my first posts… shortening your iteration avoids mini-waterfall
  6. Walking the board... We were one of the early adopters of the "walking the board" approach where we don't follow the "3 questions" in our stand up
  7. Create a proper estimate scale... Popular how-to on creating a story point estimation scale
  8. UX and Agile, how do they mix? Riding on my past usability experience, one of my first posts about User Experience within Agile
  9. Snake on the wall! A great way to easily put your finger on waste and distraction with the team… every time this post gets quiet, it suddenly fires up with traffic again after a few weeks from a new source!
  10. Post agile, one third of you will be gone... Most popular blog post ever about my first agile transition. It created controversy, was picked up by Kent Beck and flagged high on Reddit. Some even went so far as to say I sounded like a cult-member! You either get it, or you don't. When it happened to me, I was a convert, I'm now a pragmatist.
And here are three of my favorite notables that didn't make the traffic-based cut:
  1. Puppy vs. Pitbull... One of my first posts about team dynamics and personalities
  2. Before agile came along, life was easier for me... Reverse psychology at its best about the good old days
  3. Bored in the standup? Raise your hand! How we combat tangents during our stand up
Thank you for your continued reading, challenges, and criticism!

Thursday, September 24, 2009

It's all about getting groceries...

When the average college student goes to college, they suddenly have to fend for food themselves. Most campuses provide some type of food source insuring students don't starve to death, but cafeteria food isn't always up to snuff for the tastes of the average 18 year old so they wander out and make their first true grocery run. How does this typically develop?

Phase One- Wander around and find stuff that seems like a good idea.
Result- Realize very quickly within a few days that you forgot stuff that you needed and what you got wasn't really a wise choice. That 3 tub pack of chocolate Kozy Shack pudding seemed like a good deal until you went home and ate it all within 24 hrs. Now you need to make another trip for food that will actually give you some energy for mid-terms.

Phase Two- Realize over time that you don't like wasting time grocery shopping; make a list of groceries and go get those items.
Result- This helps add efficiency, stay within a budget, insure completeness, and aids in blocking useless (or unhealthy) purchases.

Phase Three- You quickly get bored of canned food, cheese n' mac, and spaghetti; it's time to decide what you want to eat/cook in the coming week, then make the grocery list
Result- You shift from always having stuff in your kitchen, to having what you need to make the right meals from that stuff. By working backwards, you insure you are happy with the outcome.

So, what does this have to do with agile or project management?

Phase One - I can't tell you how many companies have a development team that just wanders around and does what seems will help run the business or quiet the screaming managers. Kind of like the hungry college student's stomach, this is simply an id response to filling the basic needs. Unfortunately like the cozy shack pudding example, this doesn't always turn out best for them either.

Phase Two - There comes a point of time where the team can't keep everyone happy. Work starts falling on the floor and some things don't get done. Organization is suddenly required. The team has to start making lists and prioritizing work. They have to consciously decide which things won't get completed to insure that the right things do get completed. They need to stay focused on the list and not everything else that draws their attention (backlog management anyone?)

Phase Three- To really mature as a team, you have to start focusing on your DONE criteria. What is being accomplished? What is the goal you are trying to reach? What is the business value being achieved? The work isn't DONE until you meet this!

Now, lets assume that college student is growing up... or maybe they are maturing their cooking to impress someone they are dating:

Phase Four- ask the people who ate the food what they liked and didn't like. Adjust selected meals accordingly and then adjust the grocery list.

For the agile team... this is the retrospective.

Wednesday, September 23, 2009

Bees self-organize, why can't we?

There is another interesting thread on LinkedIn's Agile Alliance group. I caught up to the conversation late, so instead of adding my two cents, I just want to share the highlights here.

The Question:
In another discussion thread I saw many references to "self managing team" as being one target or goal for any Agile team.

Here are few hypothesis related to that:

True or false?
1. Teams can only become self managed if they have worked togather for long.
2. Teams (and through that companies) will never get to take advantage of their ability to be "self-managed" since the members will be transferred to different projects after they have completed their existing project.
I think the first response is the greatest, so I applaud Bob MacNeal's response:
1. False. Complete strangers are capable of self-organization. Bees do it. Humans do it too.
2. False for some teams. True for most companies. People have an amazing capacity for self-organization. Organizations habitually muck this up by layering in a mojo-killing culture of command-and-control.
Mark Ferguson:
A team that can't self-manage their own internal dynamic will fail. A manager can't micromanage each individual's interactions with other team members, although some do try!

Wayne Peacock:
Success comes only after a series of failures. Scrum or Agile is no silver bullet. The best thing about Scrum is the constant inspect and adapt cycles...

and finally, Sharan Karekatte:
Self-management is what Scrum teams do. They actually manage the user stories and tasks from the Sprint Backlog on a daily basis. They are not told 'how' to complete the work, but 'what' the Product Owner would like from the team in order to deliver the ROI and fulfill the Product Vision.

Monday, September 21, 2009

Bored in the standup? Raise your hand...

I just read this interesting post about a scrum team that borrowed the concepts of yellow and red cards from soccer to aid their standups. 3 yellow cards or 1 red card means "move on".

Unfortunately, I live in a country where soccer is not the biggest sport... and I'm sure we would just misplace the cards.

So, let me share what has been working for my team for over a year now...

If anyone in the group feels that the current topic is not relevant to the group, they slowly raise their hand. They do it slowly to not be obtrusive and rude. If other people agree with this person, they can decide to also raise their hand. If there seems to be visible consensus, the people speaking must quickly assess their conversation and decide how to close it. They can either put it on the parking lot, or realize they aren't getting anywhere with it and just stop.

The parking lot is a list on the wipeboard in the team room. The person closest to the board writes the topic and the names of the people who are involved. At the end of the meeting, those people stay behind to pick the conversation back up.

If the person raising their hand is alone when their hand is fully raised, they suddenly realize that they are alone in their stance and drop their hand. At this point they wait for the good of the team since clearly, everyone else finds the conversation valuable.

And yes... our standup is short. We have about 15-20 people every day... and we average about 17 minutes (15-20 minutes) even with these included conversations.

Recently, we had an amusing moment when someone raised their hand on themselves...

Wednesday, September 2, 2009

Quote Series Part 7 - Philosophy (contd.)

This is part eight of the series, to see what this series is about, click here. This is the last in this series.

Quotes on "Philosophy"
Make time to make it right, or be prepared to do it again - Denise Caron
Embrace new directions... not everything you do will be used, sometimes, the target changes. Re-aim and move on! - Denise Caron
Change is constant... don't fight it, leverage it. - Denise Caron
Don't fall in love with your product, someone will be there to change it, it's a promise. - Denise Caron
Blindly following rules is a fools errand. We have enough grey matter to discern when the rules are helpful and when they are not. We have the responsibility to continuously measure whether the rules are helpful, or whether they are not. - Uncle Bob Martin
It is solely and utterly the team’s responsibility to figure out what to do, and to do it. - Ken Schwaber
"Better" is typically a word leveraged by those in control (eyes of the speaker). "Appropriate" is typically a word referencing those affected (surrounding group). We should seek that which is appropriate, not that which is better. Avoid elitism, blanket statements, or viewpoints of limited individual experience. - Kevin E. Schlabach
Without prioritization, nothing is a priority. - unknown
The practices are not the knowing: they are a path to the knowing. - Ron Jeffries
To tolerate a problem is to insist on it. - Ron Jeffries
If it hurts, do it more often - Martin Fowler

Note: where I can, I've credited or linked the source of the quote. Finding the source of a quote is like chasing a ghost. When a mentor says something witty, you might not know they are quoting someone else. If you are aware of a more appropriate source for any quote, PLEASE put a comment on the post and I'll do what I can to validate this. I mean no disrespect to anyone. I believe the risk of incorrect citings is outweighed by the value of sharing these wonderful nuggets.