Thoughts in the Wilderness

Very funny…

http://xkcd.com/c225.html

A while ago I did some research on the psychology of motivation, to discover ways that I could relate to our software development team that would support them being motivated.

I won’t go into the gory details (since it is was a while ago and I have forgotten my references), but what I came out with was that in order to be happy, a person should experience the following:

• competence – they should feel like they are good at their job
• autonomy – they should feel some sense of being able to choose how they work, and what they work on
• relatedness – they should feel that they are a part of some larger whole

This balances out over a person’s day-to-day living. So if I have no relatedness at work, the only way I can be truly happy is if I find a lot of relatedness elsewhere, such as participating in a sporting team.

Happy goes a long way towards supporting motivation, so in order to motivate someone, I should endeavor to make them happy.

Thinking in this way has helped me avoid repeating mistakes. One thing I had been guilty in the past was throwing unrealistic learning curves at people. But, a learning curve (while useful) temporarily reduces a person’s feelings of competence. If they feel lost, then they can also feel alone (relatedness).

Even small changes can push a person over the line, to the point where they start looking for a new job. I still throw leaning curves at people, but I try to do so in a much more supportive way.

I try to filter my thinking at work by considering whether different things increase motivation (by supporting feelings of competence, autonomy and relatedness), or decrease it:

• how do the work-processes we use affect the people that are using them?
• as a person with much more experience and knowledge, how do I interact with people with less of those things?
• how can we introduce a new employee to work in a way that makes them more likely to stay with us

I have been struggling to try and convey to our team what the difference is between an Acceptance Test and a Component Test.

This morning in the shower, I had some insight into this. Why not define testing by its primary purpose? Seems obvious, but I have not seen it stated this way before. So, here goes:

• Acceptance Testing – ensure that the software meets the business requirement
• Component Testing – ensure that the component does not regress
• Unit Testing (in the Agile meaning) – drive the design of the code

Looking at it this way, it definitely matters whether it is a component test or an acceptance test, because they meet different needs.

As a side-note, I have found it difficult to perform acceptance testing unless unit testing has also been employed. That is because unit testing tends to create those testable-hooks that let us attach the acceptance test to the system with minimal fuss.

Some friends needed me to clean their computer of spyware today. It takes a long time usually (I’ve done it before), so I decided to do it remotely. I had heard of Copilot before, and it seemed like a good opportunity to give it a whirl.

Copilot’s strength is its no frills, no config attitude. I download a single helper exe, and my friend followed an email link to download a host exe. We each ran our respective exes, and presto, I can take control of their computer. Firewalls are not an issue – if a direct connection cannot be made, then it goes through Fog Creek’s servers.

It cost $5 for a 24 hour usage – well worth it for the convenience of remote access without any special configuration.

It worked well enough. The Vnc-based remote was not as nice and responsive as windows remote desktop, but it was adequate.

The only major issue I had was no support for reboots – every time I rebooted, I had to call my friend and tell her to run the host exe again. Most annoying.

Regarding the cleanup itself, I think it went pretty well. I used sysinternals to poke around, and disable some autoruns. I tried a few scanners, Windows Defender, Lavasoft Ad aware, and finally the Windows Live one-care safety scanner. Of all of them, the most useful was the Windows Live one. It was slow, but very thorough.

At my job (a software development company), we use a variant of Scrum to manage our development. We have short development iterations of 2 weeks, at the end of which we deliver something of value to the business.

Since we started though, it has been difficult for the business to accept our output as complete. We did not have any formal acceptance process, or acceptance tests. The result was that we were seldom able to promise a completed feature in a single 2 week sprint, because the acceptance criteria were not clear enough. Each feature evolved to where it needed to be over several sprints, severely impacting our long term planning.

Code quality is good, due to a focus on unit tests, but we struggle to quickly bring a completed user-valued feature to market because we are not able to home-in on what the completed feature should look like.

In recent retrospectives, the team decided that we want our user-stories (planned work items) to be more completely defined. We will require acceptance test documents before we start working on functionality!

A bold step, because it will increase upfront planning time. I was a little nervous of this, mainly because it sounds too much like waterfall – plan upfront, and then deliver per the spec.

I read something that calmed me though, and confirmed (for me) that we are on the right track. Mike Cohn writes that user stories should embody these 3 aspects:

• a written description of the story used for planning and as a reminder
• conversations about the story that serve to flesh out the details of the story
• tests that convey and document details and that can be used to determine when a story is complete

According to that definition, we have been missing a whole aspect of our requirements!

So, we are now using Fit to create automated acceptance tests during Sprint planning. This helps us better define what will constitute success up-front. We will spend more time planning, but we will gain in the longer term because we will be delivering completed client value at the end of the sprints.

Already, the automated acceptance tests have been improving product quality and team communication. We have gained a valuable set of regression tests for the system. But we have decreased productivity in the short term, because developers and testers have had to learn a new tool and re-invent the way we communicate.

Whether the promise of improved long-term productivity follows remains to be seen. I’m confident, but time will tell…

My last post was almost a year ago…

The reason for that was that for a while now Google’s blogger has been screwing with me – ever since they started the beta blogger service. The short version is that it was too much trouble to login to make posts. Now however, they have gone out of beta, and I can actually login again! Woohoo

The new interface is much the same, with some minor additions, such as tag support and integrated login with my Google (g-mail) account. There’s more, but I couldn’t find a link to a simple “new features” page.

(In unrelated news) I found a nice quote today:

“In preparing for battle I have always found that plans are useless, but planning is indispensable.” – Dwight D Eisenhower

Sort of relevant to Agile software development. We like to plan, but we are not bound by the plan as we would be in the older waterfall model.