Mob Programming

What’s the most important “Agile Practice”? : Do Regular Retrospectives. Getting good at retrospectives is well worth the effort.

The basic idea is to take a look at how things are going, decide on some thing (or things) to make better, decide on action(s) to take, take the action(s), and then repeat the whole thing sometime soon.

We do frequent retrospectives. As a team, we like to reflect, tune, and adjust every chance we get.

We did a retrospective back in August about “pain points” with the purpose of identifying things that were daily “pains” for us.

This is what the affinity groupings and other “artifacts” looked like over a few months (Aug. 8 to Oct. 25).  I’ll cover a little of each below.

Pain Points

In our first retrospective in this series, we found that two important areas that showed up as “pain points”.  One of these areas was developer skills.  Here is the affinity grouping about developer skills:

The items include:

• Code fluency
• Coding skills
• IDE skills
• Typing skills
• Language fluency (C#/SQL)
• Resharper Skills
• Shortcuts

Give it a name

When an affinity group gathers enough post-its to clearly show we have an area we feel needs fixing, we try to come up with a name for it.  This one was easy to name: Developer Skills

We always discuss the things we discover during a retrospective and try to find some action we can take.  In this case, we decided to take some time to mull things over and meet later to discuss how to proceed.  We are flexible – remember: no practice is written in stone. Except for DO RETROSPECTIVES.  That actually IS written in stone.

The basic process we followed for this particular discussion was similar to a “Lean Coffee”.  We all suggested topics and wrote them on post-it notes, prioritized them, and discussed them in prioritized order, taking a few minutes per item, until we had sufficient actionable ideas.  We gathered a list of about 20 ideas on ways we could improve our developer skills, and we talked over about half of them.  Some of the ideas seemed to fit together naturally so we grouped them, and pretty soon we had a few things we decided we’d like to try.   These are what we call “action items”.

Here is what we ended up with:

Action Items

Here is what we decided to do

• Create a “cheat sheet” or “check list” for the steps for some common tasks
• Review and learn the motivations behind some code generation we were doing
• Hold a daily 1-hour practice period focusing on MVC, TDD, and basic coding skills

A Daily Practice Period!!!

Well, what do you know.  Seems like something we should have been doing from the start… I think we had talked about it now and then over the past year or so, but that’s how it is with good ideas sometimes: they stay stuck on the back burner until they’ve simmered just enough and then we move them to the front, I guess.  For over a year and a half we have had a weekly study and practice period and it has been very beneficial, so in the spirit of Extreme Programming – we decided to try doing a daily practice period.

We’ve been using the “practice” of daily practice for about 4 months now – almost every morning we practice doing a coding activity.  We’ve refined it a bit over time, but the basic idea has stayed pretty much the same.

Another Retrospective, another step forward: The 12 Days of Index

After a while (about a month I guess) we had another retrospective about our practice sessions, and although things were very positive we noticed that we were not gaining a mastery of one of the things we were practicing: Creating an Index controller and it’s related parts and tests.

We discussed our approach and a few ideas we might try.  One approach we adopted is very similar to how I used to practice the banjo when I was first learning (many, many years ago):

• Practice a little bit of a tune you want to learn (just a measure or two).
• Once you have that down, learn the next little bit in isolation from the part you already learned.
• Once you have that down, combine it with the part you already learned, and practice those together until it works nicely.
• If the transition from the first part to the second part gives you trouble – isolate and practice the transition.
• Once you have the “combined parts” working well, learn the next little bit, then combine…
• And so on.

We gave this “practice of practicing” a name: “The 12 Days of …” (you fill in the …. with the name of the thing you are practicing).  It is a little like the song “The Twelve Days of Christmas”.  You sing the first part alone, then the second part AND the first part, then the third part AND the second part AND the first part.  Hopefully, you get the idea.  So, in this case since we were practicing the coding of an Index Controller, we called it “The 12 Days of Index”.

The concept is to truly master each small part “in order”, adding the result to what we have already mastered.  Everything is learned “in the small” and builds to encompass the whole concept we want to learn.  So far, it’s been working pretty good.  We’ve had a few retrospectives on this since we started using “The 12 Days of …” and we’ve kept it so far.

Things to notice

• We pay attention to try to figure out what needs attention.
• We experiment and try things that might be an improvement.
• We review and make changes as often as needed.
• We name things in a way that makes it easy to “get the idea” and talk about what we do.
• We practice doing the work we do.
• As we become better at a practice, we start to look for ways to improve that practice.

So… have fun, retrospect, and keep on practicing.

One last thing.  We are starting a regular practice session for practicing retrospective techniques.  There is a great book on the subject: ”Agile Retrospectives: Making Good Teams Great” (Diana Larsen and Esther Derby) – I’ve actually worn out my first copy of the book.  I ordered 6 new copies of the book and a group of folks here at work are going to get together weekly to practice the the techniques in that book.  Very cool. We are now retrospecting on our retrospectives, and practicing getting better at it.

Meetings are great

Meetings are great.  I’m pretty sure that we would all prefer to have meetings all day if we could.  But life isn’t perfect.

Not Really

Ooops. Did I say Meetings are great?  I meant to say meetings are mostly USELESS.  Note I said mostly – not all, just mostly. To clarify (so people won’t complain too much): In my experience meetings are typically not an effective way to get things done.  Seems like they should be, but they AIN’T. Mostly.

[Disclaimer: If you haven't already guessed, I am talking about meetings in software development.  Nothing else. Especially whatever it is you do, unless you are doing software development.]

Regardless, some meetings are ‘necessary’ in some organizations.  Did you notice the clever use of quote marks around ‘necessary’ in that last sentence?  That is my way of saying ‘mistakenly thought to be necessary’.

Like I said, life isn’t perfect.  Stranger still, in some rare cases meetings are actually useful.  Please don’t quote me on that.  It’s just between you and me.

If you MUST have meetings then make them meaningful.  I can’t help you much with that in this post.  Maybe some other time.  I’ve seen a lot of articles, book chapters, books, and training materials on “how to have effective meetings”.  You can even take week long trainings on this. So, read those, take the courses, listen to a podcast about it, and then make sure that whatever meetings you have are effective.

Teamwork

Teamwork is about people working together to do something.  If your work lends itself well to teamwork, being good at working as a team might pay off.  Working together is not the same as a meeting.

Definitions

A few definitions of words as used within the scope of this article:

Team: All the people needed to create the software being creating and who work together to get the software created. (Also goes for maintenance work).  ALL the people needed MUST work together.  Otherwise – it’s not really a team AS DEFINED FOR THE PURPOSES OF THIS ARTICLE.  Okay?

Teamwork: Teamwork is people working with each other to create the software they are creating. The key part of that is “working with each other”. Teamwork is working together.

Meeting: A gathering of people to communicate about the software they are creating.  Examples: Daily Standups, design meetings, requirements gathering meetings, bug assessment meetings, planning meetings, etc. [I am purposefully NOT including these: Retrospectives, Lunch, Trainings, Pair programming]. Meetings are often used for deciding things, communicating things, assigning things, allocating things, and selecting “action items”.  Rarely for doing the work of creating software.

[Disclaimer: You don't need to work as a team to create software, even when many people are involved.  You can have meetings, communicate via documents, send emails, respond to emails, forward emails, draw charts, email charts, correct charts, completely redo charts over and over, create requirements documents, have more meetings, sign-off on things, base-line things, hand-off things, then repeat, eventually write code, enter test and fix cycle, desperately polish up resume, and so on. There are lots of ways to manage making software.  Good luck on that.  Some famous person once said something about "the definition of insanity" that would be appropriate to point out and reflect on here.  Please recall that quote and chuckle at how appropriate it is.]

No Meetings Rule

Strive to arrange how your team works and interacts so that you never find a need to have a meeting.  That’s the rule.  It’s something to shoot for.  In some workplaces I’ve experienced this, and in some others I haven’t, and I’ve seen lots in between.  The key here is to get as close to this as possible.  It’s a lofty goal.

Meetings are a “smell” in your “process” in the same way that long methods are a “smell” in code, and in the same way that the rotten egg smell is a “smell” in your living room.  These smells are indications that there might be something that needs to be fixed.   Potential solutions (respectively): Fewer meetings, shorter methods, smaller pile of dirty socks in the corner.

Of course, fewer meetings need to be replaced with some other way to get the work done that you are trying to get done that we thought the meetings were helping us do.  Got it?

But Woody, how can we work without meetings?

If everyone works together in the same space (more or less), and is working on the same things (more or less) at the same time (more or less) then we are working as a team (more or less).  Hopefully you can see that this eliminates the need for meetings.  But really work towards the more than the less in each of those.  It works like this:

Same Space

If everyone needed for doing this work is sitting within easy talking distance then communication can be made “in real time”.  Easy talking distance is 5 or 10 feet with no walls, doors, or cubicles in between.  When I have a question I can ask it – and get a response right away.  If no one knows the answer, we have discovered something we didn’t know – right away!  This is always fantastic.  The less time it takes to get answers and discover the things we need to discover, the better off we are.  Being close physically allows us to be close “in time” as well.

Same Things

A “greater than the parts” effect happens when we all work on the same thing. This idea of  synergy happens easily when all the brain-power and effort is being applied to the same thing.  The answer to a question is likely already in the brain of the person being asked (the askee?) because the asker and askee are thinking about and working on the same stuff (more or less). And if that answer hasn’t yet been thought about, it is simply another thing we are going to pay attention to RIGHT NOW, because it is what WE are ALL working on.  It is no interruption for the askee because she is working with the asker on the same stuff.  Ideally, WE are all working to get the same exact thing done and delivered.

Same Time

When the whole team is working at the same time on the same thing we shorten the feedback loop for all interactions.  Work speeds up by an order of magnitude (your mileage may vary). The conversation happens quickly -

• Asker: “I was wondering about how this detail fits in” -
• Askee: “Yes, it’s like this…”
• Asker: “That’s not what I meant, I am asking about this part of that…”
• Askee – “Ohhhh, I see, right – it’s like this…”
• Asker – “Great! thanks”

That might seem like an exaggeration.  However, even when we don’t know the answer, the quick communication gets to the point very quickly:

• Asker: “I was wondering about how this detail fits in” -
• Askee: “Yes, it’s like this…”
• Asker: “That’s not what I meant, I am asking about this part of that…”
• Askee: “Ohhhh, I see, right – you mean this thing here?”
• Asker: “Yes, that is where I am stumped”
• Askee: “hm, I’ll need to figure that out.  I’ll do that now… can you help me look at a few things?”
• Asker: “Sure! Let’s take a stab at it” (This is LTASAI driven development, by the way).

Okay.  This is just a little, quickie blog post so I’m not covering all the types of communications we need to make. Hopefully you get the idea.

Working in the Same Space,  on the Same Thing, at the Same Time “side benefit”

To do this same space, thing, and time approach we need to have relatively small things to work on.  Very little of what we do is “small things”, but almost everything we do is made up of small things. You get the idea.  BREAK IT DOWN.  But, only break it down just before you work on it.  You have a pile of big things to work on (some call that a backlog, but it’s just a pile of big things to work on). The key is, that “backlog” is a pile of BIG things.  You peel off a small thing when you are ready to do more work, and you work on it – all together, in the same space, at the same time.  If it turns out to be too big, you’ll discover that – and you just peel off a smaller bit.  If it’s dependent on something else, you’ll discover that and you’ll work it out.  I have confidence in you.

So the side benefit is you will need to get really good at breaking things down and working on the smallest reasonable part of everything you work on.  They’ll tell you it can’t be done.  Prove them wrong.

But Woody! We still need meetings for certain things

Of course you do! I’m just suggesting that more and better teamwork is a way to lessen the need for meetings.  It’s like this little paraphrasing of one of the Agile Manifesto Principles.  We can call this the Principle Of Meetings:

Simplicity – Maximizing the number of meetings NOT HELD – is essential.

And remember.  There is no Agile Manifesto Value of “We Value Meetings Over Getting Work Done”.   Although, way back when, I have worked at places where it seemed that way.