Purpose of a manager

Recently (better late than never) I started wondering what actually is role of a manager. As usual when faced with management-related question I browsed through Manager Tools website. In the forums I found a couple of answers that made more or less sense. However, I stumbled upon one that sounds really good - "As a manager, you do what makes your group and your boss look awesome." Cheers!

Process and value, action and cause

Almost three years ago at Agile Forums I've read the following sentence:

If you separate a process from the values it is intended to express it no longer has any value.

Time and time again this short sentence, that simply boils down to "don't do anything until you understand why you do that", proves to be important. Whether it's software development or repainting the apartment, I constantly see that the less I understand why should I do a certain thing the more rarely I benefit from doing that.

Role of a QA-person in an Agile team

It's been a long time since I wrote anything on my blog. AgileTuning keeps me busy - but that's good, isn't it? I decided to finally shut down my own instance of Wordpress and to start using blogger.com

From some time I've been thinking about recoridng a podcast on role of a QA person in an Agile team. Is this about automating tests, facilitating retrospectives, defining acceptance criteria? Maybe a little bit of both?

A few days ago I had a very interesting discussion about that. On the one hand everyone is responsible for quality in the team - developers write unit tests, a Scrum Master or a Project Manager facilitates retrospectives and Customers writes acceptance tests... And everyone is really motivated to do their best!

On the other hand there's this thing called... reality. Unit tests don't cover everything and customers don't have enough time, or tech skills, to play with test automation tools. When deadlines are approaching PMs don't waste teams' time on chit-chat. And this is when we need a QA who's more than just a tester. A QA that will either work out acceptance criteria with the customer, or won't be afraid of saying "stop" and will have enough understanding of business to convince management to this decision.

Many years ago I heard Tadeusz Golonka saying that in order to successfully share responsibilities in a project one must not combine any of the following roles: technical leadership, customer representation and quality assurance (I hope I remember the first 2 correctly, anyway - I'm sure of the third). Quite much has changed in the IT since than but it sounds like this rule still holds true.