perfect stranger by daniel sandoval

Before the holiday I wanted to write a post on agile software development and risk management, but it seems the dog ate my fieldstones for that, so I’ll write about the risk of not writing instead.

I liked Johanna Rothman’s advice in The Gift of Time

The best way to prevent writers block is to write

For me it seems writing alone is not enough, it is publishing that gives me focus to go for it. A large collection of notes seems to hinder publishing, because it means I have to chose which of the notes to work into a post, which might mean procrastination. Call it publishers’ block instead of writers’ block if you want, but the end result is the same – less interesting things published than possible. I get around to posting event announcements and reports of those events, because there is some time pressure: announcements after the fact don’t make sense, and reports are more interesting for readers during or right after the event.

Even the draft for this post has been laying around since before my holiday and it contained this advice by Mike Cottmeyer :

It took weeks to write a post because I wanted everything to be perfect… I couldn’t let anything go. The guy I was working for at the time gave me the best advice ever… he told me to get over it. That’s easier said that done… but you know what… that is just what I did. I got over it and started writing.

So I’m taking that piece of advice right now, and may take the next one:

Try to limit your writing to two hours. [...]The idea is that you want to set limits and create a little pressure to perform.

I know from my coaching practice that setting defined timeboxes helps, doing it regularly: even better. How that works and to what I’m applying it right now, I’ll write now publish about it later

a “ development project for bored consultants”

contact Johannes if you’d like to spend (at least) one day per month in a project with other agile consultants and you are willing to give this project priority on that day.

I believe a regular programming project with like-minded programmers this is a great idea. Programming is a long haul activity, some effects you only notice after a while, and jamming with fellow practitioners is a great way to learn.  The reason I support Johannes’ idea is because I believe it will support participants in sharpening their saw – increase understanding of what they already know by spending time doing programing work and reflecting on it, as well as creating a space where experimentation is not an option – it is a requirement

A Lady's saw - by KaCey97007

As a consultant I am most often hired to explain what I consider to be “the basics”. This is a moving target of course, as my understanding of “the basics” changes with experience. When I started out coaching teams, I did a great deal more experimentation on client projects, as I was learning “the basics” together with my clients. There is nothing wrong with doing “the basics” again and again, that is also a way to deepen your understanding of a subject. Kata’s in a coding dojo work like that – coding dojos are another way to keep up your programming skills.

However, keeping up is not enough. I am lucky in the sense that I have been able to keep up my programming skills by teaching technical workshops and doing hands-on coaching on client projects occasionally. I’m starting on another hands-on project for a client in a couple of weeks, where we will pay quite a bit of attention to “the basics” and everyone (including me) will learn some new things.

However, client projects are not always a good place to try out experimental stuff that has not been proven yet – that requires visionary customers with some slack in their organisation. And quite frankly, my customers often benefit more from my understanding of what I already know than from my desire for experimentation and learning (which I then satisfy by learning about their domain instead).

Therefore, having a separate project to regularly practice practices and having the space to try things out is good. I’m lucky: with my partners in QWAN we came to some of the same conclusions as Johannes. We need to be able to spend significant time developing with other visionary developers so that we can advance the state of our practice. We decided to develop new hands-on programming workshops with challenging excercises – beyond our current understanding of “the basics” and start developing some (mini-) products together. We did that because we needed some software to support our business, have some wild ideas, and last but not least wanted to sharpen our saw.

We want to improve our programming skills in an organisation that has the vision and slack to support it (e.g. our own ), because keeping up is not enough.

I particularly liked the draft on Financial Options, it explains a number of not so intuitive financial instruments and techniques (e.g. naked short selling and futures) in such a way that I find them easy to understand, and possibly explain them to others. Not a bad thing to have in turbulent financial times. Chris’s goal is to make them  understandable by ‘basically everybody’ – I encourage you to go and read it, and give him some feedback on bits you don’t understand.

What Juergen Ahting writes here is connected:

So the next time a manager tells us e.g. “Yes we should do that, but we haven’t got the right people / enough resources / … to succeed.” we should test him by asking “And what are you going to do about that?”.

In my experience, with a big budget it is hard to get things done. The team is overstaffed, and the incentive to set priorities is low. When I hear someone complaing about lack of budget, I am happy – I see an opportunity to do what matters most.

I’m working with Nynke Fokma on some budgetless websites right now. It’s fun, useful and goes way faster than a fully funded CMS project I was on. We are working from passion instead of a budget.

So, next time a manager tells us “This project is fully funded”, we could test them by asking: “What would you do if you had one tenth of the budget?”