Scalable Lean and Agile, QCon London 2011

qcon-londonToday was the first day of QCon 2011 in London that I attended. I thought about sharing what I remembered while it is still fresh in my head (and the head is buzzing with ideas).

Craig Larman spoke at opening note and at one of the sessions. Embarrassing that it is, I never heard about Craig before, neither I read any of his books. I did enjoyed the way he presented his material.

Craig was talking about scalable, distributed agile teams. Apparently he has a lot of experience working in this kind of environment, gathered throughout many years of his professional career.

Craig described a typical situation where delivery teams are physically located in different countries, working on the same project. In his presentation he provided practical tips for dealing with issues that rise in distributed environment.

The most important points that Craig delivered in his presentations are:

  • No disperse team – all the teams are sharing same goal and work as equal partners. There should be no hierarchy in teams.
  • Practices should be shared and guarded by Committees of Practice. Committee should have a leader that gets slack time to overlook the Practice and organize teams appropriately.
  • Software design should emerge as a collaborative work during workshops. Embrace open space in the office and lots of white boards.
  • Diverge and merge – teams should come out with design on their own sites, then they should hold Video, show and tell session with all the other sites.
  • When teams come with design on a specific part of the system, team leaders should work across all teams to have a common design for the whole system.
  • A documentation workshop after iterations embraces knowledge sharing and collective code ownership.
  • Avoid PowerPoint architects. Architects that are so far away from the code that they became architecture astronauts.
  • Component guardians are team members who look after code across all the teams, making sure that high quality is kept. If only one team takes care for only one component, the crap code is going to be maintained and accepted within. Teams needs to be cross component and cross-functional.
  • When components involve public interfaces, start with weakly typed, for example do ( aMap ). Once you know more and more code is stabilized you can make those more formal and strongly typed.
  • Continues integration is a must have.
  • There is a need to see the people across all teams. It builds trust and respect. Try to use cheap technology like Skype and web cams.
  • Team members should meet, rotate and travel to other sites.
  • Keep on thinking and adapting your methodologies and processes. Never retire.

Above points are mainly from the keynote Craig was giving. The second session was more about contracts and collaboration on “offshore” delivery model.

Some more interesting points:

  • Outsourcing development you will have to deal with culture, language, knowledge, domain, skills difference issues.
  • Address skills difference via internal education. Brown bag sessions or workshops made by more experienced team members.
  • Avoid single point of contact with the team. Visit teams before project kick-off. Physical contact is very important to create relationship.
  • Ask and rephrase questions in different way (or from different viewpoint) to test the answers.
  • Encourage team members to say no when needed, remove fear.
  • Don’t patronize teams capabilities by giving simple, disconnected tasks. This will reduce morale and make people leave, as they would think their job sucks.
  • Before project kick-off organize Domain Workshop (so the team can understand the domain) and Vision Workshop (so they can understand what to deliver).
  • Specification by example.
  • Make sure team is stable as much as possible (no leavers and joiners).
  • Make it clear that at the end of every sprint you are expecting a shippable product with the number of functionality developed.

Many of the things that Craig was talking about can be found in his book “Scaling Lean and Agile development”.

Many more info and a good introduction to Lean Software Development can be found at Crag’s web site. You can also enjoy a video of him telling a bad joke 🙂

Cheers, Greg

Frame – works?!

 

For last few years I’ve been listening to software architects having conversations about frameworks that should be used and where. There are always different opinions. Heated discussions. At the end, decision is made that turns out to be a pain in the developer’s back.

What is framework?

Framework is the common piece of code that provides some generic functionality, that could be reused. All the frameworks are created with the aim of solving some kind of a problem. I like to think of frameworks as tools with default solutions.

In software development the multitudes of frameworks are great. There are testing frameworks, for writing your tests. Dependency Injection frameworks for all your DI needs. Multitudes of web frameworks for every possible programming language that could serve html.

Framework creation

I was involved in building up the frameworks. They were designed for specific technology, with the purpose of solving particular problem. Once they had been created, people thought of those frames to be good at solving any problems.

Unfortunately, those frameworks were designed to deal with few issues one had. It is possible that by chance you might deal with exactly same problem and the framework would suit you.

Framework on steroids

There are frameworks that became monsters. The architects of those, started with a simple idea and developed them into mammoth projects. Those frameworks are trying to solve all your problems. All they do at the end, is creating more.

Process of selection

As I mentioned earlier, one designed a framework to deal with a specific problem, that is why most likely, it will not solve yours in exactly 100%. During my development life I have learned that there is no single Software project that looks the same as the other.

That is why you should leave some room for yourself when you select a framework. Don’t rely entirely on all the framework features. Don’t bind yourself to one framework as well. If there is a way, try to shield yourself with some kind of abstraction, which can be easily manipulated into another framework.

Avoid frameworks on steroids. If you are going to go the route of it, you’ll end up hacking around it, or putting up with it and jeopardising your design.

One tool to rule them all

I don’t like to use one tool to solve many problems. I always compare it to a use of a hammer. You can perfectly drive a nail into a piece of wood with it. I’m sure you can as well cut a wooden plank with a hammer but unfortunately the result might not be as pretty as if you used a saw.

Simplicity is a bliss

According to Dr John Medina, human brain is constantly learning, trying to see patterns, matching them and generalise. This is what we tend to do when it comes to a software design. We often see patterns in places where there aren’t any.

I was once at a brilliant presentation delivered by Dan North on architecture design. The bottom line of it was, that we should take a step back and look at what we are doing as the solution might be much simpler without any fancy framework.

Greg

Tests revealing design problems

Within last few months I was introducing tests into untested code. It was not old code, just some code that was not Unit Tested. As much as I was eager to do so, I found myself getting in a bit of a pickle.

 

Code complexity

Code was actually quite complex and difficult (smell) to understand. I was also a little scared that I will misunderstand the code and its intention. I assume that I will not be the only person facing this problem while working on the piece of code.

Fortunately there was some testing coverage in a form of a higher level Acceptance tests (not sufficient though).

I decided to refactor the code a little to make it more manageable. Extract few methods, rename few variables, remove unnecessary conditions and loops, etc.

When I finished refactoring and made sure build was still successful, I checked in the code and off I go to write some Unit Test. That was the point when I hit another brick wall.

Instantiated dependencies

Necessary dependencies in a class that I wanted to test were not provided to an object upon creation, but were instantiated internally. This means that code is not flexible to changes in a future and is impossible to test (smell). Making all the dependencies passed through constructor will make it more obvious to what the class will do, and make it possible to unit test.

So, after some refactoring again, building and submitting the code, I had my dependencies all wired up through constructor, just the way I like (mmmm, delicious).

Concrete classes

Many of the dependencies were still concrete classes. Pity, actually you don’t care what’s in the guts of your collaborators (most of the time) as long as they do what they indicate. This could be replaced by interfaces (or some abstract types in worst case) as dependencies. They also make it easy and simple to stub or mock your collaborators, so the testing is simpler to setup and you’ll be testing only the correct object.

Another refactoring session ended in a bunch of new interfaces.

So I started to write a test. I created my object and started to pass some dependencies. The problem was that I had to pass some other dependencies to those dependencies, and dependencies of dependencies and even more dependencies and … you know where this is going.

This great monster had too much setup code than the one I was going to test.

Too many collaborators

This got me into thinking that something was not right. The thing was that the tested class was trying to do too much. This was the main reason of mentioned previously code complexity. Testing was not easy and possibility of introducing new bugs during future changes was great.

So, extracting few methods here and there (around same functional area) and I was able to pull those methods into new object. This new class was very simple and was responsible for one area of functionality only. I could unit test that new class.

Last problem during the tests was that I got some unexpected behaviour. As I looked into the code it turned out that there was one more smelly thing left.

Static methods

There was some code that was calling to a static method of another class. It was impossible to mock or stub it. What’s even more horrible, it was using some internal static variables. That caused some un-expected behaviour.

Summary

As it turned out, I found problems in a code even before I started to write a single line of test. Just thinking about the ways to test, revealed first issues. More of the issues appeared while testing. The work I had to do in order to make code tidy, simple and testable could be avoided by writing it in TDD/BDD way.

I’m convinced there could be more problems revealed. Here are these that I found once again:

  • complex code
  • instantiated (new Foo()) dependencies inside tested class
  • concrete classes with no interfaces
  • too many collaborators (class was doing too much)
  • static methods (brrrr)

Greg

Agile (not) multitasking

So I did the talk. It was scary. I was stressed all the time, until I finished. I actually enjoyed questions session. They were very good. Unfortunately, sometimes there is no simple answers.

agile-multitaskin

http://skillsmatter.com/podcast/agile-scrum/agile-multitasking-and-context-switching

One of the participants created a great blog post summarising the talk: http://blog.agile78.co.uk/?p=132

I lost a lot of good thoughts I could deliver due to stress. First time is the worst one. Should be down hill from now on 🙂

Not too long ago there was an article on a subject of women multitasking better than man. I was looking for some research in the scientists community, but this is the only thing I found.

http://www.telegraph.co.uk/science/science-news/7896385/Scientists-prove-that-women-are-better-at-multitasking-than-men.html

Women do multitask better than man. So guys, when you are watching a TV and talking to your Wife/Girlfriend, and she complains about your ignorance, she’s got a point. It doesn’t work the other way around thought 😀

As my friend Christian used to say “Less haste, more speed” and Lord Chesterfield “There is time enough for everything in the course of the day, if you do but one thing at once, but there is not time enough in the year, if you will do two things at a time.”

Don’t multitask, stay focus !

Cheerios, Greg

Handovers, hangovers

Handover like a pro

 

Recently I started to read a book, the one that Christian was praising so many times. I’m just through the first few chapters but already one of the sentences sounds in my head all the time. John Seddon, in “Freedom from Command and Control” writes how there was an improvement made to a process in one of the call centres. He said that “all the information was filed in the form so it was never coming back from the downstream person with the request for missing information”. This one off step was making improvement as it was never coming back.

John explained that it was possible to realise the impact once someone took a step back a took a look at the system and the flow through it as a whole.

 

This made me think about something that my other colleague, Pat did at work. When he was rolling off the project, he WIKIed all the information about it and left the Spike (proof of concept) code in the repository. He also made some comments in a code, whenever it was not entirely clear of its intention. It was one of the best handovers with no direct contact I was ever involved in.

I realised that the handovers should be looked at from a different perspective.

Typical approach is to … drop whatever at someone and let him finish the work. Whenever more information is necessary, it could be chased.

Instead, I should prepare handover in a way that would make it possible for a person who will pick up the work after, to have a brief look (at the code in my case), realise where the info is (wiki, tests, some comments) and move on with the flow.

Funny enough it encourages some good coding and work practices, like:

Handovers are a problem and should be avoided when possible. When programming is involved, Pairing reduces the danger of the need for them. If not, all the members should concentrate on the most important thing, make sure the work keeps flowing through the system and what could I do to make it happen.

Cheers, Greg

Agile multitasking, context switching

These days, computers made multitasking a doodle. In the same minute you can read this blog post, chat with friend on IM, check your email, Facebook or Twitter account, perhaps even do some work. We can switch our attention quickly from one task to another. But … is it good for our brain? Is it good for the work we are doing? Are we really more productive?

It’s been few weeks since I started to talk to people about context switching and multitasking. Most of them recognize it as an issue. Many agree that it is counter-productive. I decided to take closer look at the problem and do a little research. Here are the results.

Human brain

According to many Neurologists and Psychologists our brain was not designed for multitasking. In 1999, Jordan Grafman used MRI to scan people brain. He discovered that frontal cortex of brain of people engaged in multitasking was more active than any other. This part of the brain is the least known to science, it is said that this is “what makes us human”.

Psychologist René Marois discovered that there is a bottleneck in the brain, when it’s being stimulated to perform more than one task. David Mayer thinks, that rather than a bottleneck, brain has a process that helps to select and prioritise tasks and obey any instructions that are not on that list.

Russel Poldrack, a psychology professor found that “multitasking affects the way you learn”. He discovered that people who multitask while learning, use the part of the brain responsible for learning new skills (striatum). Rather, they should be using part of the brain responsible for storing and recalling information (hippocampus).

There is a dozens more of scientists that have done research in brain and psychology area that will confirm the fact, that we work better if we focus on a single item.

I like the words of American novelist Walter Kirn who summarises multitasking phenomena:

This is the great irony of multitasking–that its overall goal, getting more done in less time, turns out to be chimerical. In reality, multitasking slows our thinking. It forces us to chop competing tasks into pieces, set them in different piles, then hunt for the pile we are interested in, pick up its pieces, review the rules for putting the pieces back together, and then attempt to do so, often quite awkwardly.

 

Multitasking or context switching

It is easiest for me to talk about multitasking or the process of switching tasks (context) when talking about software development. During our development process quite often we are getting in the state which is defined by Mihály Csíkszentmihályi as the Flow . If we are getting interrupted or interrupting others it’s the Flow that suffer.

Receiving end of the stick

Think of the number of times that email, phone, IM chat, news ticker or anything else that interrupted your work. Very often we drop whatever we are doing and we answer an email. We are voluntarily destroying our context, switching to another one, just to get it back on track minutes later. This comes for a cost. It cost time and your focus. It is a typical distracter that actually we have control of.

We can also get interrupted by other people. Project manager, team leader etc. comes to us asking to stop working on whatever we are doing and do something else instead. Something small and quick, that is only going to take you 5 minutes. So we do that, and then we consume our mental energy on getting the entire context of interrupted task back on track.

As a developer I always work in the teams. My fellow developers always have some questions, problems that they might need a help with. I can’t tell them to buzz-off. I will be helpful and pay the cost of interruption later 🙂

The trouble maker

When we are in a despair and need answers we are not worrying about anyone else. The goal is to ask or tell to achieve whatever we are after. We are not taking into consideration that we might be disturbing someone else Flow.

It is the same when we aren’t using contact in person but electronic medium, like email, telephone or IM chat.

Too many things at the time

Almost 10 years ago, Joel Spolsky wrote on his blog:

As it turns out, if you give somebody two things to work on, you should be grateful if they "starve" one task and only work on one, because they’re going to get more stuff done and finish the average task sooner. In fact, the real lesson from all this is that you should never let people work on more than one thing at once. Make sure they know what it is. Good managers see their responsibility as removing obstacles so that people can focus on one thing and really get it done.

Getting tasks under control

When I started my short research on multitasking it became more and more obvious to me how Agile, Lean and XP methodologies are actually trying to bring the software development process to the state where individuals are focused on single task, complete it in full and move on to the next one. With no interruptions comes better quality as well. I would like to mention and shortly describe some of the techniques that could help team members to achieve the Flow and Focus and produce results.

Pair programming

You might think that having other person next to you means a constant interruptions, and impossibility finishing anything. Nothing more wrong. The positives that are coming from pair programming in the context of help with multitasking issue:

  • having another person next to you and focusing on a work, limits you to NOT respond to email, chat invitations and cutting short phone conversations or generally do anything else not related to work
  • engaged in a work you need to keep constant focus, follow your colleague and check (improve) the quality of result
  • when you think you stuck on something, you have a mate next to you that can give you a helping hand (that limits the interruptions to others as well). Also with switching and rotating pairs you have constantly a fresh source of knowledge on the project areas you have never worked on
  • it might be harder for someone to come over to you and ask about anything or ask to switch task to do something, as it is more obvious that he/she will be interrupting

There is more positives coming from pair programming but I will not write about it as it is a story for separate article.

Pomodoro technique

I was writing about the Pomodoro Technique in one of my previous posts “How can Pomodore help you shave a Yak?” Technique used will help with:

  • keeping focus on a task for period of time
  • adding short breaks to refresh the brain and take a step back to look at the task from a perspective
  • when interrupted by other person or own thoughts, wri
    ting the interruptions on a piece of paper makes you assure that the issues won’t be forgotten and ease your thoughts of it. This in turn helps you concentrate back on a task
  • if you make people aware that, while you are in pomodoro you would rather be uninterrupted, you will be more effective

For more info on Pomodoro, you can look at my previous post or visit Google 🙂

Kanban

It could potentially take few more posts to describe Kanban. As simple concept as it is, it actually creates a wide range of improvements to development process. It is a great tool to be introduced by Project Managers for use by the entire team. Few upsides:

  • working on a single item makes you focusing on a single task. The single story/task/functionality flow
  • creating only quality results means that the actual task is not finished until QAs and BAs are happy with the result. This means that testing needs to come early into the process, even better – during the process (read this article by Christian Blunden, it will show you how)
  • testing brought earlier, means also that you can help testers creating automated tests and keep in the same context until it is finished

Finally

It is in the basis of Agile techniques that work should be divided into small deliverable chunks (stories) that can be picked up and work on. If the chunks are small and team is disciplined, everyone will work uninterrupted until quality result is delivered. Project managers can employ techniques that help team members focusing on a single task and deliver it in full. I’m sure those techniques can save us many frustrating moments 🙂

This article is only a short introduction and brief summary of my little research project. I’m also preparing the talk and presentation with much wider explanation of the concepts and techniques mentioned in here.

Greg

Some of the sources if you would like to research more:

A same cup of Java …

… at IKEA.

 

Recently I changed the job. After three years (longest I ever worked for a single company) I left ThoughtWorks. Majority of my consultant career oscillated in .NET space. It was almost three years since last I was doing Java. New job … is Java (packed full of Java technologies).

I had to do some IKEA shopping one late afternoon after work (something for the house). As my journey turned out to be a waste of time (items out of stock) I was sitting in front of the IKEA building consuming a horrible £1.40 Hot Dog Menu 2. Watching the sun set I had a little epiphany! I started new job, I got dropped into source code and I was able to work without relearning Java, libraries and tools.

Then I realised that through three years of work at TW, C# and .NET changed it’s shape a lot. In a mean time Java did nothing,well … almost nothing. C# introduced new language syntax, features, influenced by dynamic and functional languages. Java had got annotations and generics (somehow weird generics).

Is that a bed thing? It gives stable platform, and more consistent syntax in legacy code. On the other hand it lacks cool features, and I do have to admit, I like new features. It’s like every time when Apple releases new iPhone instead of all cool new things on it all you get is better performance and stability 🙂

There is also the explosion of languages that run on JVM. I like Groovy and JRuby, I need to check out Clojure and Scala.

There was a lot of fear when Oracle purchased Sun. Next new release of Java will have closures. If it is caused by Oracle’s influence I hope for more to come.

It is about time for Java to make some tuff decisions and stop being 100% backwards compatible.

What you think? Comment me your thoughts.

Cheers, Greg

Flex your Agile backbone

Today I would like to write a few words about the recurring theme I observed at work. I call it a “Stiff AGILE backbone”.

With some  of the practices and processes, learned over time, we tend to stop thinking and ask questions if they are appropriate in the situation and if they work. Our agile backbone is kind of a stiff and we are keeping the same position all the time.

It is important to REMEMBER that we need to keep an open eye into what we are doing, what are others doing, identify things that we could do better and execute the improvement.

It doesn’t make sense to keep the same posture only because it worked few times before and it will work again. Every project is different and every project should evolve into “perfection”.

“No change is bad” Toyota President Katsuaki Watanabe

Cheers,  Greg

How can Pomodore help you shave a Yak?

Two terms in the title that needs clarification.  Pomodoro is a technique for managing a task completion, or simply time. Yak shaving is a situation that everyone finds himself every now and than when we are trying to solve a problem in a wrong way. Usually it happens when we create a chain of tasks that will lead to a solution and we keep on repeating it until we get somewhere. Eventually we could end up with a very crazy solution after a long period of time.

Yak shaving

An example of Yak shaving I found myself in not too long ago.

I found myself doing a Ruby on Rails development on a Mac box. As I used older version of MacOS I had an older version of Ruby compiler. To use latest version of Rails I had to get newer version of Ruby. To get that I needed to install that via Mac Ports or something similar. While trying to install Mac Ports I found myself missing some of the development files that stopped Mac Ports from installation. It turned out that those files where in XCode. I had to find XCode that is going to work on my machine. Turned out that older version is available on Apple Dev website, all I need is to sign-in. I had an account, but forgot the password. Then I tried to retrieve a password and that didn’t work. After some battles I finally got a XCode on my box.  It was still Mac Ports impossible to install Mac Ports thought. That took me along time. Eventually I ended up installing VM image of Ubuntu and developing on Linux VM.

I think that being developer, the Yak Shaving problem is very irritating and could lead into a lot of wasted hours. When working in a pair,  the Yak issue will not appear that often. There is always a second pair of eyes to validate the sanity of the task in progress. It doesn’t eliminate the Yak entirely as I found out with some peers 🙂

When working alone that is entirely different story. Because there is no one to run you ideas by, sometime I make a decisions that lead me into “the shaving“. I found myself wasting hours before realizing that it doesn’t make sense and taking step back.

Pomodoro, mmm, delicious

Not to long ago on a project I was working on, we used Pomodoro to keep us focus for a period of time. This simple technique combines 25 minutes of un-distractable time of work and a 5 minutes break. After 4 successful Pomodoros (25 minutes + 5 minutes break) we had a little longer break. While working in a pairs, Pomodoro was keeping us focus and safe from emails, phone calls and coffee breaks. The 5 minutes break gave us a lot of time to discuss the issues around the task/problem.

When working alone the 5 minutes break could be the excellent opportunity to talk with someone else about the problem or just take a step back and reflect on a solution. This eventually could lead into new ideas and most importantly into STOP shaving a Yak.

There is more to Pomodoro technique than just a sanity check from a yak shaving. There is a free PDF book that can be downloaded for free http://www.pomodorotechnique.com/resources/cirillo/ThePomodoroTechnique_v1-3.pdf and some other resources on the Pomodoro Technique web site.

Cheers, Gregster