Organic Agile: How My First Agile Environment Was the Best

Editor’s Note: This article was originally published on LinkedIn.

My first and favorite Scrum environment I’ve ever worked in (actually, the first Agile environment I’ve ever worked in) was at my very first information technology job. I had just graduated from college with an English Writing degree and had somehow managed to land a technical writing job at a small software company in Denver. Looking back, this was the most collaborative, cross-functional, self-organizing, transparent environment I’ve ever been in. The company’s development group was doing and being Agile using Scrum just naturally, without explicitly saying, “Hey, look at us, we’re doing Scrum!” We were Agile and didn’t even know it.

Ironically, my most profound and organic experience with Agile, the one by which I now measure all other Agile environments, was the one where nobody ever said, “We’re doing Agile, here’s how it works.” The development team was 100% cross-functional, co-located, and collaborative. While we didn’t sit in a shared open team space, the office suite was small and we were all in cubicles with low walls. It wasn’t a quiet place: developers, testers, and technical writers hollered over the wall at each other when they had something cool to demo. We organized our work as a cross-functional team.

When the developers had finished coding something, they called the testers and technical writers over on-the-fly to demo the software and get feedback. Testers weren’t the only ones who tried to break the software: everybody was encouraged to test and log bugs. As technical writers writing the online help and user documentation in parallel with the developers, we continually installed new builds of the beta software on our desktops. We tested and logged bugs, too. At the end of an iteration, developers, testers, and tech writers worked together to demo software and user documentation to the entire company in a large conference room, actively inviting feedback. We planned, committed, and reviewed as a team in iterations.

At the start of a project, the technical writing manager worked with her tech writing team to plan the documentation deliverables. She never assigned docs to us. The tech writers teamed up to decide who wanted to focus on what particular doc deliverable. We huddled up in a conference room together and broke the software out into user activities and tasks. We used a ton of sticky notes on a big wall to visualize all of the software tasks and the different types of users. We made sure that we were consistently thinking of the same types of online help topics across the product suite. Then we sliced the sticky notes into deliverable chunks. We used Agile release planning, story mapping, and personas to plan and visualize our work.

At the start of a work day, developers, testers, and tech writers had impromptu discussions where they’d let everybody know what they were working on that day or if they planned on demoing something. There were no silos or territories. Everybody was committed to trusting each other and getting the work done. If anybody had an idea for how to make something better, they’d speak up and say it. We’d discuss the idea and make it happen. We weren’t afraid to try new things. We planned our work day as a team, and continually inspected and adapted.

Sadly, unexpectedly, the company consolidated operations to their Maryland office and closed the Denver location. It wasn’t until many years later that I realized what a great information technology culture I’d been in. Even more years passed before I learned about Agile and realized I’d been in a Scrum Agile environment. One of the best parts about this epiphany was realizing that we were being Agile organically and naturally, simply because it was the best way to work.

It still is.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.