Gå till innehåll

Kategori: Book review

Publicerat den

Recommended by a good friend and excellent Enterprise Architect and thinker Peter Tallungs - I bought the book It´s your ship by M Abrashoff. I started reading it last night and could not stop. I finished at 2 a.m. enlightened and inspired. This is a story about a captain turning a mediocre crew into the best of the best of the best.. you get the picture.

It is a really great book on leadership. Starting out with an abused and disillusioned crew that just wanted to do the minimum of effort ending up with an inspired team of people that felt that they were doing it for themselves.

That it is really what is all about, doing things beacause they WANT to do them instead of doing things because you are told to do them. In the worst case somebody that has no clue tries to micro-manage you.

So What Was Abrashoff's Method?

  • First of all respect the people your are leading, show them that you care for them and trust them 
  • At the same time set clear rules
  • Clearly communicate what you expect from them.
  • Allow failures and then coach them to do better next time
  • Realise that the people actually doing the work are the ones that can make a difference.

By respecting people and treating them well and at the same time telling them that you expect them to perform well. Everybody wants to do a good job - if you let them!

If you really want to be a great leader - you need to read this book and reflect on how your own leadership can improve.

As for LEAN. This is right along the lines of the Lean Leadership book i just  finished reading. Respect the people!

I really despise people that do not respect others. A healthy argument can be wonderful for the spirit but when you stop respecting you peers as well as your adversaries you are in deep trouble. If you get in the situation when you realise abuse and disrespect is the case - leave, for your own good!

Publicerat den

A friend of mine is a software developer. He is of the passionate kind that really cares about the code he writes. I have the utmost respect for him. When he talks about coding, I listen. We had lunch the other day and he mentioned the book Clean Code by Uncle Bob Martin. In his opinion this should be mandatory reading for all developers. Since I am always hungry for valuable learning I ordered the book. I spent the last two days reading it. OK, I admit, I am not a developer and I have not written a lot of code but none the less I found it interesting.

Clean code is about how to be a professional developer. You can be great at coding stuff but it is different to be professional. The difference is that you do not only solve a problem but you solve with code that it easy to read for others which means maintainable. Interesting idea that comments should be avoided most of the time. The code should be so clear that it tells you what it does when you read through it. Good naming, simple functions, no duplication, indentations, clean unit tests as well. If you do not follow these practices your code will be a mess. Hard to read, lots of bugs, hard to update. In this view all automated tests is programming as well!

This leads me to the following conclusions: many people write code but few do it professionally. If you want to be a professional programmer – you have to practice hard and really want to become one. Constantly refactoring and writing tests takes a lot of effort, if you give up - the code will deteriorate fast. Automating testing is really an integrated part of development. Contrary to some popular belief, I don’t think you can just take any tester and assign them the task of automating the manual tests they are doing today, neither is it a good idea to ask them to write the unit tests. This is really writing code as well, and writing code professionally requires you to really want to write good code.

I work with a couple of really skilled developers at the moment. They know the technical stuff, they care about their code. When they tell us that they will not deliver new functions this week because they need to refactor and fix a lot of small bugs, we tester applaude! However I notice a lot that most developers have a hard time seeing the whole picture. They are very focused on solving the problems at hand and do it well technically. A nice user interface and the ability of seeing the whole picture is much lower priority than creating working code. Now I respect that, and they respect that we testers find a lot of bugs that they do not notice. I think it would be a really poor choice to make tester code and developers test more. The strength of our team is that we are good at different things. I really think the idea of everyone being able to do everything is a misunderstanding. I think it is very beneficial if developers can handle different types of coding and that testers can handle different types of testing. But that is not the same thing as everyone beeing a developer.

Both developers and testers need to become more professional. If I was a developer I would read Clean Code and do all the exercises and I would give a copy of that book to all my colleagues. Now I am a tester so I read the book to understand what developers go through. I also hand out copies of my own book on test design to members of my projects so they can understand testing better. I read about Lean, Kanban and Scrum so I understand what is happening in the agile world of today. I am really surprised and disappointed that most project managers don’t seem to care about that new stuff called Scrum when they are supposed to manage a Scrum project on some level. I learn about Effect mapping so I can help making the users happy.

Professional developers are the core of all software projects, but so are the testers. Without one or the other we will fail. Those who believe that all testing can be automated have totally missed the point, those who believe that automating testing is a waste of time have also missed the point. Both are needed but they have a very different focus. Manual testing can never make the code clean – only developers can do that using other techniques. Good manual testing will give invaluable information in order to make the application useful – help the user solve their problem!

And yes, I am really looking forward to our upcoming conferences this spring. SWET peer conference in March and Let’s test in May. The latter one open for the public. Let is discuss and bring software development one step further ahead towards real professionalism!

Publicerat den

The Sticky Minds website is now featuring a review of my book Essential Software Test Design The reviewer finds the content great but the many proofing mistakes bothering. Funny thing since I paid a fortune to an English speaking translator who then proceeded to make both spelling and grammar mistakes. The whole book project is a tale of how to NOT publish a book. No direct communication with whoever did the work, everything went through the publisher. In the end, she just vanished and after receiving my last payments she failed to pay the guys she hired to do the job. Luckily the version on Amazon is a print-on-demand version that has many - but not all spelling mistakes corrected. If I ever write a book again I will be sure to have a professional editor handling it.

There are not that many good books on test design out there, most testing litterature is about process and documentation. I use Lessons Learned in SW Testing (Kaner, Bach, Pettichord) as a way to get inspiration and new ideas, How to Break Software (Whittaker) has helped me a lot understanding the root causes of failures and I use the techniques daily. Test design for the practitioner(Copeland) inspired me to add some content to the final version of my book - I read it the first time when I was almost done with the first draft of the original Swedish version of my book and I thought - wow here is almost the same book I am writing! My recommendation to the professional test designer is - read all of these as well!

Publicerat den

The art of giving and receiving feedback. Another brilliant book by Gerald Weinberg.

As with all of the Weinberg books I have read so far the book is both fun and interesting. It discusses many myths regarding feedback and opens the eyes of the reader. It talks about both giving and receiving feedback which are closely connected. The main lessons learned for me is

- Timing: Give feedback when a situation arises, not a week or a year after.

- Shutting up: Do I really NEED to give feedback right now is this situation? Do I think the person will appreciate it or even listen? Or do I just believe that I have such important information that it is worth risking a relationsship telling it?

- Walking in their shoes: What if I was in their situation, how would I have acted? Maybe my understanding of a situation is totally wrong? Think about the reciever before opening your mouth!

- There is a big difference between observation and interpretation. Feedback can contain both parts but observation is often more useful and appreciated.

- Be specific and clear: if you wrap it up, it will likely be misunderstood.

- We can all get better by practicing! And that is very important for our personal and professional life

In my current It-project I realise that half of my work is about communicating with other people and feeback is a central part of that.

Read it!

The book can be bought new from Bingham House Books <binghamhousebooks@comcast.net>

Publicerat den

First of all I want to show a photo of the teachers we have. Johanna Rothman to the left, Jerry Weinberg in the middle and Esther Derby with grey hair to the right. It is interesting to study the interactions of the teachers and wonder aout how many of the events are carefully planned and how many are intuitional. It is at the same time a relaxed environment filled with lots of demanding tasks. I am discussing a lot of agile principles with the specialists here and enjoy every hour so far.

How can I possibly write down all the new insights I have gotten so far? Yesterday we did a lot of team exercises and this morning started with the full group analysing ur behaviour. We noted down the five most omportant actions we had done they previous day to act as leaders. Then we were told to explain why we had done a certain thing and our cards were placed in a big matrix taped to the floor. The goal was to show us the MOIJ model. The letters standing for Motivation - what did we do to motivate the team, Organisation and Information. The inexperienced leader focuses on helping motivation by motivatong the team The more experienced leader tries also to organise the team beter or to get more information in order to increase motivation. For example it is possile to get information that if the team solved a particular problem well we would get a lot of points thereby giving the team an extra motivational kick to perform.

MOIJ

The afternoon was spent observing another team while they were performing a task. We had to focus o one thing at a time which was a challenge in itself. This led to interesting obervation regarding group dynamics, non-verbal acting, roles, structure etc. Rewarding and very exhausting. Lessons wre that you can learn a lot by observing facts and telling the observed of the facts. But it hard not to make your own interpreatations at once but wait for a while.

I skipped the vening session tonight which is scheduled to continue until 9.30.  I need to sit down and reflect for a while and of course blog about it.