CSR vs Spam

"Corporate social responsibility (CSR, also called corporate conscience, corporate citizenship or responsible business)[1] is a form of corporate self-regulation integrated into a business model. CSR policy functions as a self-regulatory mechanism whereby a business monitors and ensures its active compliance with the spirit of the law, ethical standards and national or international norms." (https://en.wikipedia.org/wiki/Corporate_social_responsibility)

That's cool, but what about spam? This is a piece of my company official inbox.

There are heaps of that kind of emails. Most of companies sending me a spam have CSR page on their websites. So, what with your social responsibility guys??

Yeap, you will say that I agreed for sending me commercials...C'mon! We all know that agreement paragraphs was low balls - written with 2px font, white letters on the white background or so on. And don't tell me that your forms respect the law. CRS idea is wider than the law.

So, if you want to be socially responsible organization, take care for the spam sending on behalf of you.

Some Tips for a Presenter

I've seen many conferences talks and I've given some as well. I collected couple tips you may find useful.

Get bright clothes

Yep, I known that you will receive black t-shirt from the conferences stuff. From some reasons they think that software developers love black ones :) However, black stuff doesn't look good on cam. So, try the bright one.

Put shirt into pants

Having business casual shirt put it into pants. This kind of shirt is quite long, having it on the pants optically makes you really short. Ok, if you are really tall guy, 1,95m or more, it doesn't matter, but for the rest of speakers it does. And get a belt.

If you really hate putting a shirt into pants, get t-shirt or better polo shirt. That's also looks good.

Empty your pockets

Many times a conference stuff gives you a clip-on mike - this is a small box. Sometimes they give you two mikes - voice related and camera related ones. Speakers put them into front pockets. That looks really bad. Like big, big something on your loins. Watch this if you are a male - your loins are expected to be narrower than your shoulders - that's the style ;)

So put the mikes boxes into your back pockets or clip them on the belt backwards.

Watch on drinking

There are two reasons I do not recommend drinking during the talk. First that is a funny noise of swallowing when you have mike close to your face. And the second one is that from the audience perspective this is takes quite long when you: open the bottle, get it into you mouth, get a sip or two of water and finally put the bottle on the table. That silence "sounds" awkward.

I am sure that breathing coolly with your nose you will stand one-hour talk without drinking.

Ok, let say that drinking is really critical for you. I give you couple tips:

• The most important is timing. The audience is supposed not to wait when you're drinking. So prepare a glass first to avoid opening a bottle. Ask the question and drink when someone starts answering. Or say a joke and drink when people are laughing
• Drink only pure regular water. A juice may tickle a throat and you will start to hack. Sparkling water and beer (God!) are banned. You know belching sounds...blah

Enjoy your speech!

NVC for Agile Developer

Nonviolent Communication (NVC) is an approach developed by Marshall Rosenberg to assist in caring for this chemistry during conversations. From a technical point of view, NVC is a method of conducting dialogues.

However, apart from specific techniques, it advocates a set of assumptions and beliefs that might motivate you to think of NVC as a philosophy of treating another human being – and a philosophy where verbal communication is the exact medium.

Read more at InfoQ: Conversation Patterns for Software Professionals - Part 5

Scrum, Kanban, XP, Scrumban, SAFe, Nexus, LeSS, DAD, Evo

There were days in the Java world when we were framework enthusiasts. Every single day new framework was deployed to sourceforge, googlecode, github, bitbucket or so on.

So it was turned out that being a Framework-Junkie led you to really poor architecture (see these articles: * Driven * do not change anything, Extremely Pragmatic Software Architecture, Measuring Software Architecture, Frame-of-our-work, What Exactly Are Patterns?).

Having this technological discussion out of our heads we started new one: what is the best agile framework. Yep, we are quite poor learners. How it possible that people who are trained to see repeatable patterns in the world don't see that we replay the old movie? - searching for the Silver Bullet.

Teams or whole organizations jump from one agile framework to another one - in the same way they jumped from Struts2 to JSF, from JSF to Spring MVC, etc. But they don't achieve desired effects.

If you wonder how to jump from SAFe to LeSS or another, or maybe you wonder which agile framework to use - I know the answer. Are you ready? - IT DOES NOT MATTER.

That's right - an agile framework doesn't do the job - PEOPLE DO. Don't try to bypass teams members skills by a new framework. This is a cognitive bias I described here.

Any framework was developed by highly-skilled professionals as a generalization of their daily routine. Having highly skilled people you will apply any framework, but a framework won't make your people better.

Again, frameworks are useful, but people and their skills are the key success factor.

SoftwareTalks in Gdansk

For those of you who attended in SoftwareTalks in Gdansk.

Hi gyus, I've just spend the evening with some of you and received feedback after my talk.

The most important thing: you might come to conclusion that you won't learn anything new after your thirties.

I am really sorry for that impression, so let me explain something.

I quoted Manfred Spitzer and his book Jak się uczy mózg? where he claims that our intellectual development is the most dynamic before one's thirties, but social development is the most dynamic after one's thirties and takes quite long time.

That was my foux pas that left you with the mentioned impression without any context or explanation. Sorry again. I hope you will reframe this.

Lesson learned from ABE 2015

I gathered a killer idea from a ABE 2015 lecture. Ready??

So, the one is that listening carefully to an user voice you will come to conclusion that the thing which really matters are non-functional requirements.

Functional requirements are just only effects of decomposition, clarification and specification non functional reqs.

That's all for now. Need to think more about this concept :)

Conversation Patterns for Software Professionals - Part 4

The first three parts of the Conversation Patterns for Software Professionals series were devoted to exploring business needs. There, we presented techniques which are helpful in defining and clarifying the real business needs that are hidden behind the expected functionalities and user stories.

The current part is about asking questions that hit the nail on the head...

Continue reading with InfoQ.

A Word on Motivation

Don't blame people, avoid punishing them, empower people, let them to Drive themselves, motivate people positively. Have you heard about this stuff? I have a lot. Basically I agree, but...

A friend told me a story. His is the owner of some organization from the IT industry. Once the organization cooperated with dishonest supplier who hadn't paid the VAT tax related to their businesses for couple years. (in Poland VAT tax is the way how the sate sicks up the poorest subjects, but it's another story).

During the tax control they obviously discovered the trick an punished the supplier. As a consequence of the case weak invoices were mandated to be removed from the accounting system. Technically there was no business between my friend and the supplier. But my friend deducted VAT tax, so Tax Office request him to refund it. Two million Polish zloty (it's over $500k) in 14 days...well, this is the law.

But he survived, found the win-win solution with Tax Office. Was he motivated positively? I don't think so.

When I think about my business carrier (it has took 7 years since I started our company) I went through lots of fuckups. There was: tiny organization, little bit larger one, almost bankruptcy, UE project with a lot of madness around, we were cheated by a salesman we trust and so on and so forth.

When some investor was unsatisfied because of project one blamed personally me, I was refused so many conferences I even remember, when we started DevCastZone.com I received heaps of emails from frustrated users with many reasons: err 404, to slow, to expensive, I expected something else and so on and so forth.

You know, for the last eight years I was motivated mostly negatively by the environment I worked in. Really! Of course there were days, workshops, coaching sessions when I met attendees needs and it was fucking awesome. These days are like a pearls - they are worth to challenge every single day.

Despite all these things I sill have fun at my work. Actually thanks to these events I achieve all stuff in my work: businesses, books and articles written, presentations made, friends. So, what the hell the idea with positive motivation??

Just Do It! Pattern

Hope you have read the Fearless Change by Linda Rising. In not, Just Do It!

Well, Just Do It! it's one of the patterns Linda described to introduce new ideas to the organizations. This is a short story how to use it.

Once I coach an organisation. I was mostly focused on the work with management board, my friend coaches the developers.

The have also group UX Specialists who work together in one room. They serve many projects and customers and were really frustrated about their WIP, relationship to the other teams and to the whole organization as well.

We met in the kitchen and I was told how they work and what kind of stuff they deal with. We almost set meeting for the workshop following week, but...STOP! Let's do something NOW!

They asked themselves just two questions:

• What we offer our clients (business clients, other teams, organization)?
• What we require from our clients (as above)?

Pretty hug questions, huh? Because of lack of empty space we wrote all that on the window.

And that's all. It was 15-minutes long Just Do It! Pattern case. Leaving the room I said casually: Listen guys, you might think about this window. I would back following week.

Next visit in the UX room were really surprising. The cover all isses with possible can-do solutions.

Starting from that point we ware able to do some deeper analysis of their current situation.

Again, we did a one week break to re-thing all that. So, I was really touched when I saw this:

They take matters into their own hands. They start to visualize the workflow, to track distractors and WIP, they founded standards of UX-craftsman in the organization. But remember were they start - at the window.

Well, big changes are really difficult, but teeny-tiny changes are quite easy. So, Just Do It!

Soft Skills Buzzwords Confusions

Agile way of thinking opened engineer's eyes on soft skills. There are a lot of stuff about it at agile conferences. From my point of view there are lots of misunderstandings around this topic.

We like to use buzzowrds like *DD without deeper understanding the stuff beneath. I identified that the most overused and confused as well are: coaching, team coaching, mentoring, training, NLP, NVC. To clarify what is what I prepared a talk.



I presented it atZwinnaŁódź (AgileLodz) community meeting. Oddly enough it took 2,5h hours including QA to pass the presentation through, but hope you guys enjoyed ;)

Second Edition of My Book is Comming

I finally completed the script of the second edition of my book: Tailor Made Software. How to Talk to the Customer Who Doesn't Know What He Wants?

What were my motivations of writing:

• my publisher :)
• feedback from clients and attendees of my trainings
• I had rethought all this material during last three years so that came to conclusion that some of the stuff need to be described little bit different

What are the changes comparing with the first edition:

• pointed that business needs is a critical thing in the context of business-IT relations; I developed some useful techniques to discover them; also included usage of User Stories
• introduced dichotomy: mechanics of a conversation (questioning, stories, conversation flow, etc.) and chemistry of the conversation (soft skills, contact, empathy); also delivered techniques to use both of them
• underlined role of the conversation context
• some folks were confused because examples of conversations involved developers, analysts, clients and so on; now all conversations are between generic Specialist and generic Client
• nice professional pictures inside the book by Maria Pankowska
• new awsome cover by Helion
• some minor bugfixing

Some times I meet folks at the bus-stop, in the bus or train or at the conference, who were sharing with me their thoughts about the book. Thanks you all, guys.

Many thanks to Maria for superb pictures
and to Krystian for deep professional review of the author's version and some summary on the cover.

The book will be available in about September this year.

This is the detailed table of contents..

7 Red Lines Problem and Solutions

A year ago a post an entry related to Seven Red Lines Comedy Sketch. This the movie.



I used the movie to explain how the customer needs are important. However experts creativity is infinite and Some folks sent me two solutions of the problem. These are awsome!



and the next one:

Agile Coaching Clinic @ 4Developers Conference

This year at 4Developers Conference coaches from BNS IT arranged a special event for attendees.

We'll provide a free agile caching sessions. During the session you will get a deeper insight in issues you faced with as a TeamMember, ScrumMaster, ProductOwner or Agile Coach.

Look for the guys wearing T-Shirt like the one and subscribe the agile coaching session early!

Developing with Different Cultures

Couple weeks ago I announced that I was working on chapter about collaboration with different cultures (from Polish folk perspective). So if you want to help I put some guideline for that purpose.

If you want to contribute to, I offer info about contribution in the chapter and immortal glory:)
Contact me via m{dot}bartyzel{at}bnsit.pl

Kanban Board Needs the Goal

Please consider this blogpost as a continuation of my previous Kanban on The Fridge Door entry.

So I had my Kanban board first on the fridge door and finally on the kitchen wall. I put cards, I moved them through the board, I limited WIP, visualize work, and improve the flow.

Because of my frequent business trips I moved the board on Trello to share it remotely with my wife. Trello is, in my opinion, the best compromise between prize (for free) and functionality for an individual and for a team as well.

So, we bought a flat - big thing for a family, huh? Of course I created new board as below:

After couple of days I was overloaded by number of task, which (as my architect claimed) "absolutely must be doing NOW", but my budged was fixed. Those days I had thoughts I want to share...

#1 Kanban doesn't work

Yes, I blamed Kanban, because my project was to complicated to be managed by Kanban's approach. I thought that touching up the flat is VERY SPECIFIC project where Kanban didn't apply.

That's funny because many teams I work with have also VERY SPECIFIC projects/system/architecture/organization (choose most suitable), where all well known approaches don't apply. Despite of the fact that those approaches work perfectly well for the rest of the world.

#2 I need different tool

I also blamed Trello because it has just only one-column swimlanes, so that I couldn't see the big picture. In consequence I installed some addons to my FireFox to reach multi-column swimlanes and I started looking for better tool with smaller cards and bigger boards.

That's also funny, because many teams I work with, look for the tool/framework/library/programming language (choose most suitable), which is..., which is..., aaaaaaaaa, you know..., which is fuc*ing the best!

But...

I try to be devoted my FirstProgrammerRule - when something doesn't work, investigate your code first.
So I started wondering what was the reason I had so many cards? How I evaluated them? Damn, what the board was for?

Finally I realized that main goals of my board were to visualize work, to collect tasks in one place and to do them faster. But if doing faster is the only goal you end up with more output instead of more value.

To evaluate business value you need a purpose of the work, you need the goal of the board. That was the Aha-moment for me.

In my case the goal was: Move in (budget is fixed). Then everything made clear and simple, because the more a task made me closer to move in, the higher business value it had.

I need minimum stuff in the flat to move in with my family. I defined with my wife what the minimum meant for us and reorganized my board.

It turned out I need: floor, kitchen, one bathroom not two, one inner door not four, two wardrobes and some other stuff. The board started working perfectly well, even with Trello, even with Kanban :)

What happens when you reach the goal of your board. That's OK. This is end of the work. It's time to rest. Later on you will start up new board with new goal.

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!

Conversation Patterns for Software Professional. Episode #3

Finally InfoQ published third part of Conversation Patterns for Software Professional planned serie. In case you missed the previous two there linked to my profile.

Now I have some work with the second edition of my book, so I give the articles a break for about six moths and then I look at next set of three articles.

4Developers is waiting for your submission!

Great 4Developers Conference is waiting for great submissions. I strongly encourage you to be a part of the Soft Skills and Business Relations track. In most cases it is easier to change your framework than your colleagues and this is why you must consider this track as a speaker or an attendee as well.

Please consider following suggestions to improve your submission. These are taken from Agile Alliance review process which really impressed me last year.

1. Have a good title. This is your first opportunity to make a good impression. If it grabs the reviewer, it will likely grab the attendees.
2. Have a well thought out introductory paragraph that tells attendees why they should come to your session over others. Consider having a short call to action in this section and a problem statement.
3. The process and mechanics should tell the review team, as well as the attendees, how you plan on spending your time. Can it change? Sure it can. Should it at least be complete? You bet. This section should include the timings of your session and how you will use the time. Don’t skimp on this part; it should be the meat of what it is you want to do. Additional items you may want to inlcude in this section are:
   
   Audience. Understanding who your primary audience is, and communicating it, is key to a good submission. People need to understand why they should come to your session and why it adds value. Sure, you are listing if it is introductory or expert as a checkbox, but I look for additional details here, like, "this session is targeted at senior managers inside the company who want to introduce XP and Scrum but are not sure how to get started."
   
   Presentation Format. Yes, there is a dropdown that allows you to check lecture or workshop, but you should still consider weaving a description of your format into this section of the submission. For example, a piece of text from a tutorial session that was accepted says "I’ll start with an introduction and purpose of the game, then explain the rules and show an example of how to play. They’ll have one hour to complete the game." This tells me a lot and I can see how the game will roughly play out.
4. Presentation Delivered Before. Have you done it before or is it new? If you have done it before, provide a link to a video or some piece of detail where the review team can read about it. If it's new, call it out.
5. References to Your Speaking Ability. Not every reviewer will be familiar with your speaking style. Having a couple names that people can follow up on is beneficial. If you can provide a link to a video clip, that could be helpful to the reviewers.
6. Learning Outcomes. Good learning outcomes list what people will take away - e.g. "Learn that effective and efficient meetings are focused strategically, tactically or daily - not all mixed up." Bad ones say things like "get an understanding of agile" or "learn new coding techniques." Reviewers and attendees cannot make a determination on so vague a description.
7. Your takeaway: Have a clear vision of what you want to present, lay out the benefits to attendees of coming to your session over others, highlight why your session is valuable (through data or other means) and tell us, if you have presented it before, what you have learned and what you will do to improve upon it.

We want to deliver great content to our attendees. So, however all of the above items are important, submissions without learning outcomes clearly defined won't be accepted.