Speaking at SB Agile

I’ll be visiting the SB Agile group in Santa Barbara on Wednesday, January 21, 2015

You can find all the details about the location, time, and other pertinent info at their Meetup group page: http://bit.ly/1zdU7ha

Topic – Continuous Discovery: The Power of Pure Agile

Brief description:

The strength of Agile lies in the simplicity and clarity of the Values and Principles as expressed in the  Agile Manifesto.  I have found that if we take this philosophy to heart it can empower people doing software development in any organization, and enable us to make rapid strides to the “land of better”.

As leaders, activators, and influencers of change in the companies we work with, we must take responsibility to understand the philosophy of Agile, and learn to invite and draw people to share that understanding.  We need change, we want change, and we know we must influence change for the better.

I’ll share my thinking about “Pure Agile”, and how I use it in my daily work to enhance Continuous Discovery, Learning, and Growth in the teams and companies I work with.  Let’s explore together and discover the path to future we want to create.

I hope to see you there!

Finland and Sweden Workshops and Sessions

Workshops in Finland and Sweden this Fall


Public Workshops at Mystes in Helsinki, Finland

Along with Llewellyn Falco and Vasco Duarte I’ll be participating in 4 half-day workshops on the 23rd and 24th of October.

Mob Programming: If you are interested in participating in a Mob Programming workshop, where you can experience our Teamwork attitude and many ideas related to Teaming and collaboration, please join me for a half day hands on workshop.

NoEstimates: Explore with us our current thinking and experience on NoEstimates decision-making. In this workshop we will review and analyze why we do estimates and how we can improve software and product development while reducing the time and money invested in estimating.

Hands-On introduction to ApprovalTests: ApprovalTests make it easy to create descriptive, expressive, easy to write and debug unit tests. In this workshop you’ll experience how to use ApprovalTests to accelerate test-driven development for everything from simple strings to arrays, GUIs, and complex objects. ApprovalTests is free and currently available for C#, Java, PHP, and Ruby.

Practical Refactoring:  In this workshop we are going to work on a 300 line ball of mud, and experience some new approaches and techniques that will enable you to easily and safely revitalize your legacy code into a thing of beauty little by little. After this workshop you will have a practical, hands-on understanding of how small daily improvements improve large-scale projects over a few months. You will see how much your own project at work could benefit from continuous improvement.

Helsinki, Finland – October 23rd

Mystes Presents
Woody Zuill, Vasco Duarte & Llewellyn Falco
October 23rd & 24th, 2014

Tampere Goes Agile, Tampere Finland

I am really looking forward to Tampere Goes Agile, October 25th http://bit.ly/1vXa4sb

I’ll be presenting on Mob Programming, and likely doing a workshop on it as well.  I’ll probably be speaking about NoEstimates, and who knows what else.  As I understand it, this is a free event – which is pretty cool!

Øredev Developer Conference

Malmo, Sweden – Oredev 2014 – November 4th

I am very pleased to be returning to Malmo and the FANTASTIC Oredev conference!

Experience a full day of Mob Programming and learn the mechanics of how to work together as a “Mob”, and explore the underlying concepts that make this form of development so effective for my team.

Throughout the day we will be tackling a sample project and working on it using a full “extreme programming” approach – User stories, prioritization, test-driven development, refactoring, and retrospectives.

I will also do a session on Continuous Discovery,  The Power of Pure Agile, and I’ll share the stage with Vasco Duarte for a converstation called “#NoEstimates Unplugged – A Conversation About Agile As If You Meant It”.

And of course – I’ll be there and in Malmo for the whole week and I would love to have a chance to meet you and talk about Agile, #MobProgramming, #NoEstimates, or just about anything interesting.

Legacy Code is Good Stuff

There are a number of definitions people use, and I’ll give you mine here. Perhaps this is less a definition and more how I think about legacy code.

Legacy code is code that is doing some real work.  It exists because it is bringing value.  We work on it because we want the code to keep bringing value.

That is, any code that is in use is legacy code. We inherited it from yesterday.  Someone else might have written it, or we might have inherited from our self.  Regardless, it is meaningful to us because someone needs to use the functionality provided by the code.

I often hear people disparaging Legacy code.  When the code is bad, it can be hard to keep from complaining. I don’t. I honor the code, and the developer who wrote the code.  It is bringing value, and that in itself is a tremendous achievement.  Regardless of how good or bad it is, they (or I) got it to work well enough to be of use.

The developers(s) who created the code worked under imperfect conditions.


Google Group on NoEstimates

There is a Google Group on #NoEstimates. I joined it, and have visited it every now and then, but I have not participated.

I do not participate much in this sort of discussion group

Here is a bit of a quote (from a wise and well respected person) that goes a long way towards explaining how I feel about the #NoEstimates (and most) discussion groups. I have paraphrased it almost out of recognition to better clarify my position.

“Replacing a face to face talk with a Google Group is like replacing a hug from your Mom with a face full of pepper spray”.


It is rare that any two people agree completely about anything, let alone something as complex as the endeavor of managing software development. I don’t expect anyone to agree with anything I have to say, and it is a rare yet wonderful experience for me when I find someone who sees things in a way that is more or less in alignment with the way I see things. I don’t expect it.  However, I also enjoy having conversations with people who see things differently.

While I enjoy conversation, there is very little actual conversation going on in the typical discussion forum or Google Group.  Unless a group is actively moderated, it quickly degrades into something that is much more anti-conversational than it is conversational, more harmful than it is useful to gaining a shared understanding.  Perhaps they are not meant for conversations and understanding.

Recent forays into the land of Discussion Boards

I’ve recently read through several topic threads on various discussion boards at LinkedIn or Google Groups and it is typically a painful and disturbing experience for me. Overall, these threads are not productive conversations as far as I can tell, and seem to simply be a jumbled mess that is nearly impossible (for me, anyway) to decipher.  Some people must get value out of this sort of communication forum, but in general I don’t find them conducive to meaningful conversation.

Often these forums seem more like an opportunity for people to say “You don’t understand”, and then provide some rebuttals and clarifications that provide fuel for the next “You don’t understand” response. (I am using “you don’t understand” as a placeholder for all similar [and often less kind] responses).

Even worse, each response contains snippets and quotes (sometimes HUGE snippets or the entire content) of what someone in a previous post stated, and then intersperses the snippets/quotes with rebuttals and clarifications and “You don’t understand”, and “that is not how it is in REAL life” statements.  And even worse than that, sometimes the snippets and quotes accumulate from response to response building into an incomprehensible cacophony of confusion where there is no way to unravel who is trying to say what about which.

All in all, while this has been going on for a very long time (years and years), and while I participate in this sort of forum every now and then, I see little value in it for me.  I have enough to do already.

NOTE: The mini-forum of Twitter, while in my opinion is also not conducive to conversation, at least limits the amount of cacophony. Rather than the “continuous ringing of huge, deafening alarm bells” it’s more like the “continuous jingling of tiny, less deafening alarm bells”, and there just aren’t enough characters to gather garbage snippets.  Anyhow, I’m pretty much on board with the #NoCacophony movement.

I prefer face to face, one-on-one conversations

I prefer to have engaging and meaningful conversations with people who are willing to talk with me.  The most productive, useful, and pleasing of these experiences for me are in one-on-one, face to face sharing where the both of us are sitting at the same place, or taking a walk together.  Sometimes having these conversations in very small groups with everyone in the same place is just as good.  I have found this to be very fruitful to me for my own learning and exploring, and for vetting and critiquing my ideas and thoughts. I can only assume that this works well for at least some folks since I frequently meet with others this way.

While this “in the same place” mode is great, it is not always possible.  So, my favorite alternative (at this time)  is to have a conversation via video Skype or Google Hangout (or whatever technology that works).

Sometimes, the only viable approach is to make a voice only call, but this is in a very distant 3rd place.

Besides those 3 basic approaches (same space, via video chat, and voice only call), there are a few other variations that can make things better (like having a screen share in a remote conversation).  But that is beyond my purpose in this little post.

Why do you suppose face to face, one-on-one conversations work so well?

Why does the one on one, face to face (or small group) style work so well? I’m sure someone probably knows, and I have my ideas, but that is not important to me. What is important to me is that it works well for me, and it is my preferred approach to learning and exploring, vetting and clarifying.

When we make it our goal to find a way to understand each other it often requires that we change the way we are saying something, or the way we think about something.  That is, we might “change our mind” based on the new information and understanding we are gaining.  Our eventual understanding will likely be different from where we started for both of us.

When our words and thoughts are “locked down” in a forum thread, making changes to more clearly communicate our intention is (typically) not possible – we have limited “edit” rights.  Even worse, the path to shared understanding seems to be thwarted, and old misunderstandings just get brought up again and again, sometimes by people who were not part of the original conversation and don’t understand what has been covered, or the path that led to the current understanding.

With spoken communication we tend to just move on.  We say things like “I see what you are saying”, “You are right! How did I miss that?”, “Now I get it”, “Oh… you meant this instead of that”, “Of course!  That makes sense to me now”, “Here is something I think I wasn’t considering…”,  and so on.  I don’t see these phrases often in the discussion boards.  This isn’t always true, but I’ve found that spoken conversations tend to be more conducive to making progress towards a shared understanding.

Regardless… you must find the communication style that works for you.  If forums and groups and discussion boards work for you, then GREAT!  You just won’t see me join in much.

On the other hand, let me know if you want to chat sometime.



To me, This is Agile

I’ve seen a lot of orgs/teams/groups/whatever (I’ll call them orgs for now) doing things that aren’t working, and yet proceeding as if they are working.

I’ve seen a lot of these orgs move on to “better” starting from wherever they are by learning to reflect, tune, adapt, adjust (and some other things).

I’ve seen number orgs revert or “backslide” as well – both slowly over time, as well as almost instantly in some cases.

Whatever the situation, those of us who want things to be “better” need to take action, and that will never stop.  At least I’m pretty certain that will never stop.

I take it as my responsibility to make things better in my profession and in the places I work.  I act on this responsibility by exploring possible “better ways”, implementing “better ways”, and influencing things to the degree I can.  To that purpose, I constantly work on improving my ability to influence things for the better – sometimes I have success, sometimes I don’t.

To me, this is “Agile”:

An approach that works well for me is to always take rapid, never-ending baby steps to “better”. I constantly reflect, tune, and adjust. When things work, great. When they don’t, it’s easy to adjust or take back that baby step and try some other step.  Sometimes I take leaps, but I prefer taking baby steps.

For me, there is often a “Lofty Goal” that represents a vision of a better future.  It will change over time, and any specific “lofty goal” can grow, morph, or fade away over time depending on what I discover as I take more baby steps.

I want to always have the option to make mistakes, and to pay as little as possible for those mistakes.  Sometimes I must pay a lot for our mistakes. Still, I prefer to find ways to keep the price tiny when I can.

Being resolute to work with others to always steer to the next possible “better” seems to work nicely.  I fail in many ways, but it is not the ultimate failure of thinking and acting as if “I can’t make a difference”.

The Values and Principles of the Agile Manifesto are the foundation of my idea of what “Agile” is, and what it is to me.  I have expanded on these ideas for my own work, and I don’t see them as being “static”, but rather a somewhat firm yet dynamic set of guidelines that are easy to apply for evaluating my thinking about the business of software development, and for my exploration of software development practices and techniques.

I know what works for me: I take the Agile Manifesto seriously, and I constantly Reflect, Tune, and Adjust.  I think of this as “Pure Agile”.


Upcoming 2014 Speaking Plans

I have made plans to speak at several upcoming conferences and events.  If you are attending any of these, I’d love to meet up with you and talk about Agile, Mob Programming, #NoEstimates, #BeyondProjects, or just about anything please look me up!


Already done…



Agile Retrospectives Workshop With Diana Larsen

Advanced Practices for Leading Agile Retrospectives: New Techniques and Activities

with Diana Larsen

When: Thursday, March 6, 2014 from 9:00 AM to 4:00 PM (PST)

Where: Marina Village, San Diego, CA

Visit the Eventbrite page for this event at http://dianalarsenworkshop.eventbrite.com

Spend an entire day with Diana Larsen exploring, learning, and practicing Advanced Practices for Leading Agile Retrospectives.  Agile Retrospectives improve any project or process — building on a team’s immediate past experience of success and failure. Smart teams and organizations hold Retrospective meetings iteratively, throughout the work cycle and at important release milestones.

In this workshop, Diana Larsen will introduce advanced uses of the Flexible Framework for Retrospectives and show how to incorporate the Five Rules for Team Learning in your Retrospective designs. Participants will share new team activities to enlarge your repertoire and gain practice in designing and facilitating effective Agile Retrospectives.

The Day:

  1. Introductions – including practice with new activities to “Set the Stage”
  2. Agile Retrospective Purpose & Group Learning, Thinking, and Collaborating on Improvement Actions
  3. Applying Five Rules for Learning in Retrospectives
  4. Explore and practice new activities to “”Gather Data”, Generate Insights”, “Decide What to Do”, and “Close the Retrospective”
  5. Retrospectives as Adaptive Action for “Responding to Change”
  6. Designing Agile Retrospectives for Continuous Learning and Improvement
  7. Next Steps

Our Facilitator, Diana Larson: 

Diana is a founding partner of FutureWorks Consulting. She is considered an international authority in the areas of Agile software development, team leadership, and Agile transitions.  She co-authored “Agile Retrospectives: Making Good Teams Great”; “Liftoff: Launching Agile Teams and Projects”; “Quickstart Guide to Five Rules for Accelerated Learning”; and most recently the Path Through Agile Fluency model, described in the article, “Your Path Through Agile Fluency: A Brief Guide to Success with Agile” at www.agilefluency.com

Tickets Available on Eventbrite: 

We are keeping the price for this event as low as we possibly can.  You can attend for only $99 for a “Bring your own lunch” ticket, or $114 and we’ll provide a Box Lunch.  Also, we have set up a “5 for the price of 4” discount if you have a group from your company who would like to attend. 

Visit the Eventbrite page for this event at http://dianalarsenworkshop.eventbrite.com

NoEstimates at Oredev 2013

By Woody Zuill

I was invited to present my ideas about “No Estimates” at Oredev 2013 in Malmo, Sweden.  It was an exciting and wonderful experience for me (to say the least), and perhaps someday soon I’ll post more about it.

Until then, here is a link to a video of the session I presented there about #NoEstimates:

NoEstimates at Oredev 2013

Please let me know what you think, if you would.

The NoEstimates Hashtag

In Twitter, we use the convention of “hashtags” to connect a tweet with a theme or topic so that it is easy (or at least a bit easier) to search and find tweets for topics we want to follow.

Several people have blamed me for coining the “#NoEstimates” hashtag.  It might be true – I’m not sure.  It is possible that I was the first to use this hashtag for Software Development – a search of Twitter history on it shows that, as far as I can tell.

[UPDATE: I found the following post from Aslak Hellesøy – @aslak_hellesoy dated Feb 10, 2010 that used this hashtag

@obie at #speakerconf: “Velocity is important for budgeting”. Disagree. Measuring cycle time is a richer metric. #kanban #noestimates.]

SO… What is the Topic of the #NoEstimates Hashtag?

Here it is, as defined by me.  Others probably have their own idea:

#NoEstimates is a hashtag for the topic of exploring alternatives to estimates [of time, effort, cost] for making decisions in software development.  That is, ways to make decisions with “No Estimates”. 

I’ll probably modify this a bit over time – I put this together quickly as a starting point.

Also, A Word About Estimates

Estimates are typically and pervasively used in the decision-making process throughout software development organizations and efforts – both in “phased/waterfall” and “Agile” methodologies.  They are ubiquitous – it is rare to find a project/organization/effort where it isn’t simply accepted that “we must have estimates – it is the only way”.

Additionally, for a long time I’ve been noticing that almost every training, book, conference session, article, or blog on “Agile” software development has a very heavy focus on estimating.  I’m fine with important things taking a lot of our attention – they are important, after all. Are estimates that important?

I’ve also noticed over the years that many organizations have a number of dysfunctions in how estimates are handled, and the overall decision making process that depends on estimates.  Have you noticed any dysfunctions?

So… I started doing “5 why sessions” or similar exercises at conferences and user groups, and other investigations into the reasons for this, and the dysfunctions that people have been experiencing.  I also started discussing alternative ways to manage software development efforts without using estimates. I’ve been working without estimates for years for many decisions that are typically “estimate-driven”  in software development management, and some people are interested in how to do this.

It’s important to ask ourselves questions such as: Do we really need estimates? Are they really that important?  Are there options? Are there other ways to do things? Are there BETTER ways to do thing?

If we are willing to simply play the “devil’s advocate”, and imagine (or at least temporarily pretend) that perhaps there are better ways to make decisions, it can lead to more open thinking and clarity as to why we “believe the things we believe”.  Why not question the things we hold so dearly?

There ya go!  Have Fun!



My Customers Need Estimates, What Do I do?

It seems a lot of people have an argument against the “No Estimates” idea that goes something like this:

“Our Customers Need Estimates*”

There are many variations on this, but they typically come down to the same thing: We need customers, customers need estimates, therefore, we do estimates. The following are a few generic examples of this idea:

  • No customer will agree to hire us to write custom software for them unless we give them an “estimate”.
  • The reality of business is that we must give estimates to our customers so we can get work.
  • We must be good at estimates because our competitors are giving estimates.
  • The customer want’s to know if we can do their work at a price they can afford
  • The customer needs to know if they can make a profit based on the amount their software will cost, so they need an estimate.

How Can I Get These Customers Without Estimates?

This is a very easy question to answer: You probably can’t get these customers without estimates.  They want estimates – it’s part of the way they think. You probably MUST DO ESTIMATES for these customers.  That is, you don’t tell these customers “We don’t do estimates” if you want to work with them.

If you have chosen to work with the sort of customer that requires an estimate (or price) then give them what they want: an estimate (or price).  Your main job is to figure out a way to be able to make money taking on work for this sort of customer.  I understand that. You understand that. What more do you need to know?

A few points you might want to consider:

  • Are you willing to give an estimate/price for free?
  • Who pays for the estimates for jobs you don’t get?
  • How much extra do you need to “pad” the work for the “unknows”? Why should your customer pay for that?
  • Are you going to give a range?: “It will cost you no less than this but no more than that”.  Will you guarantee that?
  • If it costs you more to make the software than you estimated, are you willing to take the loss? Why??? If not, how will you deal with that? Re-negotiate the contract?
  • How do you know enough about the work to be able to give a resonably accurate price/estimate?
  • If a competitor shows them a better way, will they ever come back to you again?
  • That’s just a start – I’m sure we can come up with a lot of other things to consider.

If you choose to work following the “we must do estimates” model you are in good company (or at least in very numerous company), as there seems to be many who feel this is a reasonable way (or the only way they’ve found, perhaps?) to do business.

The Agile Way

I recently heard Jeff Sutherland do a talk where he mentioned the “80/20” rule – that “80 percent of the value is in 20 percent of the features” of a software project.  He quoted someone (I don’t remember who) as having suggested “we should just fund the 20% and not do the rest”.  I agree.  I’ll take it a bit further: I believe that the rule is more like “95/5” – that is: 95% of the value is in about 5% of the features, and that the people paying for the project will quickly end the project once that 5% is in use. Perhaps our goal is to pay as little as we can to discover and create that 5%.  So… how to do that?

Some choose the Agile way.  In this model, we recognize that “requirements emerge”.  If we can get good at allowing the more important and useful requirements to naturally emerge it pays off very nicely.

What does this have to do with estimates?  If I have to tell you, then you probably should be reading someone else’s blog.  But here it is: A customer who needs to “know how much it will cost” before they will decide to hire you to do the project might not be the sort who is willing to let requirements emerge.   It’s just not their way of thinking.  You might be able to “change them”, but probably not.

Not All Customers Require an Estimate (or price)

What it comes down to is this: You get to choose who you do business with.  If you choose to serve customers who need an estimate/price, then do estimates/prices, and figure out how to make that work for you.  If you choose to serve customers who are willing to let requirements emerge, then get good at the Agile way, and go for those customers.  It’s your choice.

Some of my other posts on estimates and “no estimates”


* For the purpose of this article, the sort of estimates I am discussing are the estimates typically asked for on many software development projects where a project, a feature, or a function, or a bug fix (or where a list of features or functions) are described and people are asked to come up with an approximate cost in time, money, or effort to do the work that will be required to provide the feature(s)/function(s)/capability(ies)/bug fix(es) being requested.

Disclaimer: There are many situations where estimates can be meaningful and useful.  This article is about situations where I don’t think they are typically meaningful or useful, and only in the realm of software development.