• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Happy people, happy code

I have a friend who, after years being that one guy who was fluent in Cobol and kept that ancient but really important legacy application running, got a new gig at a local Agile tech company. The last time we got together, I asked him how he liked the new job.

“It’s hard to get used to it,” he told me. “I’m used to owning the application I worked on. I’d done it a long time and knew everything about it. I was the expert. But now, everything we do is so fragmented, broken down into tiny chunks of work to fit inside a sprint. It feels like I don’t have any ownership.”

This made me think back to my own days of programming in the green-screen world. (Yeah, I’m old. Shut up.) I would get a 1-4 page specification, more of an outline than detailed requirements, and my job was to sit down and figure it out. This often involved talking to stakeholders, collaborating with team members who might have useful expertise, and sometimes just abandoning my desk to walk outside while my brain chewed on a knotty problem. After a period of days or sometimes weeks, depending on the size of the work, I delivered working software. And I knew that software completely. I could train others how to use it; I could quickly make changes to it. Having my name on that code meant something, and I took pride in making it as perfect as I could. It’s been a long time since I’ve written code; how would I function as a programmer in today’s Agile world? Would I like it? Would I hate it?

I’ve recently been working very closely with a couple of feature teams to groom the backlog of a new, greenfield application. A couple of times a product owner or a development lead said something along the lines of “You need to tell the programmers exactly what to do. “ Frankly, this startled me, because it didn’t seem to match what I thought I knew about programmers. I began to worry, is Agile driving a change – moving software engineering from creative problem solving towards the mindless delivery of tiny chunks of code? That seems to be the opposite of what I thought Agile was supposed to be all about.

I think it all comes down to culture. After all, as some dude named Drucker once supposedly said “Culture eats strategy for breakfast.” In my experience with various organizations that each had their own peculiar flavor of the SDLC, the success of projects and the quality of the software created had a lot more to do with the culture of the organization than with the details of methodology. Agile as a philosophy started as a statement about the kind of culture where excellence flourishes. Since that simple, innocent manifesto, an entire industry has sprung up around defining and implementing Agile, and everyone wants to be doing it. But you cannot build an Agile organization with sprints and standups and user stories alone. Agile is about empowerment. It’s about setting aside the layers of formality and bureaucracy that waste time and money and stifle teams. If your programmers are unhappy code-spewing automatons, you’re doing it wrong.

No comments yet.

Leave a Reply

Your email address will not be published. Required fields are marked *