Anyone who has ever managed a software development organization will agree: time tracking is a pain in the neck. It’s difficult to get people to fill out time sheets, or otherwise submit their hours into some kind of system. Developers see it as a boring and irritating activity that is also invasive: people just don’t like to be tracked, and if you try, they will suspect ulterior motives. In short, most developers hate time tracking with a purple passion.

But what if you really need time tracking? Well, all is not lost. Read more

Over the years, I’ve been involved in a lot of discussions about how to estimate during sprint planning. If you’re new to Scrum – or even if you’re not – I hope you can find value in these musings.

Story Points. There are some very good reasons to estimate in story points rather than in man-hours. When you work in an Agile environment, everybody pretty much agrees that there is uncertainty to every user story. In order to claim that a requirement will “cost” 8 man-hours, you should first call in a business analyst to flesh out the requirement until it’s 100% unambiguous, and also an architect to design a solution for it. Read more

The use of the expression “labor arbitrage” to describe outsourcing in general, and outsourcing of software development in particular, has always seemed extremely misleading to me. The term “arbitrage” refers to the practice of taking advantage of a price difference between two or more markets: striking a combination of matching deals that capitalize upon the imbalance, the profit being the difference between the market prices. In other words, arbitrage means the possibility of riskless profit at zero cost. Read more

A while ago the structure of our project team changed, making it distributed: several very senior developers in another country joined us in order to assist in the implementation of certain features crucial to the project.

This was a reasonable decision because the new developers had deep knowledge of the underlying technology, and that knowledge could now be spread across all team members. Read more

To further explore the discussion about the role of architects on Agile projects that Sergey talks about below, let me share a few ideas that are applicable to smaller and medium sized teams.

Let’s assume you have a Scrum team that needs to build a complex solution. Maybe you need to guarantee 99.999% uptime, or handle 100K concurrent users, or make the application extendable while minimizing maintenance costs. Whatever the complexities may be, let’s look at our options. Read more

In response to the recent discussion thread on LinkedIn, and to expound on the issues raised therein, here are a few thoughts on the subject of dealing with architecture on Agile projects:

1. On any complex project that is delivered using an Agile methodology, special effort should be allocated for designing the right architecture, because the textbook understanding of Agile does not provide for it automatically. The actual implementation of this approach will depend on the project at hand.
Read more