9 years in The Bank – lessons learned

I worked at RBS for almost a decade. During my nine years at the bank, I got the opportunity to work with very talented and smart people, and I learned a lot. I want to use this opportunity to summarise some learnings and experiences that I encountered during that time.

Large Organisations are like Big Ships

Large Organisations, like traditional banks, are like big ships, hard to get going, require an enormous amount of energy to move and a long distance to stop. When it finally departs, it’s impossible for it to quickly and swiftly change the direction. The organization is on the constant lookout for problems far into the horizon, to be ready for a direction change maneuver. Finally, if unexpected happens, just like the Titanic, the ship will not be able to avoid the obstacle and will crash into it. Make a mental note as this will impede decisions and choices you’ll have to make.

white cruise ship

Smart people do dumb things – the fallacy of targets

I’ve seen people make irrational decisions, sacrificing Software quality and Customer Experience for the sake of delivering to deadlines. Deadlines quite often self-imposed, making no commercial reason. Those decisions were driven by localized targets, imposed by line managers. Values that the organization pursued, the good of customer was forgotten because the way performance was assessed, was against the targets.
The result was a poor quality software, delivered at a high cost, and at the end had to be scrapped and re-written. Beware of personal targets as those are often in direct opposition to organization vision and objectives.

Smart people do smart things – if you give them some autonomy

I’ve seen and been working in the hugely successful teams. Teams were focused, creative in solving problems and very productive. Motivation was high as well as team satisfaction. What was common for those teams was the autonomy in solving a clearly articulated problem they were given.
When you hire smart people, give them problems to solve, guide them in organization intricacies and help get the resources they need to solve problems but don’t tell them what to do (don’t micromanage).

Shared services for technology don’t work

Creating a team of specialists (for example DataPower developers), co-locating them in one place and offering their skills as services to delivery teams via the ticketing system is a recipe for disaster. Something that makes sense from the accounting point of view doesn’t work for agile teams that are building software. Again, localized targets for Shared Service teams are never aligned with the vision for product teams.

Beware of re-inventing the wheel

I’ve seen the countless amount of open-source frameworks and tools wrapped in a “thin” wrapper, offering the “same” functionality as the original. In reality, central platform teams started with good intention but hardly ever had the time, resources or expertise to deliver the promise. Avoid re-inventing the wheel, instead of wrapping try to integrate and use extension mechanisms.

gray multi spoke wheel leaning on wall

Management and Leadership are two different things

Leaders inspire people to take actions; managers help people to overcome obstacles and deal with distribution of work. It is possible to be a great leader but at the same time a terrible manager, and the other way around as well. During the nine years, I’ve not met a single Great Leader who was a great manager as well. I believe that in a large organization this happens due to a simple lack of time to perform both roles well. Beware of giving Leaders the responsibilities of managers. They might do a mediocre job at both instead of great at one.

Distributed work is hard

Distributing work on a single product creates communication overhead. For example, scaling one team into two teams creates the illusion of doubling productivity. In reality communication, teams synchronization and integration overhead will only yield a fraction of improvement. Introducing new teams, distributed across different location only amplifies the problem reducing improvements further. When scaling for improved productivity, first look into augmenting existing team and fixing all issues in the delivery process to achieve a smooth flow of work.

Working with vendors require much care

Agencies and Consultancies like to deliver software or services on their terms. The typical sales pitch will mention how beneficial it is for the customer and how productive they can be. The only problem is that quite often after the engagement is done, resulting work doesn’t integrate, is build with incompatible or problematic technologies or lacks on quality. When choosing vendors, make sure to have a set of requirements ready, including technologies to use, ways of working (e.g., integrate early and often), engineering practices and quality standards. If you hear questions related to the above list from the vendor, it’s a good sign, but don’t take anything for granted.

Scaling teams to early could backfire

This point is the expansion of the previous mark of Distributing work. If appropriate software architecture, engineering practices, and delivery pipeline are not in place, the resulting product will lack in quality and cohesive solution. Multiple teams will try to isolate itself via designing architecture and solutions that make it possible for them to work in parallel in relative isolation. This time it’s a Convey’s law applicable on the micro level. If you need to move faster, first try to optimize your delivery process before looking into scaling.

Technology is hardly ever a problem

Majority of issues that arise during software development have very little to do with technology and are associated with people relationship and communication problems. Bad communication leads to missed requirements and invalid assumptions. Make sure to validate all the assumptions early and keep revisiting information you gathered. When you have all the requirements, keep on going back to the Product Owner to confirm that what you are building is the right thing. More importantly, if it is still needed.

Finally

Above are just some of the lessons I learned. I will use this knowledge at the new organization I just started work. I think that the above might provoke some thinking for you as well as re-affirm the lessons learned for me.

Scalable Lean and Agile, QCon London 2011

qcon-london Today 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

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.

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

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:

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

Revolution – Evolution of a story wall

Everyone who knows or was close to Agile Software Development knows something about Story Wall. If by any chance you don’t, here goes.

Tell me the Story

Story is software requirement/feature/pice of functionality that is presented in story telling way. For example:
‘Given that I am a new user,
When I arrive at xxx site home page and I click Register button
I will see the registration form so I can register and use the awesome site’

This is just one way of story formating and wording. As many people and teams as there are, wording can take different shape.

For the purpose of the Wall we would normally have stories written on a index card in a bit shorter form with reference to more verbose version. The more verbose version contains acceptance criteria (we are using Mingle most of the time for that purpose).

The Wall

The wall is a physical place where we stick our story cards. Wall is a visual dashboard. It gives every team member current state of an iteration.

Wall is usually split into columns that indicates what is the current state of the story. A wall will usually have columns like:

In Analysis
Ready for Development
In Development
Ready for QA
In QA
Ready for Sign-off
Finished
Blocked (the infamous one)

This is a very typical wall setup. I worked with this shape of wall on many projects I was on. It is quite good, gives all important feedback through entire life cycle of a story.

Story wall

It is very important to point out the fact that story wall maps to a development process. The columns on a wall are direct map to the way we work. As you might already know it is essential to bend and improve the process in order to achieve best results possible.

A very short break through the mentioned story wall. When Story got analyzed it moves into ready for development. Developer picks it up and works on it. When work on it is finished it is ready for being QA. If there are any bugs or hidden “features” it goes back to Development and so on. Once QA is happy with the story it is ready for Sign-Off. In any point in time if something stop story from being Developed/QAed/Analyzed it goes into blocked. Once the story is showcased it officially finished.

In perfect world this sounds good, but … as software development world is one of the most imperfect, it doesn’t. For example, if stories are in development, QAs might have nothing to do. If stories are developed in “high rate” the QA column will pile up. Once story is in QA, devs are picking new story and start their work on it. When bug is discovered on previous one it is raised as bug, or story is moved back to ready for development.

Evolution

In our current project, we have identified some issues and decided to change, improve our way of working from the very beginning. As process changed so did our story wall.

Once all the stories for iteration have been analyzed they are landing in Ready for Development. The team has 6 developers, as we are pairing, we are 3 pairs working on 3 stories at the time. This makes THREE streams of work that could be started at any time. We decided that we will create THREE vertical slots for that THREE pairs. This means that it is impossible to have four stories worked on at any given point in time.

Next, we decided to eliminate QA column. It doesn’t mean that there is no QA, it means that QAs are involved in testing from very beginning. While the story is worked on, every single bit of new functionality is presented to QA to check it out. Developers are getting immediate feedback and very often tips for things that they could miss. In a mean time QAs are testing on their test environment and preparing automated tests.

We have the luxury of heaving one QA per DEV pair. This makes little teams of THREE. When development is finished there is very little for QA to test as it was already done. At the end newly created automated tests are fired up just to confirm that all is done.

As it is a team effort (a DEV pair plus QA) to FINISH the story, DEVS are helping in testing and in development of automated tests when needed. The story goes than into Ready for Sign-Off.

It involved discipline to make sure that only one story is worked on at the time, until entirely finished and being ready for presentation to business sponsor.

The THREE musketeers are responsible for the story to be finished and to improve the process.

Revolution

How did this process change affect our project. Short summary.

We have completed all the required scope for release, in given time (a little ahead of time)
Number of recorded bugs: 1 (fixed few minutes after it was reported)
Team morale, GREAT

We are very happy with this setup. What YOU think about it?

Cheers, Greg and the Team