Thoughts in the Wilderness

I’m into my second month at my new job.  I remain amazed at the amount of documentation that is being generated.  Being a Microsoft shop, almost everything finds its way into Sharepoint.  I’m not against Sharepoint per-se, but I do find it very opaque, i.e. hard to find stuff.

Its like having a lot of interesting papers on my desk, but they are all inside sealed envelopes.  I can open the envelopes, but when I’m done with it, it goes back in the envelope.  Sometimes there are other envelopes inside the envelopes.  As I said, very opaque, and very non-agile.  Contrast with what I am used to, which is a Wiki.  Totally searchable, easy to find what people have been editing.  More like a nice folder with happy little index tabs.

Sharepoint rant over, moving on…

The Business Analysts (BAs) had a slow start, with the result that we started developing our product before they had really written any requirement documents about it.  The result is that they are playing catch-up, and documenting what we have provided, and asking all of the questions that we should have asked while we developed it.

We do not have a single customer, or product champion.  This means that the questions are difficult for anyone to answer effectively.  It also means that the team is pulled in several directions:

• software architect tries to get us to do multi-tier and service-based and ultra secure at the expense of usability
• managers care mostly that it is done on time
• business analysts care about “checking off” features
• there is very little optimization of features, i.e. everything is equal priority

The result is that we have a fairly well architected, feature-full product that is hastily put together.  Features are surface deep, i.e. we are not “done” to the level that an Agile team would normally consider “done”.  Usability is low, and the product lacks perceived integrity.

Even given all of that, I remain optimistic.  We have a solid team, and every day we work more closely together.  As I understand more about the environment, I am able to make small adjustments to improve it.  We have a lot of time left to deliver, and upper management expects that it will be very much a v1.0 product.

Well today we had our first retrospective, a day before the end of our first sprint.  I used the tried & true format of “What went well” followed by “what went not as well”.  We scheduled an hour for the meeting.

As usual, people had a lot of trouble coming up with positive things to say, and not much trouble coming up with negative   One person refused to write anything positive!

It came together pretty easily that the topic that concerned the most people was “requirements”, or rather the lack of them.  There was a fair bit of conversation, which could easily have got out of hand.  In fact, it did for a little bit when one person tried to hijack the meeting for a topic other than the one we agreed to talk about.  I redirected that to another 1-on-1 meeting between the 2 of us later.

I tried to keep it in front of everyone that we wanted to come up with concrete actions that could be used to address the problems.  This worked ok to keep the conversation on topic, but no-one really suggested any actions except for our manager.  Being that she is the manager, no-one was seemed ready to contradict her suggestions.  They were good enough action items though, so I went with the flow.

The organization is very document-centric, which bothers me.  Rather than talk about ways that the developers could *pull* requirements through 1-on-1 conversations, there were a lot of suggestions on how we could better use email and documents on SharePoint.  Ugh.  I’ll have to live with the document-centric viewpoint for a while I think.  The best I can probably hope for, short term, is to find ways to make the documents useful to the team.

In the end, we finished on time and came out with some actions that we are taking to address our requirements-concerns.  Nobody was insulted or put off, and the team is fairly positive.  I’m pretty happy with those results.

As mentioned a few weeks ago, I have started a new job. My role is still unclear, but that doesn’t bother me at all – this way I can define my own role.

I’m working in a small team of web developers, trying to start on the next generation of the web portion of our core business product. The team was supposed to be Agile, but was decidedly *not*. I’m working on that, i.e. so far I’m defining myself as the Agile-guru.

We had our first planning meeting that I was allowed to run, and I went with my favorite planning tool (FreeMind). The team is very tool and framework oriented, so I think introducing the tool as part of the planning was less intimidating than if I had just gone at it with story cards.

My purpose in using FreeMind is to enable open discussion, and also to focus that discussion. It allows me to acknowledge everyone’s input, by reflecting it on the mind-map. The tree-like structure naturally allows everyone to be focused on the current area of discussion without being too distracted by other concerns. Once we have everything noted, then we can more effectively make estimates.

We had a very short estimating session. This was difficult, because individuals on the team seemed information-starved, i.e. they wanted to gather all of the requirements then and there. I tried with limited success to focus on just getting rough estimates. To keep it ultra-simple, I allowed only 4 time estimates: 1 day, 2 days, 5 days, or more (needs to be broken down further to estimate). As expected for a new Agile team, estimates were *very* ambitious, and we did not complete.

My final note is that it is interesting to be able to observe the team forming. I was the last member of the team to be hired, but before my joining, the others have barely interacted as far as I can tell. This means that we started in the “forming” stage of team evolution. This is characterised by the our manager being very hands-on, and directive. Basically, we are not a team so much as a set of individuals working under the co-ordination of a manager.

The next team-stage after forming is “storming”. This is a little stressful, and I hope we don’t lose any team members, or the confidence of our manager. I can already see some people coming out strongly on opposite sides of issues, and coming into conflict because of it.

Anyway, that’s my update. Wish me luck.

One of the foundations of all Agile techniques is that of frequent iterations developing working software. I think maybe this is a developer-centric view of a deeper concept.

When we talk about iterations, what we are really trying to do is to work with a client to break down their “big goals” into smaller ones. We ask them to call these mini-goals “stories” or “backlog items”. Perhaps “goal” is a better word. Why…?

For one thing, it is less feature-attached. A backlog item or story usually translates to a feature. Maybe thats not the intention,but that is how it works out.

I’m digressing though. The main thought is that one or more iterations fulfill some client goal. This goal often corresponds with a release. That is a very concrete view of reality. Anything smaller is not meaningful to a client.

We ask them to shuffle backlog items around in order to decide which features make it into a release. What we should be asking them to do is to decide on the minimal set of functionality that meets their goal. Anything after that is meeting some other goal.

On another tangent…

When we ask developers to think in terms of backlog items and stories, we are making it too easy for them. They need to be made aware that the code they write has to work towards the client’s goals. If a “feature” can be avoided or changed by meeting the goal in another way, then the developer needs to realize that.

For example? …. The client proposes a feature. Under certain circumstances, when the user clicks the Save button, we should pop up a dialog asking them if they are sure they want to do this. They must click “Yes” to continue.

Seems like a pretty normal feature. It will make a fine backlog item. But what is the goal of the client? In this example (based on real-life), the answer was that we needed users to manually assert their intentions.

The implementation of a dialog box is a poor solution (as it almost always is). A better one was to supply a checkbox that became enabled (and required) when the right conditions occurred. Thus, the user had to pro-actively assert that they were sure this is what they wanted.

The point is this – when we tell developers to think in terms of backlog items, we are really saying “think in terms of features”. Experienced developers will intuitively sidestep this and get to the real goal. Less experienced developers will do exactly what the backlog item suggests.

If we had stated the requirement as a goal instead of a feature, then the less experienced developer would have had to suggest the details of the feature. This implies design, and thought. Exactly what we want in an Agile environment.

Debugging. The process by which a programmer discovers how his program works.

I am a hyperproductive programmer. That means I can output 3-20 times the work that an average programmer can. (Arrogant? Maybe. Still true though).

One of the biggest reasons I am productive is that I make a habit of not “debugging”. This is my theory:

Debugging code is always wasted time

The only output of debugging is a greater understanding of the code. But there are better ways to understand code. I can read it. I can refactor it so as to make it easier to read. Leading to Corollary one:

Code reading and refactoring are more important skills than debugging.

Time spent debugging is not only wasted, it smells of poor code quality. If I lack understanding, that means that the code was too hard to read.

Programmers that do Test-Driven development understand this productivity boost. Once you write unit tests, you find that you no longer have to debug. Leading to Corollary two:

Improved up-front quality leads to less debugging.

Moving on. Maintainability. An ugly word. A nicer word is Soluble, (or grokkable). My productivity is far higher when I am dealing with code that I “grok”. Put me on a new project, and it will take me a while to come up to full speed. Much of that time will be debugging, refactoring, or reading code. Leading to Corollary three:

Solubility of code has a direct impact on time spent debugging.

(That is so obvious that it may be a truism).

In summary – debugging is a symptom caused by underlying causes of poor code quality, poor programmer skills, and code that is hard to read.

If you notice yourself, or other programmers debugging code, then ask yourself – which combination of the above is a problem? Then fix it.

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