The Regenerate Web

facilitating the regeneration of software teams

User login

Syndicate

Syndicate content

Services


Add to Technorati Favorites

Project

- delivery (3)
- duration (1)
- effort (3)
- estimation (4)
- metrics (1)
- Planning (1)
- PMI (1)
 - PMBOK
- task (2)
- velocity (6)

Management

- Boss (1)
- consensus (1)
- influence (1)
- leader (5)
- meetings (1)
- Motivation (1)

Browse archives

« May 2008  
Su Mo Tu We Th Fr Sa
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

Analysis

- modeling (3)
- requirements (3)
- research
- Analysis (1)

Who's online

There are currently 0 users and 0 guests online.

velocity

Critical difference between software development and construction...

|
Glen Alleman from the Herding Cats blog offers this post on the subject.  I want to agree with him.  I merely need to remind him that there is one key difference in the two industries:

Estimation - my experience with software development, and construction projects (church, home) though small, informs me of a key difference.  In construction projects, Once the required work is known, it can be estimated with some reasonable accuracy, because the vast majority of construction tasks have been done exactly the same way by the people who are doing them.  The tool set doesn't change every 2-5 years.  Carpenters still use nails to fasten wood together.  Wood still has the same physical properties that it did in 1965.  In software, there is a programming language every 6 weeks, and every 10-20 years the nature of raw materials change - assembler to procedural to functional to 4gl to object oriented, etc.  The new raw materials and tools require estimation to be redone from scratch.  The other factor in estimation is the difference in productivity between master, journeyman, and apprentice practitioners.  In construction the difference between resources can be a factor of 2 or 3, but years of stable estimates for building 40 linear feet of stud wall, provide a rational basis for scheduling.  In the software industry, only the practitioner who is doing the work can estimate his or her rate of completion, and the difference between practitioners can be a factor of 10 or 20.  

Value of Agile

| |

Reading this post on Carpe Factum made me want to share about my experience with "agile" management practices.

The value of the agile, especially SCRUM, is the continual measurement of the distance to a goal. That is, for me, a signficant benefit. Here are the premises:

  • Tasks size is small, so deviation from estimate is identified quickly.
  • Frequent measurement of distance to the goal. In SCRUM the daily meeting allows the SCRUM Master to measure the distance. The burndown charts they use show daily progress toward the interim goal

Measure the Change

|

You are a manager or leader. You want to make a difference. You recognize that the way that the organization does things is getting in the way. There are processes in place that need to change if things are going to get better. Most people want things to get better. Virtually everyone in every organization has some process that they would like to improve. Trouble is that it is difficult to get two people (let alone the whole team, division, department) to agree on what or how to change.

How do you ensure that the changes that you implement are having the effect that you hoped that they would? How do you ensure that the changes stick, that the people experiencing the change are helping drive the change, rather than resisting it. How do you collect sponsorship from those managers in positions to help you drive the change? I have one suggestion: Measure the change!

Syndicate content