Archive

Learning

If you ever worked with me you would know I’m not a big fan of estimates, mostly for the reasons better explained here, here and here, but there are still moments within a project where there are a bunch of stories written and teams need to have a guess on how much time will be needed

  • the project might be beginning and we need to know what is realistic or not
  • there might be go to market activities that need to be synchronised in advance
  • there might be a fixed deadline and we need to understand if there is any chance of making it or not

In cases like these, I’m still not a big fan of using planning poker or similar practices. First of all, it takes a _lot_ of time. Whoever has experienced a long session of estimation can probably remember people rolling their eyes as soon as we get to card number 54 (or around that…).

And handling the short attention span of tech people (which could probably be increased for the better) is not the only problem here. In every project there will be a lot of similar cards, and reestimating similar things over and over is probably not the most productive thing a software team could be doing, and also tests the patience of anyone involved.

Instead, what I’ve used in the past is a simple technique for group estimation (that I’m sure I saw somewhere before, so don’t credit it me for it) that will allow a group to get to some numbers with less time and effort.

1. Write all the stories you have in cards, and put them on top of a table.

2. Create 3 separate areas within the table, based on different timeframes. What I normally use is 1-5 days, 1-2 weeks and “too big”.

3. Ask the team to go over the stories and position in the categories they find appropriate. Let individual people move (and move again) cards however they want for a few minutes.

4. Let everyone go through the table and look at the cards, and observe the ones that are being moved between categories frequently.

5. Get the unstable cards and the ones in the “too big” category and discuss them within the team. Rewrite cards as appropriate.

6. Rinse and repeat if needed.

Is it precise? Probably not that much. Are any estimates precise? Definitely not. So far every time I’ve used we got a good level of results that were in the right timescale, which is probably the most you will get from software estimates anyway.

Regarding the fact that every story is not individually discussed within the team, a common argument in favour of detailes estimates, I believe there are better times to do that than when looking at all the cards with no context or experience working on them. Time to establish some story kick-offs maybe?

To close my participation at LAST Conference, I’ve presented a follow up of the talk I’ve done at LESS 2011, talking about why I believe most organisations are not set up for learning.

In the presentation I’ve explained my thoughts on why I believe change programs are often unfair to employees, asking them to embrace change, but only the one that management is putting forward.

I’ve also talked about learning within organisations, product teams, and how management teams should step back and understand their new role as leaders instead of controllers of the company.

If it sounds interesting to you, there is more info here.

Last week I’ve presented with Herry at LAST Conference about our experience of helping forming a new distributed team in Melbourne and Xi’an while transferring the knowledge of an existing product.

It was an interesting challenge since what we had a not so simple task to do, which was to

  • finish a major release of an existing product
  • ramp down the existing team in Sydney
  • create a new team distributed between Melbourne and Xi’an
  • transfer the knowledge as smoothly as possible, so the new team could start delivering new functionalities as soon as possible

It was great to talk about our experience for the first time, and the amount of questions that came from the audience showed us that it is a interesting (and controversial) topic for other people as well.

The slides are available here, unfortunately it’s hard to get all the content just based on them, but just get in touch with us if you have any.

Last Friday I’ve participated in the Lean, Agile & Systems Thinking conference, which was a one day event organised by Craig and Ed  with the intention to be a day with content “from practitioners” and “to practitioners”.

I have told both of them and a bunch of other people, but it won’t hurt to say again that I believe Australia was in need of an event like this, organised by the community and with focus in providing useful content more than anything. Its success was definitely proven by the attendance and also the twittersphere on the day, so if you haven’t congratulated them yet, don’t wait any longer!

I’m going to try to share what Ive heard around the event here, but there are definitely more places to look for, and videos of some sessions should be available soon.

Storytelling by Shawn Callahan

I’ve started the day by going to the double session from Shawn from Anecdote on business storytelling. I’ve been reading on the subject for a while and the session was very interesting.

After proving in a story telling exercise that everyone has a story to tell (and that we start telling them after we hear other people doing it!), shawn spoke about the storytelling spectrum and how we should keep the business stories on what he called the small ‘s’ version, avoiding the risk of telling something so epic that it makes us lose the engagement of our colleagues.

He also spoke about anecdote circles, where people gather to tell stories about the environment they are in, and gave a few examples and tips on how to create questions that will spark stories from people:

  • Never ask why questions
  • Use when and where
  • Make open questions
  • Ask for an example if answer is too narrow
  • Include emotions, as in “when did you feel like … ?”

Some examples of questions:

  • What have you seen lately that has surprised you?
  • When was the last time that something small made a big difference?

He finished the session talking about a story narrative and how you can construct a story, showing video examples of great story tellers and how they used the elements he was talking about.

Overall a great session, definitely recommended if you have the opportunity!

Cynefin Model by Kim Ballestrin

Kim gave an overview of what the Cynefin model is and how she is using that in her current work.

Having had a brief understanding of the model beforehand, it was really useful to see someone talking about it in action, and what it could be used for.

She gave an example of how the model can be used in classifying types of work, and then using the classification to execute them differently. She used three categories for that:

  • Complex Work (with uncertain outcome) – Create experiment and test it the cheapest way possible, to verify if it’s worth being done
  • Complicated Work (where analysis is required)  - Analyze
  • Simple Work (where outcome is certain)  -Build

She spoke about what an experiment actually is in that context and how it could be just a conversation, giving the example of a kids’ party, where parents are constantly assessing risk and acting on weak signals.

Live Below the Line by Claire Pitchford

Claire spoke about her experience as a business analyst in the Live Below the Line project, where they had to deliver a campaign website in six weeks.

She talked in some detail about the inception process that was performed with the client and the whole team during one week, helping everyone get to a shared understanding of the project, and how different tools as personas, storyboards, stories and estimation where used in the process.

It was a very practical talk about what was done, and also quite impressive that she was happy to talk about everything that went wrong, things she tried and didn’t work but also what she learned during it.

As I mentioned before, it was a great day above all. I also have presented on two sessions during the day, and will write about it in separate posts.

It is well known that Agile (not sure about the big/small “A” thing, it always gets me confused) has gone mainstream nowadays. With big companies and conferences endorsing it, long gone were the days when you actually had to convince people this was a good idea… and that’s great!

However, with the early/late majority now adopting Agile, we are not talking about small companies anymore, and that means that the challenge is not how to get teams delivering better, but whole departments and organisations. So yes, scaling agile is one of the current challenges, with the preferred approach being the dreaded (at least by me) “Change Programs”.

I don’t believe agile is a fad or just a small team thing, since empowerment, short feedback loops and delivery of results it’s never going to be a fad and isnt IT specific either. There are many other examples, in different industries (errm… Toyota?) which show that the same principles can be applied successfully in a much larger scale, on complete different problems.

The problem begins though, when by scaling agile, companies try to scale the practices, keeping the control mindset, instead of scaling what’s important, i.e. the principles.

It is common to see companies, for example, adopting a hierarchical structure to create multiple agile teams, all “reporting” to a main office, killing most of what was good about the idea.

If agile in the organisation is the challenge, we need to think about empowerment, short feedback and delivery of real results for the whole company. Unfortunately, the more common behaviour is to talk about bigger walls, how to standardise velocity across teams and synchronisation of iterations.

And if we go back to the roots, and look at the manifesto, I believe we can find a good guidance of what can be done:

Individuals and interactions over processes and tools: Instead of scaling processes and tools to control teams, why not increase the ability of individuals to traverse the organisation, making software developers talk to real customers and sales people talk to qa’s?

Working software over comprehensive documentation: Scale by making a working product the final goal, removing the necessity of internal product briefs, extensive training of sales staff and long delivery cycles.

Customer collaboration over contract negotiation: It is actually impressive how this still makes sense now. We just need to change the customer. It’s not the product owner anymore, it’s _the_ customer, the one who buys your product and pays the bills.

Responding to change over following a plan: Feedback, feedback and feedback. Not from a showcase though, but from the market.

Yes, if it feels like you’ve heard these ideas before, it’s because they are not new. Product teams are the way to scale agile in my opinion. Small and independent groups of people that can get to the best results in short iterations with feedback from the market, in a Lean Startup style. The game shouldn’t be about execution anymore, it is about innovation.

I’ve been thinking about and researching the topic of organisational learning for some time now. Last year, I presented on the topic at LESS 2011, but realized it was time to take some time and write about it. So this is the first post of a series to explore the topic, which I’m also hoping will help me clarify my view on the subject.

Organisational learning. Should anyone care ?

My hope is that this goes without saying, but I guess that the first question to be asked is why should anyone care about learning? Some businesses make money staying still, while the world keeps moving. Full stop.

While this could be true for established business in the past, it’s something that is not so clear anymore. Gary Hamel makes a good point in his “Reinventing the Technology of Human Accomplishment” presentation: Change is changing, and it’s much faster now than it has ever been.

The world is changing, and faster than ever, so (every) company has to adapt, not only once but constantly.

Why is it so hard ?

A company has to learn. If this was an easy task, it wouldn’t be so rare, but creating a learning organisation is one of those things that gets harder the more you try and control it. If you want to form a learning organisation, a few questions you might think of are:

  • What does my company need to learn ?
  • If I had to setup the body of knowledge necessary to run my organisation, what would it be ?

While these could have been easy questions to answer 50 years ago, nowadays, in this ever changing (specially IT) world, whatever you write as being essential today might not be useful at all in one year’s time.

And the big issue is that most companies are not setup to deal with this problem. Instead of an evolving structure, modern organisations still have a very hierarchical structure based on top down control, with the vision of a CEO (put any other senior role here) that drives the strategy while most of the company just follows.

They have Project Management Offices that dictate how to deal with projects, architecture teams that say what can and cannot be done and common policies that dictate behaviour for everyone. Bjarte Bogsnes  has a good tale about how companie’s policies try to establish control over the employees:

“A friend of mine works at SAS. Even if he is trusted to fly planes around the world, if he wants to change his shirt more often than what the policy states, he needs a written authorization”

So the common alternative to evolution in this kind of structure are the well known “Change Programs”. They try to implement a top-down approach to change, that can be explained in two simple steps:

  1. Senior people decide how to move forward
  2. They teach the rest of the company how to do it

While step 1 is always a success, step 2 is usually more troublesome that people would like to think. And it’s not hard to understand why, since the whole idea of a change program is quite an unfair proposition to the affected employees, which could be described like this:

“You have to embrace change, but only the change we want”

As expected, people resist. Peter Senge has a quote that explains this situation quite well – “People don’t resist change, they resist being changed” – It’s natural that most employees will doubt and resist something that they haven’t been asked about. I would, and I’m quite confident that most people would too.

And as a result, money is spent, time and most importantly people are consumed through the process, and not much is learned in the end.

So is there an alternative to this situation ? Do you agree with this view ? Let me know what you think

One of the challenges I’ve had to face a few times in my career was how to ramp-up a software development team, specially in what relates to knowledge sharing.

Why is it hard?

I still remember watching an old presentation from Dan North where he kept hiting on the same point, which was that there is always a story behind any decision made on a project. And that is the main problem I see when joining a new team: there is always story, and you probably don’t know it.

Working in a new codebase for me feels much like moving to a house in a new neighborhood. It takes some time until you know where all the shops are, what’s the best way to get anywhere and where can you buy stuff in the middle of the night. In a software project you don’t know exactly where things are in the codebase, it takes time to understand the rationale behind the design and you are afraid of making big changes, even when they should be made!

So when ramping up a team with a considerable amount of new developers, there is a risk they won’t be able to be effective for quite some time, or that in the urge to be effective they will end up changing what doesn’t need to be changed, being counter productive after all.

So here we go again

This challenge came up again in my last project, where we were starting to work in our second release and wanted to include a team of developers in China in what would turn into our new distributed team.

Gladly enough we were able to spend 2 weeks together as a colocated team in Xi’an, but still we needed to use this 10 working days to ramp up 5 new developers who had little or no experience in the codebase we had been working on.

This time we decided to try something out of the ordinary with some inspiration coming from my period at Thoughtworks University  (what Sumeet would call workscaping), in what could be described as a mixed of promiscuous pairing and very frequent showcases.

What does that mean ?

The idea was:

  • We rotate pairs every 2 hours
  • After each 2 hour block the team would stop and every pair would do a 5 min presentation on what they had done
  • We have a 30 min slot available at the end of the day for having a more in-depth discussion about topics that the new developers had doubts about.

Some of the benefits we expected to achieve were:

  • Everyone would work together quite a few times, improving the relationship between team members
  • The new developers would have an opportunity to touch different parts of the codebase quite soon, hearing the stories from the old ones about what was there and why
  • By presenting it back to the team, everyone would have a chance to raise questions and understand a little bit more about a specific topic
  • The constant sharing of information would enable newcomers to get more questions answered and deliver functionality quicker, which always helps with confidence

So the day would start with a normal standup, and after 2 hours the team would swarm and go around the room, hearing what had been happening. Pairs would then rotate and start again. Repeat that 4 times and the day is over.

How did it go ?

Overall the result was quite good in my opinion. Most of the results we expected to obtain actually happened, specially the communication within the team, which was great after a few days.

After one week of doing it most people started feeling the need of working more hours without interruption, so we changed our pace to 2 rounds of 4 hours and then eventually rotating pairs once a day, where we ended up stabilizing. Despite being earlier than expected, it felt like a natural point where people had enough knowledge to deliver and wanted to focus on that, which can probably be considered as a success.

Follow

Get every new post delivered to your Inbox.

Join 836 other followers