tagged by: project planning

tags

API design · agile · agile adoption · analysis patterns · application architecture · application integration · bad things · big data · board games · build scripting · certification · collaboration · computer history · conference panels · conferences · continuous delivery · database · design · dictionary · distributed computing magazine · diversions · diversity · documentation · domain driven design · domain specific language · domestic · encapsulation · enterprise architecture · estimation · event architectures · evolutionary design · experience reports · expositional architectures · extreme programming · front-end · gadgets · ieeeSoftware · infodecks · internet culture · interviews · language feature · language workbench · lean · legacy rehab · legal · metrics · microservices · mobile · noSQL · object collaboration design · parser generators · photography · podcast · popular · presentation technique · privacy · process theory · productivity · programming platforms · programming style · project planning · recruiting · refactoring · refactoring boundary · requirements analysis · ruby · security · talk videos · team environment · team organization · technical debt · technical leadership · test categories · testing · thoughtworks · tools · travel · uml · version control · web development · web services · website · writing

2019 · 2018 · 2017 · 2016 · 2015 · 2014 · 2013 · 2012 · 2011 · 2010 · 2009 · 2008 · 2007 · 2006 · 2005 · 2004 · 2003 · 2002 · 2001 · 2000 · 1999 · 1998 · 1997 · 1996

All Content

Is High Quality Software Worth the Cost?

by Martin Fowler

A common debate in software development projects is between spending time on improving the quality of the software versus concentrating on releasing more valuable features. Usually the pressure to deliver functionality dominates the discussion, leading many developers to complain that they don't have time to work on architecture and code quality. This debate is based on the assumption that increasing quality also increases costs, which is our common experience. But the counter-intuitive reality is that internal software quality removes the cruft that slows down developing new features, thus decreasing the cost of enhancing the software.

29 May 2019

article


Lean Inception

by Paulo Caroli

An inception is an activity done at the start of a project to gather together the people involved and set a common direction and working style for the on-going work. The lean inception is a focused form of inception, which can be done in a single week. During this time we understand the key features and customers for the product, and build a canvas to formulate the characteristics of a Minimum Viable Product.

5 Apr 2017

article


Cannot Measure Productivity

by Martin Fowler

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


Estimated Interest

by Martin Fowler

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


Fixed Price

by Martin Fowler

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


Large Agile Projects

by Martin Fowler

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


Premature Ramp Up

by Martin Fowler

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


Roller Skate Implementation

by Martin Fowler

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


Standard Story Points

by Martin Fowler

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.

I think trying to come up with this at best of limited value, and at worst dangerous.

6 September 2004

bliki


Xp Velocity

by Martin Fowler

Velocity is a notion that helps calibrate a plan by tying broad statements of effort into elapsed time. Velocity is a statement of how much stuff a team (or a person if it's personal velocity) gets done in a time period. You should usually determine velocity by measuring how much got done in past periods, following the principle of YesterdaysWeather. A typical approach is to average the velocity the past three time periods to determine velocity for future time periods. Velocity was originally formed as part ExtremeProgramming but has since spread and is now used widely in agile software development of all flavors.

17 May 2013

bliki


Yesterdays Weather

by Martin Fowler

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

An Appropriate Use of Metrics

Patrick Kua

Management love their metrics. The thinking goes something like this, "We need a number to measure how we’re doing. Numbers focus people and help us measure success." Whilst well intentioned, management by numbers unintuitively leads to problematic behavior and ultimately detracts from broader project and organizational goals. Metrics inherently aren’t a bad thing; just often, inappropriately used. This essay demonstrates many of the issues caused by management’s traditional use of metrics and offers an alternative to address these dysfunctions.

19 Feb 2013

article


Alignment Map

by Sriram Narayan

Alignment maps are organizational information radiators that help visualize the alignment of ongoing work with business outcomes. The work may be regular functionality addition or technical work such as re-architecting or repaying technical debt or improving the build and deployment pipeline. Team members use alignment maps to understand what business outcomes their day-to-day work is meant to improve. Business and IT sponsors use them to understand how ongoing work relates to the business outcomes they care about.

18 August 2015

bliki


Design Payoff Line

by Martin Fowler

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


Five Pound Bag

by Martin Fowler

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


Fixed Scope Mirage

by Martin Fowler

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


Lock In Cost

by Wisen Tanasa

In my recent client engagement, I foresaw that serverless architecture was a perfect fit. The idea of adopting serverless architecture, though, didn’t fly to our client well due to the fear of vendor lock-in. It was an interesting time for retailers as staying in AWS might mean that Amazon, as another retail business, will be given a competitive advantage. Given the idea of not supporting a competitor, my client was interested to ensure that the solution chosen by us is fully portable to other cloud vendors.

5 March 2019

bliki


Purpose Of Estimation

by Martin Fowler

My first encounter with agile software development was working with Kent Beck at the dawn of Extreme Programming. One of the things that impressed me about that project was the way we went about planning. This included an approach to estimating which was both lightweight yet more effective than what I'd seen before. Over a decade has now passed, and now there is an argument amongst experienced agilsts about whether estimation is worth doing at all, or indeed is actively harmful . I think that to answer this question we have to look to what purpose the estimates will be used for.

27 February 2013

bliki


Scope Limbering

by Martin Fowler

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


Thrown Estimate

by Martin Fowler

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 UserStory in more detail.

22 June 2004

bliki


Yagni

by Martin Fowler

Yagni originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from ExtremeProgramming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it".

26 May 2015

bliki