Scrum Does Not Take Control Away From Developers

There is a small and vocal percentage of software developers who dislike almost any form of structured process around their work. Process is often viewed as a euphemism for control, specifically, management control.

If you take the time to carefully read the Agile Manifesto and to understand the basic elements of Scrum, you’ll see that developing better software is about empowering software teams. High-performance teams need the ability to structure their day-to-day activities and self-correct as new information is received.

Managers retain a critically important role focused on strategic goals, long-term planning, and operating environments. Everyone must actively participate to achieve successful outcomes.

I believe that agile techniques add considerable value to software development and I have the experience to back that up. Let me explain how I approach implementing a new software module using agile techniques.

Yes, I still write software. Not as much as I did many years ago but I still like getting my hands dirty. Currently, I work with the Salesforce.com Apex language (Java-like) and the associated Visualforce page description framework.

Here’s how it works…

At the outset, I like to get some aspect of the new software module running as quickly as possible. I find it much easier and more efficient when I see the code producing results that I can then build upon and extend. There are surely developers that like to write lots of code and start debugging it once an entire module or set of modules is written. That has never worked for me but if you are really, really, good at writing code, it might work for you.

Once I have something running successfully, I know I’m on the right track — my initial assumptions are correct and my approach should work. If I’m dealing with user interface issues, I’ll solicit feedback from the user community immediately even though the UI is simply a framework. I don’t want to spend a lot of time creating a nice-looking user experience only to be told they don’t like it. [This initial result could be called a ‘story’. It may even be more than one.]

Now, I like to dive in and tackle the most difficult part of the problem along with the test cases that will be needed. I want to know early on if I can reach my ultimate goal or not. In the case of Salesforce.com, governor limits are a huge issue. I need to know that I can deliver the results I want without exceeding limits such as the number of records returned or the time required.

To recap, there are three things that I believe should be done as early as practical on any project:

• Test assumptions
• Solicit user feedback
• Solve the most difficult challenges

Once these elements are handled, I’m ready to build out the final solution. The UI (if any) can be beautified, error processing can be extended, performance can be optimized, etc. [All of these efforts can be covered in individual stories.]

That’s my approach. It’s iterative, interactive and agile. It’s also lean with minimal overhead.

I should also point out that I have a strong, positive relationship with my manager and with the user community. It helps a lot! So what do you think?