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.