The Three Legged Pig | The Three Legged Pig

Meeting madness

Mar 122011

I think there are two types of meetings: essential, and really essential.

I actually enjoy meetings, they get me away from my desk, and they provide an opportunity to get some input, for some decision making and to get dormant parts of my brain working again.

Essential meetings are those required to keep a project going, they might be daily or every few days. They can be something where people get together in a meeting room, or just pulling your chair up to a co-workers desk and going over something. These meetings get the most done, but are the least organised. However, one clear ingredient of these types of meetings is that they are usually internal meetings, and as such they tend to get spontaneously created, shifted around, forgotten, cancelled, changed or pushed into the background and as as Agent Smith says, it’s inevitable.

And if the focus is on getting the job done then meetings are like doing a check of the map to make sure you’re going the right way. If the highway doesn’t have any turn-offs then you don’t need to check the map so often. But if you’re in a squiggly city like Canberra, then you need to check the map every few streets (or have a good GPS.) But eventually you have to have one of these meetings to make sure all is well in the world. Thus, regardless how much disdain you give these kinds of meetings, they eventually become essential.

Really essential meetings are usually external meetings with the client. These will have a fixed day and time and rarely get shifted due to the amount of work it takes to actually organise it. These meetings can go for an hour, sometimes more and consist of quite a bit of waffle, kerfuffle and other ~fuffley items. Due to the number of stakeholders involved and their relative levels of power within an organisation, the ratio of decision making to participants tends to approach zero. (Or one, I never was good ratio maths.)

Well, I guess that’s a bit of an exaggeration (the inability to get things done in client meetings, not my mathematical ability with ratios.) But part of the challenge is that in internal meetings there’s already a corporate language in use that facilitates faster communication. When meeting with the external client, the use of language has to be very carefully clarified in order to avoid ambiguities.

When ever I have a client meeting, I’ll take lots of notes and then after the event (and sometimes, it is an event) I go back to my deskicle and write everything up as best I can and send it to all the stakeholders. (That’s an odd expression, stakeholders, it sounds as though Buffy is going to turn up with her friends and kill Edward, et. al. One can only hope.) Then afterwards I can use the notes as a point of reference of what I’m doing. Internal meetings however are just a fluffy feel good get together to do a check of how things are going. Usually.

I don’t like to have internal meetings run like external ones with client. But that’s just me and the situation I’m in now. If I was working in a huge corporation and I had people from all different departments who didn’t know each other, then yeah, I’d be a bit more formal, but then I think that would reduce the productivity of the meeting. Formality however reduces ambiguity.
So, where does that leave us?

In a mixed up world between formality and ambiguity.

Back to agile fundamentals

The Three Legged Pig No Responses »

Jan 302011

So, I’ve been trying to get my head around how best to deal with our heterogeneous development environment in an agile way. It’s easy to say a process is agile, much like we used to say software was user friendly. We just slapped a label on it that said User Friendly. Now I think we’re sometimes doing the same with Agile.

So, how do we distil agile down to its core elements. Well, we don’t have to, it’s been done already. I think for where I am, competing priorities are the greatest concern. We’ve always got client jobs going on, in different stages of development. However, we usually try to make sure the developers have one block of work on a day, but one day might be a different job to the next. And we need to consider how we invest our time in planning for the future with new technologies.

Almost every good feature in computer operating systems today, including most features in DOS, Windows, and Windows NT, came from the mind of one hacker or another. Typically the work was not commissioned by a company. It was done as a research project then productized. Without these people, we make no forward progress. – Larry McVoy, The Sourceware Operating System Proposal, 1993.

Our struggle at the moment is finding the right balance between letting the developers have their time to freely investigate a new technology, and doing paid client work. We can’t spend all the time doing study and training, and developers aren’t robots that can churn out code 100% of the time.

One point of view is that research can be done as part of clients’ work. That is, when a client’s job is being quoted or designed we can throw in project time then and there to do the research required to get the job done. I call this the Brave New World way of doing things. The advantage of this is that it’s fully funded research and has a clear end goal and time allocated to the work.

The flip side is having dedicated time not allocated to a particular job where the developers can try out new things that don’t directly lead to a paying client’s job. The advantage here, as in the quote above, is that it tends to lead towards more innovation and discovering unique things that may not have been discovered if the goal had already been chosen. The down side of this, of course, is the cost. It doesn’t directly bring in revenue. Research is a cost, not a profit generator in the short term.

The business person prefers the first way, and the technical the second.

Planning for the long term is expensive, but the investment pays off much later. But how much later? And is it really the domain of a small business to be doing research?

I’m sure if we position research as training, then it would be fine. It might be easier to justify the expense if we had found a training course, the money to send the developer off on it, and off they went for a day or two. We’re not talking about pure research, but about investigating new technology without the pressure of delivering to a client.

So how does this all fit into a agile way of doing things? Well, it doesn’t directly. Agile is about delivering to the customer the best product within the constraints provided. And, although the principles mention

Continuous attention to technical excellence and good design enhances agility.

and

The best architectures, requirements, and designs emerge from self-organizing teams.

We need to think about how we can make those an input to the system rather than as an end product. How can we keep both the business and technical people happy?

Working with outsourced developers the agile way

The Three Legged Pig No Responses »

Jan 082011

So, I’m beginning to think that Agile development is a metaphor for the ideal work environment where the client has a clear idea of what they want developed – maybe not the end product but at least a good sense of the direction they want to go in, the development team gets their work done unhindered, the management team gets the resources they need and everything seems to just flow; like a sake cup flowing down a small estuary under the cherry blossoms while lines of haiku are composed.

But in reality, it’s more like the hapless cat herder trying to bring their untameable pets (pests?) under control, while battling a multi-dimensional beast from the planet Zorg with a useless blaster. Not impossible, but down right tricky.

The event that has brought me to this realisation is our effort to try and find a new outsourcing partner to cover our workload. In order to start a conversation (the trendy new-ish word for business relationship) I have contacted a few, and sent them complete specifications of what we want.

Not very agile.

But how are they supposed to quote on what I want? It’s not a big project – we chose this project because it’s rather small, has a short time-frame for what’s wanted, and if it goes pear-shaped we should be able to recover. And in return they have come back with fixed price quotes where the most expensive is 3 1/2 times more than the cheapest. I’ve asked for clarification of the costs from all three, but I’m not really getting very far with that.

But how is this supposed to work for larger jobs? Do we then just take a developer on a retainer and push work through to them? That seems like a better deal. But one of the things we’re looking for is not a single developer, but an organisation that can do different parts of the work: HTML coding, PHP coding, graphic design, etc.

And having someone non-co-located (un-co-located?) is not within the spirit of agile where all the developers work together in the same place and on the same project. You can’t have a daily scrum when some of the participants are in a different location and time zone, and maybe use a different language.

So we just end up with the same processes happening the same way.

The last project I tried to have the outsourced developers work on a daily basis meant that they were trying to second guess some of the development decisions that were clear to me, but not so clear to them. I thought I had explained most of the project to them, but every now and then a decision would have to be made, and they would make it and check with me. And for some reason, it always seemed to be the wrong decision. It wasn’t a bad decision, and looking back it seemed like the most logical thing to do, but it wasn’t the correct thing to do.

The happy medium that we’ve found is to get the local development team to do the interesting part of the project: database design, setting up the framework, some design and any interesting or new coding that is required, and have the offshore developer do a lot of the grunt work based on the work that has been already done. So far, that’s been a good place to start.

In the end, I don’t think we can work within an agile methodology for every project in every instance. We’ll have to have hybrid teams, where the local developers can work together doing what they do best, and we have clearly defined development for the outsource agencies.

Older Entries Newer Entries