Yesterday's Meeting at JUG Lodz

This is the slides I presented in the evening.



Some folks also asked me about materials related to conversation patterns and working with business people. This the list with some resources

• My stuff at this blog
• My stuff at InfoQ
• My stuff at Conversation Patterns for Software Professionals
• Bridging Communication Gap, by Gojko Adzic - is about improving communication between customers and development teams; how to create quality software with Agile techniques
• Specification by Example - explains core concepts founded in Bridging Communication Gap in more details
• Non-violent Communication. Language of Life - great book by Marshall Rosenberg about advanced communication skills
• Core Protocols - these are procedures for improving personal communications and team meetings for total nerds :)
• Fearless Change by Linda Rising and materials on her home page

Write, Review, Improve

Currently I am deep in writing the second edition of my book. I asked some professionals for help in early reviewing.

I also plan to involve some tips for those polish folks who work with different cultures - this is a hot topic these days.
Because of limitation of my personal experiences I'd like to collect the experience from volunteers. So if you want to share your tips via my book, please contact me. I consider these cultures:

• German
• Ango-Saxon, American
• Asia: Indian, Chinese, Korean
• Nordic: Denmark, Sweden, Norway
• any other?

Developer and the developer - the final thought

A year or so ago I wrote an entry about core attributes of wanted developers. The conclusion was having said responsibility team leaders had in minds responsibility for a relationship. The core of being responsible for something is responsibility for a relationship between all involved stakeholders. Doing tasks is part of it. But meeting stakeholder needs and increasing business value always comes with taking care of relationship.

So this evening I came to next critical attribute of wanted developer - it is ability to deliver. It's simply stupid - you may think. Well maybe it is - on the knowledge level, but today I've understood what it really is. Closing tasks, delivering pieces of work, moving work forward, getting things done - this is what the developer is expected.

But - Caution! Controversial! - ability to deliver has higher priority than technical quality (even in the form of 'good enough'). It doesn't mean that quality is not important, but being responsible for business goals and relations between all involved stakeholders over being responsible for set of tasks, delivering pieces of software over assuring technical quality.
"That is, while there is value in the items on the right, most folks tends to value the items on the left more". :)

Summing up: Ability to deliver is the thing which must be assured in time, technical quality is the thing which must be constantly improved through time!