tagged by: project planning
CannotMeasureProductivity
We see so much emotional discussion about software process, design practices and the like. Many of these arguments are impossible to resolve because the software industry lacks the ability to measure some of the basic elements of the effectiveness of software development. In particular we have no way of reasonably measuring productivity.
29 August 2003
bliki
EstimatedInterest
TechnicalDebt is a very useful concept, but it raises the question of how do you measure it? Sadly technical debt isn't like financial debt, so it's not easy to tell how far you are in hock (although we seem to have had some trouble with measuring the financial kind recently).
10 December 2008
bliki
FixedPrice
Many people belive that you can't do a fixed price contract in an agile project. Since the whole point of an agile process is that you cannot predict the future, this isn't an unreasonable supposition. However this doesn't mean you can't come up with a fixed price agile contract, what it really means is that you can't come up with a fixed scope contract.
29 July 2003
bliki
LargeAgileProjects
A common question is whether large projects can be done with agile techniques. After all many agile approaches are designed for smaller projects and the heavyweight ideas that they resist are more needed on bigger projects.
10 May 2003
bliki
RollerSkateImplementation
A key property of agile development is figuring out how to make a system go live with a small subset of features. We build software for the business value it offers, the quicker we go live, the faster we get at least some of that business value.
9 September 2007
bliki
StandardStoryPoints
I've heard a couple of questions recently about coming up with a standard story point mechanism for multiple teams using extreme programming's planning approach. The hope is have several teams all using equivalent story points, so that three story points of effort on one team is the same as on another.
6 September 2004
bliki
XpVelocity
I've seen this confused in a couple of places now, so I feel the urge to re-state what the meaning of the term velocity is in Extreme Programming.
10 May 2004
bliki
DesignPayoffLine
In the DesignStaminaHypothesis, the design payoff line is the amount of functionality below which it is possible to trade off design quality for time to market.
bliki
FivePoundBag
You can't put ten pounds of shit into a five pound bag
-- Anyone who has tried
When Kent and I wrote Planning Extreme Programming, we included this whimsical quote to help get the essence of what planning is about.
13 October 2005
bliki
FixedScopeMirage
Many companies like the idea of writing a contract that fixes scope and price because they think it lowers their risk. The mirage says that their financial obligation is fixed at the price of the deal. If they don't get satisfactory software, then it won't cost them.
30 September 2004
bliki
PrematureRampUp
One of the good things about software is that people seem to want it, and want it quickly. It's usual for organizations to ask teams to speed up production of software and from time to time the organization seeks to help in the way that really shows its commitment - by spending money to add more people to the team.
10 November 2011
bliki
ScopeLimbering
One of the basic tenets of agile development is that requirements changes aren't just expected, they are welcomed. This poses a particular challenge when an external company, like ThoughtWorks, is doing work for client. Many clients want a FixedPrice arrangement, which is really fixing scope because they see the FixedScopeMirage. But a fixed scope contract is totally at odds with agile development, so what is a company like us to do?
27 October 2004
bliki
ThrownEstimate
If you're using XP style planning, you need to get rapid consensus estimates from developers. Throwing the estimates lets you quickly tell when developers have same similar views on an estimate (so you can note it and move on) or if there is disagreement (when you need to talk about the feature in more detail.
22 June 2004
bliki
YesterdaysWeather
This is the principle that says you'll get as much done today as you got done yesterday. In iterative projects it says that you should plan to do as much this iteration as you did last iteration. The term comes from the Extreme Programming community.
12 May 2004
bliki