AGILE IN ACTION

The prevailing management (and financial) mindset in companies today is focused on efficiency, productivity, and costs. The primary concern is to maximize all assets and capabilities so that nothing sits idle. What this really means is keeping people working at 100% utilization.

Ron Jeffries speaks out about trading quality for speed. Basically, you're kidding yourself.

A team's velocity is the sum of the estimates of the user stories that were done during the iteration.

But 9 women can't make a baby in 1 month. Despite popular belief, there isn't a direct relationship between coder-headcount and productivity. Developing software is a creative and often complex process. It's not data entry. The other day Gus was asked by a very senior executive why his team of 16 people were far more productive than another team of 150. Both teams work at the same company. The short answer is the larger team is following a waterfall approach in a bureaucratic and political environment, while the smaller team has achieved agility in an organisation enclave. Process has a lot to do with productivity. Ironically many processes, apparently designed to increase productivity, are actually impediments to throughput. They're more concerned with putting ticks in boxes and producing intermediate artefacts than they are about delivering business value with production quality software. Jeremy Miller lists many of the scenarios that slow down a traditional team using waterfall: Waiting for missing requirements. Struggling through ambiguous requirements. Not having timely access to the business people. Delays from sequential hand-offs between disciplines. Testers and developers disagreeing over the interpretation of a requirement. Testers receiving code and not knowing what or how to test the completed software. Having completed code, but not being able to quickly deploy it for testing. Rework because requirements were misunderstood. Slow response time when the business people change their minds. Assumptions about requirements or architecture being overturned. Elaborate documents that quickly become obsolete. Code that was written because it will be needed later ; it never was. The Agile Manifesto values individuals and interactions over processes and tools . You can do away with prescriptive process and achieve significant throughput if you have a disciplined, colocated and cross-functional team (that includes the product owner ), with people who communicate effectively, collaborate intensively and focus on delivering business value. In an environment where they are trusted to self-organise and make decisions, and where they receive feedback continuously, I bet these people will always deliver more than a traditional team ( more a group than a team ) in a command-and-control environment. Why? Because empowerment and ownership breeds responsibility, commitment, accountability and motivation. You'll see delivery, early, often and regularly. Disempowerment and control breeds mediocrity, apathy, fear and demotivation. People turn up but they lack commitment and they don't really take responsibility. You'll see missed deadlines, a distinct lack of delivery, and ultimately you'll smell the dead fish of failure . Skills and practices also affect productivity. Who's more productive? The developer using test-driven development and continuous integration , who checks in code and integrates with others many times a day, and who collaborates with testers performing exploratory testing in parallel. Or the developer who codes for days (if not weeks) before checking in and integrating with others and then hands-off to testers for manual ad-hoc testing, bouncing back and forth as he fixes bugs until the code is working? I bet it's the first developer. Give me an agile process in a lean environment any day.

Sadly, these days most managers are more interested in the cost of quality than in quality itself. Essentially, they're wondering 'how low can we take our quality before we start losing customers?' They might permit us to improve quality up to a point, beyond which they see further improvements in quality as a poor investment. When a manager warns us that we're in danger of putting too much time and effort into quality, he's wrong! We can't take quality too far. And when scope, time and cost are fixed, as is so often the case these days, we've all been guilty of habitually cutting quality to meet the deadline. It's madness! This is one of the major contributing factors to project failure. Seeking excellence through continuous improvements in quality initiates a chain reaction of positive and beneficial results. Improve quality to increase productivity Originally uploaded by sjb140470 . When you continuously improve quality the defect count is significantly reduced and there are fewer delays. You find yourself with more time to spend on adding new features that are valuable to your customers. Productivity is increased and costs are reduced. People are happy in their jobs. Existing customers see more of the features they've requested materialise in the product with fewer defects, which secures their continuing loyalty. And new customers are attracted to your product because it's feature-rich, has a higher quality and is more reliable than competitor products and comes at a lower price. All this is very good for business.