thekua.com@work

Anyone who has worked with me knows how crazy I am about Retrospectives for the workplace. I apply similar techniques when it comes to organising my personal life so I thought I’d share one technique I use that I call “Free Running Reflection”.

I adapted this technique from a “free-writing” class that clieu took a while back. I’ve found it especially effective for getting all those niggling things out of my head and in a place that I can see them and focus on doing something about them. It’s also been very useful under extreme times of stress, showing me things that may be unconsciously influencing my thinking.

I use four very simple thing to run this exercise: 15 minutes of time, a timer (watch, stopwatch, clock, etc) a pen and access to plenty of paper to write on. I normally carry around a small notebook (previously a Moleskin, and currently a great little Ciak one).

Here’s how I run it:

• Choose a time boxed period – I usually use 5 or 10 minutes depending on how much time I have.
• Start the timer and write down everything in your head on to the paper until the time runs out. Put down absolutely anything and everything that crosses your mind. A word, a phrase, a full sentence, and especially all random thoughts. I generally avoid pictures though sometimes draw small diagrams if it’s faster than writing a sentence. If you do draw diagrams be careful to keep them as simple as possible as the goal is to get everything going through your head down as soon as possible during the time period.
• With the remaining time, review what you’ve written down and see if there are common themes. Sometimes I draw lines between bits, or regroup items to help me discover patterns. Depending on how I’m feeling I will then decide if I want to do anything about the items on the list, and add the top three to my list of things to focus on and complete.

If you like this technique, or have any other recommendations, please leave a comment.

Comments(1)

Its Purpose?
Breaking down complex or larger blocks of work into very small, defined tasks helps people focus on learning one thing at a time. Each item should be as small as possible, with enough detail that the newbie either doesn’t need to ask someone how to complete it, or wouldn’t take them long to find out. Each task completed helps people celebrate small successes, and helps them make progress without being completely overwhelmed.

Photo taken from Controvento’s photostream on Flickr under the Creative Commons license

How did we execute it?
Our story cards are written on index cards, and before starting development we would discuss the requirements with our Business Analyst and Quality Assurance person. For each block of work, an experienced person would write down each task that might be needed to complete that block of work. Each tiny task would be as granular as possible and we wrote each on to a separate sticky note. We strung them together and put them on top of the story card on our wall.

A tiny task must be as simple and as clear as possible such as “New DB column to table X”, “Property to domain object”, “Modify Hibernate Mapping File” or “Refactor XXX domain object” with certain assumptions already being clear (i.e. each code task would have a test).

Tiny task lists can and will change, with our developers adding and removing more tiny tasks as they discovered more detail. Small to-do tasks found during development also ended up being written out as tiny tasks to be addressed at a later point. We would encourage developers checking in for each tiny task as much as possible although in reality this ended up being a small handful of tiny tasks (i.e. 3 or 4).

As people became more accustomed to the patterns in the system, and the things that might be needed to implement a small group of functionality, developers wrote tiny tasks less and less.

Why Is It Important?
People need successes to learn, and a safety net when they fail. Clear and easily achievable tasks help people build their confidence, either giving them a feel for how quickly they are progressing, or giving them a basis to talk over where gaps in their knowledge may be. Tiny tasks also give a certain amount of independence as some people learn certain things only by doing them themselves and either succeeding or failing.

Comments(8)

Its Purpose?
To help people understand what parts of the system have excessive code-smells and need either refactoring or redesign.

How did we execute it?

1. Maintain a list of the technical debt - We have a list of all the technical debt in the system on our wiki. As a team, we identify parts of the system we want to address as a whole and discussed different strategies for implementing it. Some of the debt stays on there until we all agree on a common approach, although we try to remove as much of it as we can, especially if they are small things
2. Walkthrough the list with new people - We sat down and expressed our concerns by walking through the list and explaining perhaps how it came about and what effects each item on the list have.

Photo taken from Jekemp’s photostream on Flickr under the Creative Commons license

Why Is It Important?
All big projects have some part of the system that doesn’t seem particularly right. Given commercial time constraints, you never have the time to address all the issues to make every single bit of the code perfect. It’s better to keep people aware of these compromises so you address them when you have time.

From experience, I’ve also found it’s very easy for new people to projects to criticise parts of the code that obviously aren’t ideal. It’s a very healthy process having new eyes on the material to bring a different point of view and offer different approaches, although there are better ways they can express their concern without making incumbent developers feel criticised.

Providing the opportunity to openly discuss all areas of the system the team would like to collectively improve each of them has been an effective way at meeting all of these goals.

Comments(0)

Photo taken from Radiospike’s photostream under Creative Commons.

Its Purpose?
Visible Architecture helps new team members form a common understanding about how the patterns and constructs in the system interact. It helps them to identify clearer boundaries of responsibility that should not be crossed. It may describe external or internal systems or devices the application may interact with and how they relate to the system. It may also help them understand how the application is deployed and configured.

How Did We Execute It?
We actually ran two sessions to complete this – one ended up describing the physical architecture and how it gets deployed. The other ended up describing the software architecture and focused on the patterns in the system.

For the physical architecture diagram, we drew on sheets of flip chart paper a box for each machine in one colour, then each executing application in another colour on the machines. We also drew circles around the boxes grouping them and gave them a physical name since the servers are grouped together but each group is distributed around the world. Each unique executable was given a code to which we drew a legend on the side to give them a name. We ended up with nine unique executables (it’s the most minimal set for our application requirements), though with many instances of these based on the redundancy needs and distributed nature of this application.

For the software architecture one we first drew onion ring layers of the systems, added labels to each of them and talked about which how the parts should interact and their dependencies. We applied this to the testing layers as well to demonstrate their dependencies on the onion rings that we just drew and their own set of onion rings. We also talked about the patterns in the system and in which layers you would find them.

Techniques Found Useful For Running It

• Flip chart or whiteboard – It was useful to be able to draw relationships between individual executables to show what parts really communicate with each other, and other ones that communicate or depend on a database.
• Colour codes – Given how busy our diagram got in the end, the colours helped people to easily identify what was what.
• Executable code names –Writing each executable name on every box would have taken a long time and made the diagram more confusing. It was more useful to give them a shorthand code such as XX01 or XX02 and to describe it on the side.
• Onion ring layers – Helped people solidify the boundaries to the system in their own heads.

Why Is It Important?
Architecture diagrams are popular for a big reason in many systems as they help people visualise the larger parts of the system. It forces people to take a broader look at the system and provides a better context for the smaller programming tasks. It helps them raise suspicions when one part of the system starts getting too tightly coupled to another as they can understand where the responsibilities lie.

I’ve found that ad-hoc and lo-fidelity diagrams are much more useful than using one built specifically in a single tool as anyone can adapt them there and then in front of everyone and it helps someone show questions they may not be able to ask.

Next Time I Might Try:

• Team Participation First – Getting team members to first draw up what they see as the patterns might help demonstrate where misunderstandings or gaps in knowledge lie and to have better idea of where to focus the discussions.

Comments(1)

Topics or books I need to look into after attending the XP2007 conference:

• The Five Dysfunctions of a Team: A Leadership Fable
• Satir Change Model
• DSDM Practices
• New Peoplemaking
• The Psychology of Computer Programming

Comments(0)