Application Generation - Agile Development

Tracking your time on Solo Projects

Mon, 20 Apr 2009 15:32:00 -0400

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]

The Pomodoro Technique for Time Management

Thu, 16 Apr 2009 12:06:00 -0400

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]

Solo Scrum - Google Group for Solo Development Best Practices

Wed, 15 Apr 2009 10:20:00 -0400

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.

Solo Scrum - Workshop session outputs now available

Sat, 11 Apr 2009 07:20:00 -0400

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]

APLN Dueling Vendors: Mingle vs. Rally

Thu, 19 Mar 2009 13:45:00 -0400

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.

Duelling Vendors at APLN NYC Tonight

Wed, 18 Mar 2009 13:20:00 -0400

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!

Charging for Value vs. Time

Wed, 01 Oct 2008 10:59:00 -0400

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!

The Simplest Thing That Could Possibly Work: Getting Started with OO

Tue, 15 Jul 2008 13:24:00 -0400

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]

Lean Development AND Skills Acquisition

Wed, 09 Jul 2008 10:25:00 -0400

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.

XP 2008 - When Six Conferences Just Aren't Enough!

Thu, 08 May 2008 10:17:00 -0400

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!

Pair Programming with Ben for SCFUG

Tue, 29 Apr 2008 22:04:00 -0400

As reported on Stephen Moretti's blog, next Thursday at 3pm EST (8pm British Summer Time) I'll be pair programming using TDD with Ben Nadel for the SCFUG. I paired with Ben last night and thoroughly enjoyed the process. It makes it much easier to stick with the TDD when pairing and one of my goals this year is to pair with a number of good programmers as I think you can learn a great deal by watching how other people approach projects. Anyway, check out the announcement and sign up for the fun!

Pair Programming With Ben Nadel

Tue, 29 Apr 2008 08:37:00 -0400

Neither Ben nor I have ever paired and neither of us have much experience with Test Driven Development, but last night we spent a couple of hours pair programming and developing a new BaseObject for a project using TDD in MX Unit . . . [More]

It's Not About the Language, Stupid

Mon, 28 Apr 2008 11:56:00 -0400

A great developer isn't the one with the deepest knowledge of their language of choice. Most of the time (and there are exceptions when you need the deployment demon or the garbage collection guru) the best developer is the one that has the best understanding of all of the pieces of creating great software. That's why approaches like Domain Driven Design are so valuable and why project management approaches like Scrum and engineering practices as described in XP are so crucial. It's why I'm particularly excited to see that Lean software pioneers Mary and Tom Poppendieck will be giving a presentation in NYC next week. If you're interested in the craft of software and would like to meet like minded people from different language communities, I think these kind of meetings are an amazing opportunity to become a better developer - irrespective of the language you happen to develop in. Comment on the previous posting if yu can make the meeting in NYC next week. I think it's going to be a memorable event.

Poppendiecks giving free talk on Lean in NYC

Mon, 28 Apr 2008 11:36:00 -0400

Mary and Tom Poppendieck are going to be giving a free talk on May 6th in NYC. If you're interested, post a comment below and I'll try to get you out an invite. For anyone who has read their books, this is an amazing chance to learn more about lean software development from the pioneers in the field. And it's free! If you are in town or can make it to NYC, just comment below and I'll try to get you an invite. For anyone interested, they will also be teaching a two day course.

Kent Beck on YAGNI

Tue, 22 Apr 2008 17:47:00 -0400

Seen in the extreme programming group on Yahoo! "A big part of the problem with YAGNI is that it is expressed indirectly. That was a communication style I was enamored of ten years ago that I found caused lots of problems. Today I would probably just say it directly, "It seems to me that you have reached a point where more experience would be better than more speculation. I encourage you to just implement X1 and see how it goes. You might want a simple little data storage abstraction. That will simplify the code in X1 and make it easier to move to a database later." "Here's what I do: consider X2 a little, but try not to get so caught up in it that I freeze. As soon as I hit unknowns about X2 or X1, I stop thinking about X2 because I have something more important to learn. That's what I am getting at with YAGNI--breaking the cycle of fear and procrastination that I tend to fall into when programming. I use it with people who come to me for help when I think they have fallen into that same cycle. As I mentioned in a previous post, there is quite an opposite intervention, "Have you thought about..." that I use when I see an important issue, short- or long-term, that isn't being considered."