The Human Batch Script

It’s Monday, the last day of the iteration. It’s time to build, package and release the next version of LogLady, the best tool known to man used for analyzing server logs. Robert, the build master, responsible for the buildprocess dreads this day more than any other day of the iteration. To Robert this isn’t release day or the last day of the iteration. It’s Build day … yuck.

 

Bug Squash – Another Software Team Anti Pattern

It’s time to do something about all these bugs. The dev-team keeps shipping bugs every other month – Manny thought to himself. He had been managing a team for almost six months now and his gut-feeling told him they were on a slippery slope to a really warm place.

 

My Pair Programming Journey (pt. 2)

Me and my colleagues had all jumped in the XP-water. Iterations, planning game, TDD and more. Things was running along quite nicely and I realized I had been pair-infected. Just like you can get test-infected, meaning you testdrive all your code. I had been pair-infected.

I wanted to develop all my code in a pair.

 

My pair programming journey (pt. 1)

“Pair programming is a software development technique in which two programmers work together at one keyboard” – Wikipedia, April 2009.

While this is basically true, I’d say it is a flavor of pair programming. If you’ve never heard about it before, this definition gives you a basic idea of what pair programming is about. Or if you’ve never tried it, this approach is one easy way to start. Just sit down next to your peer and start working. The only modification to your working area you need to do is to move your chair closer to your colleagues. And off you go!

 

How I learned about Feedback

What is feedback anyway? I looked it up and found this to be rather descriptive, accurate and short.

“The return of information about the result of a process or activity” – The Free Dictionary, April 2009

Early fall 2007 I participated in a workshop Esther Derby and Diana Larsen held. It’s called ‘Secrets Of Agile Teamwork’ and is by the way an excellent workshop, which I can highly recommend. One of the things that really stuck from those three days was the discussions, the information and the exercises we did about feedback. Partly because the exercises felt rather uncomfortable at times and partly because it changed my perspective on feedback.

 

Contracts and initial requirements – Impediments pt. 3

Contracts are shaping the way we work. Even more so if you are working as a contractor. Surprise?! Is this why we are spending more and more time on them? Fixing them, trying to make them cover all aspects of the work, all possibilities of opportunistic behavior and so on.

I believe we are, in fact, forcing or leading parties of contracts with steady hands into a supposedly pre-determined behavior. And without even thinking of it, we are limiting our own abilities.

 

Software Development Team Anti-patterns

I’ve decided to put all my current writings about software development team anti-patterns in one place. Namely a PDF. I expect it to grow and evolve.

A month ago this was a first public version so to speak. It has evolved since and now it contains some improvements and a whole new pattern. Which is a contribution from Chris Hedgate. In a short while there will be, at least, two more patterns.

Oh, I still appreciate all feedback I can get.

Get the latest version of  Software Development Team Anti-patterns.

 

Interaction with the outside world – Impediments pt. 2

Every effective software team interacts with the outside world. In fact,  all the teams efforts will be totally useless if they don’t. These points, where the interaction takes place, I usually refer to as ‘team interfaces’ or ‘contact points’. They take the form of a conversations between people. For instance, developers talk to customers or another team. It can also be a contract or a written specification of a product, a document, which is written by someone and read by another person. Chances are that these points will cause a lot of friction.

 

Why, oh why? – Impediments pt. 1

No matter how you decide to develop software, the less you develop the cheaper it is. So, before you start a new project or decide to invest in software development I would suggest you think long and hard about how you can solve the same problem without even writing a single line of source code. Or buying an off the shelf product. Before investing any money.

 

Where are your [real] impediments

I’ve been invited to speak at Turku Agile Day. No real instructions on what to speak about. No guidelines. While this can be very inspiring it also gives you a lot to go through. It took me well over a month to decide on the subject.

Sometime before Xmas I talked to a colleague and he said:

- Ola, why not talk about things outside of software projects and teams. You always say; No matter how effective you are, there is always something outside the team that bogs you down. Something that doesn’t really seem to have anything to do with software.

How right he … I was .. he is … We are!

This speech resulted in no less than five smaller parts. Which I have turned into blogs for your reading pleasure. They will all appear here in due time.

Enjoy!

Part one – Why oh why?

Part two – Interaction with the outside world

Part three – Contract and Initial requirements