Design sessions is one practice that most agile teams will find themselves engaging in from time to time. For some teams it will be completely informal (just get everyone together for 10-15 mins whenever you think it is warranted), for others it becomes more of a ritual where most non-trivial features get a once-over in a design session before implementation proceeds.  There are many benefits to having regular design sessions with your team mates:

• an opportunity to share knowledge about a particular area of the system with the whole team
• an opportunity to validate design decisions before implementation gets too far
• promotes collective ownership of code as everyone has some stake in most non-trivial design decisions
• gives an opportunity to brainstorm (brainstorming is not used nearly enough)
• an opportunity to identify areas that are potential refactoring candidates
• gets everyone more personally invested in the solution
• gives people a break from cutting code and gives them an opportunity to engage in an alternative but still useful activity
• an opportunity for the team to bond and ‘gel’ further

At least those are all the benefits that a design session SHOULD provide, but more often than not the potential of design session goes sadly under-utilised by many teams. Any sort of design session will provide some of the above benefits to some degree, however our goal as software developers and agile practitioners should always be to get the maximum benefits from all the practices we employ. So is there anything we can do to ensure we get the most out of a design session?

A Typical Design Session Scenario

A typical design session is a pretty informal affair and usually occurs when a pair would like some input from the rest of the team into the best way to implement the feature they are currently working on. When a pair calls a design session the rest of the team gathers in one place (usually in front of a whiteboard) where the team would proceed to outline the problem they are looking at as well as potential solutions that they have come up with. The pair running the session would normally use the whiteboard as a visual aid to help represent the problem and their solution (or solutions).

Ideally the rest of the team would have some insight into the problem and would offer better solutions or critique and improve the solutions that the pair running the design session has proposed. After some back-and-forth a solution that most people are happy with would emerge and everyone goes back to what they were doing before while the pair that called the session proceeds with the implementation.

While there is nothing overtly wrong with this scenario (and many teams would do well to even have that as one of the practices they follow), I believe there are many opportunities lost when a design session similar to the above occurs:

• not everyone is an extrovert and since no particular effort was made to engage the more introverted people their knowledge/ideas may go unheard/unused
• it takes a while to switch mental gears, since no particular effort is made to snap everyone out of the mode they’re thinking in, interesting ideas/solutions may not occur to some people until long after the design session is over
• only visual clues (whiteboard) and audio (verbal explanations) are used to represent the problem and the solution, many people work better with tactile clues (use physical objects to represent the problem), or by seeing themselves as part of a larger abstraction (acting it out)
• by presenting a solutions at the start, potential creative solutions are stifled as it puts the team into an analytical mode (analysing the presented solutions) rather than creative mode (coming up with innovative solutions)
• design sessions can sometimes be a serious affair and so an opportunity for “play” (while still doing something productive) is lost (this is a fluffy one but worth a mention I think), a design session can be light-hearted while still providing all the value

A Much Better Design Session

A pair calls a design session in very similar fashion to the above. However before jumping into the problem, call for someone from the team a tell a joke or tell one themselves. It is unexpected in a work environment and will force people  to snap out of thinking about what they were just doing, it is also a playful start to the discussion which I think is never a bad thing as it gets everyone more relaxed. This also has the potential to turn into a design session ritual that everyone on the team can look forward to which will be something they share that brings the team closer together.

Before we draw the problem on the whiteboard, we explain it using just words and then we try and represent the problem using a tactile abstraction (i.e. build what you mean using lego blocks or chess pieces or anything that people can move and touch). This gets people thinking about the problem domain before you draw it i.e. forces them to think about it before seeing it in a familiar medium. The other thing you can do at this point, either before or after drawing, is to act the problem out using people as objects in the system. Many people learn and appreciate problems a lot better by actually doing rather than seeing or hearing about it. As an added benefit, this provides another opportunity for play, gets the less extroverted people more relaxed in a fun and friendly atmosphere and gets everyone primed to participate.

Do not present potential solutions you have come up with to the team, get the team to brainstorm first and come up with solutions of their own. Chances are they will probably come up with something similar to what you had, but they will have a lot more stake in it having thought it up rather than just validated the solution that the pair that called the session contributes. By not forcing your potential solution on the team you also have a much better chance of the team coming up with something truly innovative that you haven’t thought of (remember it’s analytical thinking – validating a solution, vs creative thinking – brainstorming a solution). Of course if noone can come up with anything interesting present your solution, you don’t want to get stuck in design paralysis.

At this point everyone discusses and agrees on a way forward and the design session is concluded. The difference is:

• the team was a lot more engaged
• everyone had fun
• people had a break from the routine
• everyone was heard (there were no chickens in the design session, only pigs)
• everyone goes back to their work feeling a lot more fulfilled
• the team has bonded together that little bit more

Agile Chickens And Pigs

At The End Of The Day

I have very strong opinions on design sessions. I believe they are an extremely valuable tool in the arsenal of any agile team. However I also believe that unless you can fully engage everyone on the team (who is present at the design session) and get everyone thinking creatively (and potentially in a different mode than they would normally) you’re wasting a large part of the benefit that a design session can provide. Do you use design sessions in your team (if so do you use them as fully as you can) and do you get a lot of value out of them? I’d love to hear what other people have to say on the matter.

Related posts:

1. Effective vs Ineffective Pair Programming
2. Who Deserves The Credit For Software Craftsmanship and Great Design?
3. Why Your Developers Don’t Want To Swap Pairs – Practical Agility

Pair programming has always been one of the more controversial agile practices. Mostly because it is damn hard to sell to management (at least the unenlightened kind of management), we’ve all heard the old “double the cost for the same work” excuse. To those in-the-know that excuse is patent nonsense, those who’ve done it are well aware of the benefits that it brings even if they do sometimes find it hard to verbalise just exactly what those benefits are.  Pairing brings all sorts of benefits:

• organic code review
• less bugs, which means less maintenance effort
• detecting problems early
• more focused effort (harder to procrastinate when person next to you)
• etc.

The most important benefit in my opinion is the fact that pairing is highly conducive to organic knowledge transfer (“pairing is knowledge sharing” for the poet in you). I believe this is key since in a large system there is literally no other way to do this well.

It is however interesting to ask exactly why pair programming brings those benefits and this would directly lead us to ask if there are any situations where pair programming can be less effective and what we can do to mitigate that.

What’s So Good About Pairing And Why It Works

The  reason I think pairing works so well is the fact that the “driver” and the “navigator” are mentally in completely different places. Andy Hunt explains this really well in his “Pragmatic Thinking & Learning – Refactor Your Wetware” book. The driver is focused on the nitty-gritty of the code, his mind is in its analytical mode (his left brain is more engaged) and he is more focused on the “small picture”. The navigator on the other is more focused on the bigger picture and due to the fact that he is not actually busy driving his mind is in its more intuitive mode (his right brain is more engaged). This means that the navigator is more able to see patterns and abstractions that the more analytically engaged driver will tend to miss.

However in order to be able to see the patterns and notice the abstractions, good system knowledge is invaluable (and the best way to gain it is through pairing so this is sort-of cyclical), which brings us to 4 situations where pairing can be either less or more effective.

The 4 Pairing Situations

The 4 situations are as follows:

• the driver and the navigator both know the system/area well
• the driver knows the system/area well, while the navigator does not
• the navigator knows the system well while the driver does not
• both the driver and the navigator do not know the system/area well

Driver and the navigator both know the system/area well

This is the ideal situation (obviously), and there is no need to say to much about this, when pairing having both people well versed in the system will ensure maximum effectiveness.

Driver knows the system/area well, while the navigator does not

This is a lot less ideal, in this case the person with the most knowledge of how the system works is in their analytical mode and is a lot less able to see the bigger picture and pick up on the appropriate patterns and abstractions. More than that, since as the driver they are focused on the task at hand and are actively busy/engaged they are potentially less able to share their expertise with their partner. The navigator is also extremely hampered by their lack of system knowledge, not only are they limited in their ability to help the driver, but they will also tend to feel frustrated and unfulfilled.

Navigator knows the system well while the driver does not

This situation is a lot better. In this case the person with less system knowledge is fully engaged as the driver, the navigator on the other hand is able to guide the pairing effort and is still able to see the code from a right-brain perspective. The navigator is also able to maintain a stream of commentary about the system for the driver to absorb. The downside here may be that the work proceeds somewhat slower due to the lack of system knowledge on the part of the driver. This can however be mitigated by discussion between the members of the pair before proceeding to do the next step in the work.

The driver and the navigator do not know the system/area well

From the perspective of getting some work done this is the worst situation to find yourself in. It can however be quite a lot of fun to dig through code you don’t know, as well as find and recover from mistakes together. The danger here is due to the fact that neither person is potentially able to appreciate the bigger picture -  the quality of the work can suffer and it can be inconsistent with the rest of the code in the system.

It is difficult to mitigate lack of system knowledge, there is always a significant amount of time and effort involved when the system is of reasonable size. I believe there are 2 ways to ensure that pairing brings benefit no matter what the situation:

• the person with the most system knowledge should spend the majority of their time being the navigator rather than the driver, in this way they can bring the most benefit to the system as well as to their partner
• both members of a pair need to ensure that they are constantly proactive both in learning and in teaching

Do you think there are other ways to make sure that our pairing efforts are always optimally successful? Feel free to leave a comment and let me know.

Related posts:

1. The Real Measure Of Code Quality
2. Why Your Developers Don’t Want To Swap Pairs – Practical Agility
3. How To Get The Most Out Of Your Design Sessions

A few days ago I was asked where I thought Agile adoption was at right now. After giving a long and no-doubt confusing answer I thought I would write it up as well. After all if I had to confuse one person I might as well confuse and bore a whole lot of others while I am at it. Therefore, here is where I think the agile world is right now (oh and by the way, the adoption rates below are my own opinion and are based purely on keeping a ‘finger on the pulse’ not any statistical evidence):

The SCRUM People

Scrum is by far the most well known and widely adopted process right now.  Scrum is becoming almost synonymous with agile with some of the biggest names (Ken Schwaber, Jeff Sutherland etc.) in the agile world pushing scrum as their process of choice. Scrum is one of the few agile process that has a certification path (as offered by the Scrum Alliance) and this is probably one of the main reasons why Scrum has become the most widely accepted agile process. Of course the fact that Scrum bundles the majority of XP practices into itself probably doesn’t hurt it much either, infact Scrum couldn’t exist without XP practices.

Adoption Rate: ~ 10%

The XP People

XP is probably the original Agile process if anything is. It is pretty much a set of common sense practices to make software development better. Many of the practices support each other but there is no common framework that ties them all together. This is probably why many management-type people don’t really like it much it makes them feel useless and unnecessary. But since we still have to work with all sorts of people including management-types, just about every single other agile process tries to wrap XP in just such a framework (see Scrum above).

Adoption Rate: ~ 7%

The Other SCRUM People

Of course when something starts to enjoy a bit of success and someone starts making a good living from it, other people get envious of that tasty pie and want to get themselves a piece. These people are disillusioned or simply want to make some cash without being bound by someone elses rules. This is what is happening to Scrum right now. With Scrum becoming more and more successful a lot of people come out all critical about how regular Scrum is not quite right and how they have a much better Scrum (Is Scrum Failing Us?). The Scrum certifications are all bad and how they have bigger and better certifications (Scrum Master Certification By Net Objectives).

Adoption Rate: ~ 2%

The Lean People

Then of course there are people who really want to be different so they come up with a whole different process and even give it a different name and since these people might even have a name within the community their ideas gain instant recognition (http://www.poppendieck.com/). No matter that the ideas they espouse were always part of the Agile spirit, just the execution may have been faulty (agile doesn’t kill agile, people kill agile). But hell, why not, let’s re-brand – it worked for SOA.  The point is to create a niche, so that more consulting can be offered and more books can be written and if we happen to help people write better software at the same time, well that’s just an extra benefit.

Adoption Rate: ~ 3%

The People Who Are Over It

Inevitably there are people who are sick of it. After all Agile has been around for a decade or more now, there are bound to be people who just can’t be bothered any more. I wrote about it before it’s called post-agilism. Sometimes you just get sick of arguing about process. You just want to write good software and deliver value. You know that you can’t please everyone, you know the good practices and the bad ones. You try to maximize the good ones and minimize the bad ones and do as good a job as you can under the circumstances.

Adoption Rate: ~ 8%

The Clueless People

For those of us who are into the whole Agile thing it might sometimes seem like the whole world is jumping on the Agile bandwagon. After all most of the job ads these days list Agile as a mandatory skills and everyone seems to be talking about it. Nothing could be further from the truth. The vast majority of people have absolutely no idea, they’ve heard of this Agile thing but they don’t know what the hell it’s all about and they don’t really care. They might be happy to bandy words but can’t really be bothered changing the way the work. This applies to both individuals and companies. Even if they are trying to pay lip service to the Agile way, they do it in such a half-arsed way as to make it completely meaningless (quarter-arsed).  Into here we can also bundle the people who think they are doing agile but they aren’t, people whose upper management says they are doing agile and a whole host of other types of dudes who make this bucket by far the biggest out of the ones I listed.

Adoption Rate: ~ 70%

Conclusion – Things Could Be Better

There you go this is the state of the agile process adoption world as I see it right now. That’s right, I didn’t include all the other agile and quasi-agile processes such as DSDM, FDD etc. ; that’s because I think we can either easily lump them with one of my categories (e.g. lump DSDM with the clueless people), or their adoption rates are small enough to neglect, or maybe I just don’t care to mention them.

The Agile world seems to be splintering into smaller and smaller bits as more and more people, disillusioned for various reasons, try to peddle their own brand of process.  While this is going on everyone seems to forget the fact that just about any brand of Agile is better than waterfall or ad hoc. Rather than presenting a united front and forcing crappiness, like waterfall, completely out of the software development profession we are like the Greek city states with the giant Persia sitting dismissively on our borders. Except there is no Alexander in sight to unite us all and show them what’s what.  I hope you enjoy that little bit of allegory.

Related posts:

1. Are You Actually A Post-Agilist?
2. Before There Was Lean, Agile Or Waterfall There Was Theory X, Y And Z
3. The Most Important Agile Practice Of All

Have you heard that term? I happened upon it purely by accident about a year ago and after reading and learning a bit about it I found that I could identify with it quite a bit. You can read Jason Gorman’s post Post-Agilism Explained (Pretentiously) as well as Jonathan Kohl’s massive post – Post-Agilism Frequently Asked Questions for a great discussion of what the post-Agile movement is all about. Jonathan and Jason independently coined the term at about the same time so they are an authority on the term if anyone is. I am going to attempt to give my humble views on the topic and hopefully you will identify with some of what I say.

For those of you who’ve decided to learn about post-Agilism after they finish reading this post (thanks!), post-Agilism is basically a movement in the software development community of people who see themselves as moving beyond Agile methods. They have used Agile and not-so-agile methodologies and have moved beyond both to using an amalgamation of tools and methods that best facilitate them doing their job. Post-Agilism is not about evangelizing a particular process or a set of practices or even the Agile Manifesto, it is about getting to the core of the issues that process in general tries to address and solving them in the best ways possible. At least, this is the way I see it.

Post-Agilism is not about rejecting the Agile practices, it is about not limit yourself by Agile practices. I think the original spirit of the Agile movement has now become the spirit of the post-Agile movement as Agile is becoming less about the spirit and more about pushing a particular Agile process as the best one (there are so many to choose from now). At first it was Agile vs heavyweight; now it is still that, but it is also Agile vs Agile (we are an XP team we are the best, no we are clearly superior for we are a Scrum team!).

I for one get extremely annoyed sometimes at process vs process discussion (be they Agile or not), I see them as completely pointless. One of the core ideas behind Agile which most often seems to be forgotten is the fact that you’re meant to adapt, to ‘bastardise’ the process and practices until you get something that works for you. This makes any kind of process/practice purist argument meaningless. This very agile idea of being adaptable, of chopping and changing to fit your needs is now also at the core of the post-Agile movement.

To me, the most important thing about a process is the ‘spirit’ of it, not the practices. Quite often these days Agile teams seem to loose sight of the agile spirit and I think the post-Agile movement is more about the spirit. When I say spirit I mean things like:

• respecting the individual
• communicating effectively
• doing work (writing code) that you could be proud of
• not getting bogged down in minutiae
• having some backbone when dealing with those around your team (i.e. stakeholders etc.)
• etc.

And all of these at the same time, not one by one.

If these sound suspiciously like the Agile Manifesto, they are meant to, the spirit of the Manifesto is very sound. If some of these sound strangely unlike the Agile Manifesto they are also meant to, the Manifesto is not the be-all, end-all of commandments that we live by.

This I think is also at the heart of the post-Agile movement, it is not about the process, it is not about the practices, it is about the spirit of agile, it is about the ideal. Use your knowledge to select the most appropriate tools, processes and practices, whatever they happen to be. There is no best length for an iteration, there is no best retro format, pick whatever works and discard it if it doesn’t, as long as you stay true to the ideal, you won’t go too far wrong.

Here is an example that might help make my meaning a little bit clearer. I’ve been interested in distributed Agile for a while now. So, what do you do if you ever find yourself working in a distributed environment with multiple teams that are not co-located? Trying to make the best of a bad situation while all the while moaning about how much better things would have been had the teams been located in the same place. That is NOT staying true to the agile spirit (alright, you can moan a little bit, good for the soul and all). Trying to find ways to effectively collaborate, to make things work better, to innovate solutions, to get to know the people on the other teams (rather than complaining about their ‘crappy’ code). That would be living up to the ideal, staying true to the spirit of agile, or post-Agile as the case may be.

I found myself in very strange territory of not being able to find the words to adequately get my point across with this post (I can usually express myself pretty well, and loudly, just ask anyone who knows me). Parts of this post seem overly existential to me while others just seem to tread over the same ground. I guess it comes from trying to express ideas that are almost subconscious for me. Hopefully this will have resonated with people on some level or at the very least given people some food for thought.

Perhaps some comments might help clarify matters for everyone. I’ve tried to explain my thoughts, so what does post-Agilism mean to you? Would you consider yourself a post-Agilist or are you still firmly in the Agile camp (or god-forbid, heavyweight)? Any relevant thoughts would be appreciated.

Related posts:

1. The Current State Of The Agile Nation – Agile Process Adoption
2. Rules Of Standup – You Don’t Need To Justify Your Own Existence
3. The Real Measure Of Code Quality

There was a comic going around a few weeks ago about code quality, you remember the one:

Pretty amusing, but it got me thinking, what IS a good measure of code quality? Quality after all is very subjective, what I might perceive as being great, you might perceive as crappy for a host of reasons. A pet pattern wasn’t used quite right, the unit tests aren’t “real” unit tests, you know of a library that would have made the whole thing 10 times easier, etc.

There are all sorts of different measures that might relate to code quality, the level of coupling, the testability of the code, the test coverage, adherence to standards and many others and yet all of these are still subjective to a degree. There are times when not adhering to standards is best, just as there are times when a low level of coverage is good enough, it is all different from system to system, situation to situation. So is there no one good measure of code quality?

I contend that there is only one measure of code quality that is worth anything. We can argue all we want about numbers and patterns but in the end, one thing will always be true for every good developer:

Every good developer intrinsically knows if his/her code is good enough!

That’s right, you already know if your code is good enough, if you think that you don’t then you’re deceiving yourself and need to ask yourself the following questions.

If you were to think of a developer you admire, would you be proud to show your code to that person or would you cringe in shame if they were to see it? By extension, if that person were to criticise your code for whatever reason, would you vigorously defend it with all your heart or would you put in a token defensive effort for appearance sakes?

Due to the nature of our work, developers are part artist, part craftsman and part scientist and the one thing that all those people share is the ability to know if what they’ve produced is worth anything. Therefore, before we go and try to find an external way to validate our code for quality (and that includes getting it reviewed by other people) we need to be completely unequivocal about our answer to the question:

Do I think the code is good enough?

If the answer is not unequivocally yes, then there is no point going any further and you have some work ahead of you. If the answer IS yes, it doesn’t mean the code is perfect and can’t improve, it means that only more knowledge and/or experience can make it better. This is when involving someone else is a good idea, sharing knowledge and experience is (partly) why we work in teams after all.

The above works even better for pair programming, but the question becomes:

Do we as a pair think the code is good enough?

This works better because as a pair your internal threshold for quality will most likely be higher than it would be for each of you individually and you’re already sharing knowledge and experience. The threshold becomes higher still if you regularly rotate pairs. Although I do believe there will be diminishing returns if too many people have a stake in the code, but if the story size is small enough, this should not be an issue.

Well, those are my thoughts on measuring code quality I wonder what everyone else thinks. Do you agree with me or do you perhaps think that I am way off base? Do you know of a better way of measuring code quality (no, WTF per minute doesn’t count)?

Related posts:

1. Are You Actually A Post-Agilist?
2. How To Be A Real Elite Programmer And Make Sure Everybody Knows It
3. Effective vs Ineffective Pair Programming