Go see your managers day

A follow up thought on my previous post on to show some empathy and put yourself in management shoes, to understand what she really cares about and what’s important for her.

A bold and probably a very insightful way of understanding your manager and how to speak with her, is to apply Genba – Go See principle – the other way around. Go See where the action is. Ask your manager if you can come for a ”study visit” 1 or 2 days, to follow her for 2 days as an apprentice just to understand what she’s facing every day and to understand business better.

Not that hard really?

If someone asks you if they can follow you for 1-2 days to learn about your way of working, your delighters and problems, with the purpose of being able to help you in a better way, would you be happy for that question? I would for sure. And I think your manager would too.

The effect I’ve already seen many times – The Go See principle is powerful whenever applied.

Go See your mangers day

Tests aren’t about testing – Scandev 2012

At Scandinavian Developers Conference April 2012 there were some rememberable messages about testing – what I heard tests aren’t anymore about testing, if it’s ever has been.

Kevlin Henney @KevlinHenney first mentioned the message on testing in his keynote which was really about architecture and good coding – such as economy, visibility, spacing, symmetry and emergence.

About testing he said,  the point of automated tests is NOT how many tests you have,  it is in the meaning of them. To explicitily state rules, to know exactly what we mean in a row of code – that’s the point of testing

Tests turns belief into knowledge.

Gojko Adzic, @gojkoadzic, test and requirement change agent, told us the story of a French team that threw away their automated tests as soon as they’ve passed.  They used automated tests as a

shared understanding of what to do very effectevily

rather than a tool for testing.

He busted a lot about myths of BDD (Behaviour Driven Development) and the challenges on understanding of it from business. He called it

Businessting – the belief business users could write acceptance tests

I’m happy he brought this challenge up. I’ve seen so many teams waiting for business to suddenly show up with very clear, ready to automate, covering test specifications at exactly the right level. Gojko reminded us of the importance of conversation with business people on the rules, on the examples, on the code that’s gonna be written.

The main benefit of Behaviour Driven Development is that is supporting us longterm with information on what the system does – therefore you don’t always need to keep them tightly integrated to the code when they have passed once (!)

We’re obsessed with wrong details.

Jeff Patton,  reminded us also of conversation with business, and of the thing many of us seem to have forgotten about user stories.

User stories, no matter in what written template, was in the beginning there for the purpose of making business people telling stories! Stories about what’s happening in the business, and what could be happening in the future. Now many asks about how to write correct user stories, rather than asking their business person to tell.. their story.

So whatever we do we need to find ways to include business people in our daily conversations 

This seems to be the greatest challenge when it comes to Agile.

Mary Poppendieck, always insightful, brought the subject up of the importance of whole product team. She said we need to let go of ”software development” and talk about what we’re actually doing – product (or service) development to get business on our team so we can do great products and services.

If we believe in whole product teams, which I guess we do if we want to deliver good stuff, software development teams need to start to talk about products (and services)

Go from programming language to design language.

Why estimation by email is a bad idea

It seems like the most common way to communicate between customer (for example a Marketing department) and supplier (for example a development company or a webb design company) is by email.

Email seems to be the most common way to ask for an offer or an estimate.

By working both on the customer and the developer side I very clearly have seen during 15 years of web and IT development projects, that making estimates through email communication is a very bad idea and a big WASTE. Why?

• Reading and make a correct interpretation of email descriptions of a design idea someone else has written, is extremely hard
• Email is very close to one-way communication. The ones reading your email are scratching their heads trying to figure out what you mean. To pick up the phone is very uncommon these days. The readers (suppliers) will try to collect all their questions in one email, in stead of 20 small ones – by the time for writing the email back, they’ll have forgotten half of the questions or think it’s to small to write in an email.
• Email is very close to one-way communication. The readers (suppliers) cannot share their own ideas of better solution or their questions
• Email communication takes TOO MUCH time for all people involved. The lead time from the customers idea to a fair estimate can be weeks. Bring the customer and supplier together for 1 hour (or video conference if the distance is too far), and you will have a fair estimate that same hour.
• When you finally reach some estimate by email communication after 1 week or more, there will be so much misunderstandings so when the service or functionality is developed there will be endless discussions about the estimate and  – who said what, who had the right intepretation. When you talk about design issues face to face there is at least a fair chance of common understanding.
• Email communcation wastes the creative minds of both the customer (writer) and the (supplier) reader. You’re not taking advantage of the creative nature of face to face communication where you can share ideas, draw, explain impediments, constraints, the purpose and develop the idea to a better and in the long run much cheaper one, by making a better solution for both you and your customer.

Please STOP this! And you will come much quicker to time to market – and have much more accurate estimates.

It’s very easy. By going for 1 hour travel time to meet your supplier to have a 1 hour conversation about some idea, you will for sure save many many hours in later discussions (by probably writing angry emails). And if they like you, you might be brave enough to ask them for a desk to borrow the rest of the day with your laptop so you don’t have to travel back that day.

Try this @ home and @ your supplier and you will both win the estimation game.

Going English

I love Swedish, everything is so much easier to say in your mother language. And it’s very interesting all this with off-shoring – a bunch of Swedish IT people speaking ”Swenglish” and a bunch of Indian IT guys speaking some sort of Hindi English, trying to understand each other with loads of  prejudices on top of that.

Well, I believe we can overcome this and soon enough start to work globally together for real – teamwork, joint ventures, learning, innovating, creating with the good parts from our different cultures, languages and way of work. Of course with some stumbles and falls on the way.

That’s why this blog is going English. I hope to be part of making the communication gaps out there smaller – between business and IT, between requirement people and developers, between western & eastern people, hopefully with the result of more beautiful and useful systems. Communication, systems and learning is my main passion.

Another reason is to practice my English, if I one day would get an offer to go abroad.  As you’d probably already can see – if your not Swedish or from India.. my English grammatics and vocabulary needs a lot of that!

Thank you for keep following me.