Finland and Sweden Workshops and Sessions

Mob Programming Workshops in Finland and Sweden this Fall

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, I’m providing several workshops this fall – one in Finland and one in Sweden:

Helsinki, Finland – October 23rd

Mystes Presents
STATE OF THE ART PRACTICES
IN AGILE SOFTWARE DEVELOPMENT
Woody Zuill, Vasco Duarte & Llewellyn Falco
October 23rd & 24th, 2014

I’ll be doing a half day workshop on Mob Programming, along with 3 other workshops covering 2 days.

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.

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”.

Conversations

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.

Cheers!

Woody

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”.

Cheers!

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 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”

Agile2013 Lightning Talk: NoEstimates

NOTE: This was a lightning talk proposal for Agile 2013 in Nashville.  My main purpose in this post was to have a chance to give a lightning talk on “No Estimates” at that conference.  An additional purpose is to encourage people to be thinking about the sort of estimates we use in software development, why we think they are useful, why we depend on them so heavily, and some of the reasons we might want to re-think our dependence on estimates.

Fortunately for me, I was chosen to present this lightning talk, which challenged me to put together a focused slide deck and talk on the subject, which then grew into the talk which I gave at Oredev 2013.

Going forward, my is goal to expose the sort of thinking and questioning I have been doing over the last 10+ years so that others who have been asking can use these questions as a starting point in their own exploration of estimate-driven software development.

I am not offering to answer these questions for you.  Only you can do that.

I want to emphasize this: If you want to discuss these ideas with me, I am always happy to talk with almost anyone – either via Skype, or at a conference or developer meetup.  If you demand that I answer these questions for you, then you have misunderstood the purpose of this question list.  Again: I am not offering to answer these questions for you. I am offering these questions as a starting point for your own journey of exploration and learning.  I encourage you to use them.

Now: the original post:

I’m proposing an “idea” to present for the Agile2013 Lightning Talk stage under the Process At Scale theme.

Title: No Estimates

Talk summary: Ask a lot of questions, answer a few.

Please vote for it here: Agile2013 Lightning Talk On No Estimates

Here are the things I have been asking myself about Estimates:

  • What are estimates, anyways?
  • Are estimates useless? wasteful? harmful?
  • Who needs them? Who is asking for them?
  • Why do we think we need them?
  • Can we have successful projects without estimates?
  • When will this be done? How much will it cost?
  • How can we decide if we should do a project without knowing the cost?
  • Is NoEstimates better than MoEstimates?
  • How expensive are useful estimates?
  • How useful are inexpensive estimates?
  • If it takes you “no time” to do estimates, are they of any value?
  • If estimates are waste, would you still do them?
  • Is the reason you do estimates because “someone requires I do estimates”?
  • Why do they require you to do estimates – is it because someone “higher” is asking them for estimates?
  • When someone asks for an estimate, what do you do?
  • When estimates don’t work well for us, should we just get “better at doing estimates”?
  • If estimates are useful and easy to do, why do we still have so many problems with estimates?
  • How would you plan a project if you were NOT allowed to do estimates?
  • Can you imagine any reason why estimates might be harmful?
  • Can you imagine some better way?
  • How important are predictions?
  • Can you “sell” programming without estimates?
  • What about estimating the “value” of a feature?
  • Are there things where estimates make sense?
  • What is “No Estimates” anyway?
  • If estimates are good for some things, does that mean they are good for everything?
  • Does “No Estimates” mean we don’t use estimates at all?
  • What are “Whole Team Estimates” and does it help at all?
  • If you are estimating about work you don’t yet understand to be done by someone you haven’t yet hired, is that meaningful?
  • How much are you willing to invest in estimates to get useful information from them?
  • Does it matter how good estimates are: are “wild guesses” good enough?
  • Are the decisions you are making that are based on estimates good decisions?

We’ll ask some of these questions. Perhaps explore a few ideas. Maybe answer a few.

Stuff like that.