Tester in Agile

A car, crash tested inside the box.

Someone asked me what should happen to the testers now that the developers were moving to Agile. How should they handle the new situation? This is how I answered: I think your best bet would be to integrate with the development teams. Here are two things you could start thinking…

Continue reading

Budget for Technical Debt Reduction

If you do not take care of technical debt reduction, you will end up like this house.

The foolish man builds his house on loose sand but the rains and the winds will crash it. (Matthew 7:24-27) Things have not changed that much in the last two thousand years. Technical debt remains a major challenge for software development teams.

Continue reading

Rock star agile developers

Two rock star agile developers.

Rock star agile developers. We are all talking about them. But are they truly out there? Studies show that developer productivity falls into a wide range. An average run-of-the mill developer has a productivity of 1. A great programmer might be a 10. A poor programmer might be a -1.…

Continue reading

Software Development Success

A roadpost pointing to success or failure

Software development success is organization dependent. Which organizations are successful in developing and delivering software? Which projects will be successful? That is a crucial question in an industry with an annual turnover of over 400 billion USD and only a 50% success rate. Is it enough to be agile or…

Continue reading

Agile projects requirements breakdown structure

fibonacci series in nature

In Agile projects, when a set of requirements are received from Clients, it may consist of (a mix of) A few needs, objectives, goals and some partial stories (even though it would have come in a structured document). Re-organizing (re-arranging) those into a requirements breakdown structure (RBS) helps ask right questions to…

Continue reading

Change is the only constant in agile

Neon sign: change. Change is the only constant.

How much change can a project withstand before it is too much? A requirements change rate of above 20% is probably too much . Typical rules of thumb figures for software development requirements change rate is cited as 1-3% . But the rate of change is accelerating. In 2002, 10%…

Continue reading

Software Effort Estimation Problems

Estimation is important for software developers. Software effort estimation problems are part of their daily lives.

Software effort estimation is an important part of the daily lives of many software professionals. I have joined the #noestimates debate on Twitter because there is a lot to learn from a discussion on estimates. I’m not ready to fully abandon estimates but I am interested in discussing where, when…

Continue reading

Agile Community of Practice

A data repository is not a community of practice

I’m a strong believer in learning by doing. I also believe that learning will be better when supported by an agile community of practice (CoP). Communities of practice allow self-selected members to develop their “capabilities, build and exchange knowledge”. In my professional life, I am involved in several communities including…

Continue reading

Evidence Based Software Engineering

Is it possible to do controlled process experiments in software? That was the question asked in the Kanbandev group over at Yahoo groups. We need evidence to support the practices we use in software development. After all we are talking about a serious business with an annual value of about 500 TUSD.

How detailled should a test case be?

I sort of remembered a very interesting article about one-liner test cases at testzonen.se. I have blogged about it before, but perhaps it is worth repeating myself? The idea is that detailled (manual, scripted) test cases are uninteresting, limit creativity and are expensive to maintain. The solution is to create “one liner” test cases instead. What about test documentation? If testing actions are recorded during execution then the documentation can be created afterwards.

I guess this goes to show that there is no one size fits all in testing. The right tool should be used at the right time to reach the right goal – which of course is to find bugs early rather than late.