The speakers are decided and the program is printed and ready.
See you there…

Uncategorized | No Comments »

Being a scrum master is basically the same as being a coach, in this case team coaching. Coaching is about creating self awareness and making the coachee take responsibility himself. As a coach you are not supposed to reach any goals or solve any problems for the coachee. The same goes for the scrum master, it is not about managing and it’s not about solving the problems for the team. It is about creating self-awareness that makes the team take responsibility and helping the team focus on their task.
Coaching is what makes a self-organizing team.

These articles also come to similar conclusions:
Agile Management is Servant-Leadership (Agile Advice blog post)
Agile Coaching

Uncategorized | No Comments »

I have decided to try to terminate personal development talks (PD-talk, Swe. pu-samtal) in favor of coaching. I have tried coaching during a period for a chosen handful and it has turned out successful.

I want to support the employees in their personal development by enabling them to focus on their goals. The idea is to have a coaching session every month where we can talk about their goals and obstacles, to help keeping focus on these issues. This enables us to put up both long term and short term goals and to follow them up on a regular basis.

A PD-talk once or twice a year doesn’t allow us to put up short term goals in a successful way, and putting up long term goals without dividing them up into short term sub-goals looses focus.

For a consultancy business where most of the consultants are located externally at customer sites it is of even more importance to have a close dialogue with their nearest manager.

Yes there could be conflicting situation being a person’s manager at the same time as coaching them, but we have to live with that. The benefits still outweigh the disadvantages. Coaching is essentially about raising self-awareness and taking responsibility.

How do we do this then? My idea is that we kick-start with a coaching education for all managers and then we create a coaching schedule and simply start coaching. After a while we follow up and evaluate eventual needs for more education or perhaps a coach for the coaches.

Two educations that we are evaluating at the moment:
Coach2Coach
Mercuri

Uncategorized | No Comments »

This project took place several years ago, way back when I still was coding, mostly for Oracle databases. The customer was in the financial sector and the IT department was quite immature and had basically no formal processes or methods at all, no written requirements and no version handling.

A bit frightening at first, but we (unknowingly) adopted an agile approach:

• We worked directly with the customer who sat almost beside us dictating the requirements without any filters.
• Code was king - as soon as we got an idea we coded it to get a feel of it and showed it to the customer.
• We didn’t document - the code was the documentation.

Looking back we actually followed the Agile Manifesto.

The result was that the development went at a tremendous speed. But having no process also meant problems of course. To mention a few:

• We didn’t have an exit criteria. I didn’t know when I was ready, which meant that I eventually ended up in a really boring phase of endless changes back and forth, making me finally leave the project.
• Maintenance of the system would be quite challenging.
• We were a small team, but if team size would grow I believe we would have ran into more problems.

I think that adopting an agile method like Scrum would have taken care of some of the problems and let us keep the development speed.

Uncategorized | 1 Comment »

I have evaluated my blog experiment and decided to scale up. In this process I have renamed it, moved to a new domain, did a complete graphic redesign and finally moved all the previous posts, so everything should be here. I know I shouldn’t rename and move it, but I want to do it before it (hopefully) grows too much.

What about the name then? Well I am a member of Mensa so why not? I think it works pretty well, it’s easier to remember than the old one. And the IQ? 156 on the Catell scale, meaning top 1% of the population.

Well, enough bragging. Come on in and read. If you like it go ahead and subscribe or bookmark it. Or why not both?

If you have any feedback, please comment!

Uncategorized | No Comments »

The reason for human domination on this planet is our extraordinary ability to adapt to change. But why do we try to fight this ability within software development?

Only changes in the near future can be predicted, for the rest we have to adapt and overcome, like soldiers. Any change, even a small one can invalidate a whole plan. A goal however, is more stable and can survive even major changes. That is why an agile team must strive for a goal, not a plan, while responding to changes on the way to the goal.

The Horizon of Predictability is the distance into the future that a team can be reasonably sure that plans will be stable. Any further into the future plans start to get uncertain and even further the future becomes totally unpredictable.

The horizon of predictability varies depending on the environment, but is for most IT organizations not more than 30 days, i.e. the iteration length of a Scrum sprint.

To minimize the overhead in short iterations consider automating your environment e.g. continuous integration, daily builds and automated tests.

Read more here:
Change is constant - blog post at Agile Advice
The pros and cons of short iterations - blog post at Agile Advice
How long is a time box? - blog post at the Pragmatic Architect
Predictability Paradox - whitepaper by Mary Poppendieck

Uncategorized | No Comments »