How to Use Agile Development Across Your Company

There was a time at Fishbowl when every department was storming to find the right processes and procedures to guide them to success, which led to a lot of experimentation. At one meeting, several departmental leaders filled several whiteboards with scribbled ideas in hopes of finding the grand theory of everything relevant to their department.

Stumbling Into the Solution

Light bulb lighting up in a hand, Fishbowl Inventory Blog

Many of us could have benefited from some schooling in business. Lacking that, we did the best we could with our limited views. At that time, I was the newly appointed testing manager. I had no experience testing software and even less experience in management (It was less than zero because I guess I had had a negative experience). I had worked at Fishbowl for about a year and this meant that I was a seasoned veteran compared to most of my coworkers.

It took several years of failed management experiments before we stumbled upon “The Art of Agile Development” by James Shore. This was a huge break for us. We found that someone had already written a bible on software development that perfectly married soft skills and hard results. It was the grand theory of everything that we, in development, were seeking.

In short order the development team became Agile zealots. Like most zealots, we were anxious to proselytize to our fellow department leaders. We were sure that we could make the Art of Agile Development the governing principle of our IT, support, sales, and marketing departments. After all, Agile doesn’t just apply to software development.

What Is Agile Development?

The first attempt we made was converting our IT department. Before I tell that story, I’ll explain a few things about the brand of Agile that Fishbowl uses: XP (eXtreme Programming). XP follows the Agile Manifesto and the Agile Prime Directive, which says:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

XP is the most simplified brand of Agile, and it encourages “soft” practices that build relationships and improve results. For example, XP users engage in face-to-face conversations and create cross-functional teams that share the same workspace.

The most obvious outward sign of an XP team is the use of lots of index cards pinned to huge planning boards. XP planning boards are my favorite Agile practice because using them creates some neat results. First off, we can’t write much on a 3×5 card. This forces us to engage with people rather than relying on confusing documentation. Creating extensive documentation requires a lot of time and effort while producing little value. What I mean is that we can’t sell requirement docs.

XP planning boards are also a great way to provide accountability. When a team’s tasks are on a public board it is easy to see who is stepping up and taking tasks and who is not. We ask our people to take the task card to their desks. As a manager, it’s nice to have employees take tasks instead of making assignments. This prevents micromanagement. In addition, our boards only have space enough for a limited number of index cards. When we have tasks that do not fit on the board, we keep the most important ones and leave less-important ones off for a while. This is an important mechanism of the planning board: It helps you prioritize and make commitments you can keep.

Trial and Error

So on to the story of IT and Agile. IT is the department in charge of our network, desktop computers, phones, and other hardware. We created a planning board for them, gave them a quick lesson on the Agile Manifesto, and collocated our IT folks. We expected some great results (e.g., better in-house customer service and more reliable phone servers) because when we adopted XP in development, we saw positive results fairly quickly. But what happened was stagnation. Things didn’t get worse, but they didn’t get better, either. Why?

One thing we noticed was that IT at our company really was not big picture-type work. Our IT process was similar to that of a fire department, always rushing to fix issues. Our IT department didn’t do a lot of planning or preparation, and as a consequence they mainly engaged in firefighting. Agile doesn’t work when you don’t take time to build stable infrastructure. In the end we decided to outsource the majority of our IT needs to a professional IT firm that we happened to know and trust.

Next up we tried an Agile experiment with our marketing department. Marketing came to us asking for a rundown of XP so they could have some context for project management. Fishbowl’s marketing fellas created public planning board and used index cards to lay out their tasks. However, they were not able to limit the number of tasks they accepted. They also could not collocate their workspace. They ended up with huge, unwieldy tasks lists. They spent a great deal of time shuffling hundreds of cards around while reaping little or none of the rewards that we had seen in development.

I think the problem that using Agile ran into in the marketing department is obvious. Just adopting a few features of Agile isn’t going to accomplish much. XP isn’t just about project management; it’s also about Pair Programming, Test-Driven Development, Minimal Marketable Features, Face-to-Face Communication, Rigorous Preparation, Responding to Change, Customer Collaboration, and much more. Agile works best when you adopt most of these Agile practices.

Hitting the Mark

Despite these missteps, every Fishbowl leader saw the potential of the Agile Prime Directive and most of them implemented it in their departments.

Fishbowl has one of the greatest customer service departments in the industry. In the early days of our transition to XP, customer service picked up a few ideas that they liked. The first is a cross-functional team and a concept we called paired leadership. For us, paired leadership was an important discovery. As its name implies, its fundamental principle is to have two divergent leaders focusing on different areas of a team’s success. In development, each team is led by a technical lead and a customer lead. The technical lead focuses on the technological sophistication and execution of the code production. The customer lead focuses on the direction and value being produced.

Porting this to our support teams worked well. Our support teams are led by a similar technical/customer dichotomy. One lead is an expert in the product and the other focuses on consultative sales. Each of the support teams consists of a handful of trainers and technicians. To accommodate these 5-to-6-man teams, we built custom workspaces to collocate each team. Each team is an autonomous cell assigned to a limited number of customers. Their primary focus is maintaining happy customers by providing value-added services.

A key to their success is this notion of a highly autonomous, cross-functional, collocated team. You will not hear scripted answers coming from our support department. Each team follows guiding principles but handles each customer’s situation with unique expertise.

The X Factor

We called our Agile experiment with the sales department the X team. The X team was an idea we had to create the perfect cross-functional Agile team. We collected some of the best performers from each department and put them into one huge office together. This office was separate from the rest of the company. The X team included a sales representative, a few technical support guys, a product owner, and a handful of developers. It was like we were creating a tiny startup within our company.

Their task was to recreate one of our failed products from scratch. We knew the product concept was solid and we knew with the right talent and dedication we could learn a lot from this experiment. This turned out to be very interesting. We wanted to get direction for the product directly from our sales representative and feedback about the functionality of the product directly from the support technicians. We also wanted to be able to disseminate information immediately to provide great customer service.

For the most part this experiment was a success. The product created during this experiment ended up becoming a great revenue producer. The customer service provided by the team was stellar. In the end, homesickness pulled sales representative back to the sales team. Without him, a big part of the value proposition to development was removed and so the X team soon dissolved. We continue to look back on that experiment and talk about the valuable lessons we learned.

Agile Terms

The word “Agile” gets thrown around in the software development world so much that it is hard to know what it really means. We have learned that Agile in its purest form isn’t a one-size-fits-all proposition. For development departments of fewer than  50, my advice is to become experts in your favorite form of Agile. Buy a book, and follow it to the letter for the first four years. For sales, support, and marketing departments, don’t expect Agile to fit your needs precisely. Spend time identifying high-value tasks. See if there are principles that will help you deliver these tasks and experiment

Here are the principles that we found port well to all departments.

Paired Leadership – We found that paired leadership has some great advantages. First off, it provides inherent checks and balances. Second, two leaders with vastly different skills who learn to work well together are much better problem solvers. Two leaders can listen twice as much. With two leaders there’s a greater chance their employees can build a relationship with at least one of them, thus increasing the flow of creative ideas to the top of the company.

Collocated Workspaces – By having people share workspaces, communication barriers are cut down. Management becomes a less-mechanical process. Face-to-face communication gets faster and clearer. People can learn by their peers’ examples. Social pressures and dynamics can be leveraged to provide productivity.

Autonomous Teams – Each team should contain the decision-making power they need to accomplish all of their tasks. Eliminating bureaucracy from a team gives them the ability to quickly solve problems. Autonomy builds intrinsic motivators for success.

Cross-Functional Teams – Teams should have a diverse skill set that includes your best technical folks, communicators, hard workers, and strong leaders. They should sit together. Encourage them to build strong friendships, buy them lunch every week. The more they like each other, the better they will work together to solve customers’ problems.

Customer Collaboration – Every team should have a singular focus on customer collaboration. Serving customers is the goal of every worker. Eliminate tasks that are not focused on solving customers’ problems. Build customer-centric solutions. Eliminate all types of scripts, approval processes, documentation, and busy work.

Share
This entry was posted in fishbowl software and tagged , , , , , , . Bookmark the permalink.

Leave a Reply

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

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>