Posts Tagged agile

So what is the right ratio between developers and testers?

One of the questions I’m asked quite frequently is what is the right ratio between developers and testers.

A variant on that question is what I typically see in other organizations as the ratio.

Well lets answer the second variant and then try to deal with the first.

Typically what we see in agilesparks customers is 2:1 or 3:1. There are some exceptions of 3:2 or 5:1 but they are quite rare.

What is right? Well as u might expect it depends:
– what are the skills/strength of developers and testers. Not all engineers are made equal…
– how are the responsibilities spread between roles? Eg test automation etc.
– what is the development life cycle style used by the group
– what is the quality of the code when delivered to testers
– technology and character of the system. Usually the lower the product is in the stack the more testing it needs per code developed. This is due to the amount of impacted areas, the complexity to test, and the breadth of the configuration/platform matrix.
– how much test automation exists

One of the typical dynamics of a phased waterfall-like development lifecycle is that QA phase starts late and pressured and compromises in quality are part of life

This means very tough weeks/months for the poor testers which get a big blob of code to work on, they are outnumbered, usually outskilled and the following happens:
– the perception is that test is the bottleneck. ( well I would say that in waterfall each phase is a bottleneck. Those that tend to be the last ones just get the short end of the straw 😉
– either test phase is prolonged or developers are asked to help do testing. Or both.

But what also happens is that organizations get used to this. It’s a fact of life. For some reason the need to strengthen the test organization is usually outweighed by ability to develop more features each version.

Another thing is that developers do end up helping testers they usually do it in crisis mode when their only option is to help do the work, not help testers have an easier job the next time

Lets see what happens when such an organization moves to agile/kanban

In kanban or any kind of lifecycle that is feature driven developers and testers are expected to have more
Or less the same pace / feature velocity. So our typical outskilled outnumbered testers usually quickly appear as a bottleneck early in the transition to agile.

Limiting the WIP in test and Dev causes Dev to stall, leading to one of the classic discussions in kanban workshops and even some kanban games I wouldn’t mention to avoid spoiling the fun ( Carlos – we know you’re out there!)

In an upcoming post I will try to cover what can be done when this typical scenario happens, using practices from Agile Testing, the TOC five focusing steps, and agile engineering practices I general.

And we will try to think what is the right ratio for an agile environment.

Leave a Comment

Its hard to embrace change…

A key theme in Agile is embracing change. We hear time and again that change is good, we should “welcome change”, yada yada yada. Most teams I see are sick of change. On one hand they are not fully exposed to the business case for change, to the sense of urgency around changing fast. On the other hand, change is HARD for them to absorb.

Effectively embracing change means overcoming the cost of change curve. Traditionally, we were taught that change costs more, the later you learn about it. This is still true. The cost is comprised of the complexity of dealing with change when it is buried under layers of work that was done since the original development was finished.

In many systems the quality of the codebase makes it even harder – spaghetti code, copy pasting, and a bunch of other smells / technical debt aspects make time work against us.

So how can Agile Engineering practices help us deal with change?

First, since we anticipate anything can change, its important to avoid wasting work in areas which might change.

In general its important to do as much of our work “just in time”, avoiding the planning ahead that is based on wishful thinking about how the future will look. The XP principle of “Simple Design” helps us provide the simplest solution that can possibly work. Complexity and “Fully Featured flexible solutions” are our enemy here. We have no way to know that they will actually be used since we cannot really predict the path the system will take. You Ain’t going to need it – YAGNI is another key XP phrase.

We also need to keep our systems at very high codebase quality to minimize the cost of changing when it does happen. Refactoring as part of the ongoing development cycle helps us achieve a Sustainable Pace where we might pay an ongoing small price, in order to be ready for whatever curve ball change throws at us. Think of exercising in order to keep our body healthy and able to cope with whatever life throws at us…

The air force uses AWACS planes and other types long range radars to get early warning.

In agile we use iterations, TDD and CI.

Iterations are a key factor here. Since we get feedback after every iteration we hear about required changes earlier, as well as discover many defects due to the testing we do in order to achieve PSP. This much can be achieved without any special engineering practices.

Test-driven Development provides much earlier feedback about the behaviour of our units, modules and systems, and makes sure that our system is REALLY Designed to meet its specification.

Continuous Integration provides early warning for any integration issues, avoiding any form of “Big Bang” integration problems.

Once we do need to make a change, we rely on a high quality codebase, as well as several safety nets, in order to proceed quickly.

If we use ongoing Refactoring, applied the relevant Design Patterns, kept the design as simple as possible, the cost of making the change will be as low as it can be. Once we implement the change, Continuous Integration, together with the test suite we accumulate using TDD, will catch any problem we create very quickly. Weeks of regression testing, or Dev/QA managers losing sleep over a risk-taking testing coverage, will thankfully become a part of our past problem.

Next in the series – how fast iterations strain the typical team starting with agile…

Leave a Comment

Agilesparks Agile VP R&D forum

Welcome to a new blog for Agilesparks, our Agile/Scrum solutions company.
On last Thu, we had the opportunity to present Agile/Scrum to a group of R&D leaders from various companies/organizations in Israel.

Danko provided his signature exciting intro to Agile, followed up by a customer success story, an intro to Engineering practices delivered by yours truly, a discussion of Agile Metrics and Measurements, and a Q&A panel.

Based on initial feedback we got it seems like we got people quite interested in what Agile/Scrum can provide…

If you would like to hear about Agile/Scrum we have similar opportunities coming up. Check http://www.agilesparks.com for more details.

At the meantime, checkout my presentation:

and some pictures from the event:

see you!

Leave a Comment