A lot of agile teams don't track actual time (in hours) at all. When you're working on your own and juggling multiple projects, however, it can make sense to gather "just enough" time tracking data. Here's why . . . Any input on whether/how you track time much appreciated . . .

[More]

I sometimes find that if I'm not "in the zone" (or running up on a deadline), I'm not always as productive as I'd like to be. The Pomodoro technique is one approach for improving your personal productivity . . .

[More]

Do you ever work alone on projects? Maybe you are a consultant working remotely sometimes? Maybe you are working up an open source project or personal project. If you ever code on your own and would like to do a better job of it, check out this group . . .

I created it after a workshop I lead at the BCS SPA conference last week. The goal is to help developers who work along on some of their projects to do a better job of delivering code using practices modified from the agile and XP communities for the individual developer.

If you're interested in working more efficiently on your own, please join us, introduce yourself and share your challenges and ideas.

To anyone who attended my workshop on solo scrum, the outputs are now available on the wiki. Thanks everyone for attending.

And if you're interested in learning more about using best practices from agile and xp for solo projects, why not join our new solo scrum google group?!

Here is a copy of the original output for reference . . .

[More]

Last night, the New York chapter of the Agile Project Leadership Network hosted a "Dueling Vendors" evening where both Rally and ThoughtWorks could show how their agile project management tools would handle user stories suggested by the audience. It provided a really great introduction to the tools and prompted a bunch of good discussion. Rally was clearly a little more polished, but also a little more prescriptive and focused on organizations that use a Scrum style approach. Mingle is a little less comprehensive and requires more configuration, but it's flexible enough to easily support a kanban style lean approach or even just creating an agile project management system for managing a company - not just a programming team. It was great to see both in action and to get to ask questions of the vendors.

Expect to see more from me on Mingle as it was a better fit to my use case, but both tools are definitely worth investigating.

I'm looking forwards to the APLN presentation tonight. The presentation (Duelling Vendors) is going to be a chance to see Rally Enterprise and Mingle go head to head. Participants will throw out user stories and the vendors will show how easy (or otherwise) it is to capture and manage them in the two toolkits.

I'm looking for some better tooling for capturing and managing user stories so it should be interesting to see how the two vendors come out in a head to head battle!

I've never been a big fan of charging for project work on an hourly basis - you can make a living, but there's no real upside, and because the variation in hourly pay between great and average programmers is (to my mind) less than the variation in the value they can provide, the better you get at adding business value as a programmer, the less the compensation matches the value you are capable of adding.

In most businesses, the answer would be easy - move to value/results based pricing. This is a little more interesting in the programming world because it is often hard to determine what the time will be to add a particular level of value, and clients often want to make changes that won't increase the value of the deliverable (and may even decrease it) but that will still burn your time and affect your costs.

Many programmers are moving towards Agile development methodologies. After trying a number of XP engineering practices and Agile project management approaches - from SCRUM to Lean I tend to think that agile is the most efficient way of adding business value to clients. However it isn't necessarily the best way to build a profitable consulting business because you're limited to charging by the hour.

We have an interesting hybrid model where our software product line allows us to generate an application very quickly and we deliver those apps for a fixed bid but then charge on an hourly basis for any tweaks the clients want (we also outsource the graphic design and the tweaking of the layouts when we can as those are the areas that can burn the most time in inconsequential changes).

It works quite well as we don't really want to work on an hourly basis so we do our best to keep the tweaking to a minimum and the client has control over how much the project costs. We guarantee to deliver something that meets the spec for a fixed bid so they don't have to worry about how long it'll take us to code a newsletter system or a custom content management system, but they have to pay by the hour for the tweaking at the end of the project so we don't lose money on picky clients - they just pay for more hours at the end in the tweaking phase.

What do other people do to get beyond just making an hourly rate (especially in a world where open source is replacing licensed software in many situations)?

Input appreciated!

Ben Nadel is doing a great job of working through the concepts of OO programming, but I want to promote Dan Wilsons advice of doing the simplest thing possible (even if procedural) and then refactoring to OO. Here's why . . .

[More]

Last month (hey, I've been busy!) Dan North posted a great piece on getting started with lean. As well as providing a good, brief introduction to lean development, he also provided a great overview of the Dreyfus model of skills acquisition which is really useful for anyone trying to understand how they and others go about getting better at something.

I'm presenting at or attending six conferences in May/June, but I was talking with Tom Poppendieck the other night after Mary's talk @ Google in NYC. I got the impression that the XP conference in Limerick Ireland was just the conference I needed to hang out with the people who "really get" Agile/Lean/XP.

Checking my diary I saw I would just be finished with Scotch on the Rocks, and could just fit the XP conference in before flying back to the US to present at CF United.

I'm really excited about the conference. There is an excellent line up, and I really feel that Agile/Lean/XP/SCRUM along with Metaprogramming/Language Oriented Programming/Domain Specific Modeling is one of the best ways that developers can maximize the business value they can produce.

Looking forwards to lots of learning this year!