Looking back over who-knows-how-many “agile transformation” and “agile coaching” engagements, it occurs to me that five experiences stand out as especially positive.
When I ask myself why, two elements present themselves: First, (in three cases) the development team was physically collocated with the end users and collaborated directly with them daily; and second, (in the other two cases) the team and the organization did not “lock in” any rigid definition of “agile,” and actively explored ways to move beyond the usual Agile 101 level of practice.
These characteristics seem to be extremely rare in the “agile” world. Usually, that’s due to perfectly understandable and practical reasons. But often, teams could do far more than they ever attempt to do. They seem content to memorize a few rules and follow them by rote.
I might observe that most agile coaches introduce Scrum to a group of people who have never worked in an agile way before, and then move on to their next engagement, where they introduce Scrum to another group of people who have never worked that way before, and so on.
They repeatedly set up “Scrum 101” for client after client, year after year. They have never seen (imagined?) anything beyond that. Many have never seen a Scrum team that has been in operation for more than a few months; they don’t stick with the same team long enough to experience “zombie Scrum,” or conversely to see a team outgrow the need for the Scrum “rules.”
In large transformation programs, a coach may work with a group of teams for 3 or 4 months and then move to another group of teams. Although they remain with the same client for a couple of years, they still don’t see progress beyond Scrum 101.
Most coaches I’ve met would never consider advising a team to question Scrum anyway. They don’t like the idea of “going beyond Scrum.” After all, Scrum is The Answer, isn’t it? If Cloud William were an agile coach, he might reply, “Scrum is our worship word. You will not speak it!”
But I digress.
Five previous engagements come to mind. Three had the characteristic that the development team set up shop in the end users’ work space and collaborated directly with them throughout the project. Two had the characteristic that teams did not stop at Scrum 101, but continually sought improvement wherever they could find it.
These days, we prefer to see teams organized around product lines or services, and we advise organizations to fund ongoing support for product lines and services rather than running discrete projects. But in four of these five cases, the discrete project model was still used.
In retrospect, these five situations were the most effective software development and delivery experiences of my career. You might not consider them the “most agile,” but they were definitely the most effective. As I type this, it strikes me that of these five, exactly zero were focused on Scrum as such. All these examples are US-based corporations.
Case 1: Mid-sized bank
At the time (2001-2006), the bank had about 33,000 employees, with about 1,300 in the IT department. There was immense frustration from the “business side of the house” at the cost, quality, and unpredictability of the results they got from the IT department, which was heavily bureaucratic and sluggish.
A small group of us became interested in learning how things really happened in the IT department, and how we might be able to improve outcomes. Midway through that effort one of us stumbled across the Agile Manifesto, and we thought it captured the essense of the values we were interested in applying at the bank.
Long story short, after getting some help from a company that knew how to do things in this way (ThoughtWorks), we organized our development teams into small squads. We used Extreme Programming (XP). The agile team members had no offices or cubicles. We were issued identical laptops, and for each project we were issued an external hard drive to use as our local storage for that project. We had some limited ability to procure hardware and software without going through the traditional bureaucratic channels.
We served internal business units rather than external bank customers. Each team set up shop in the physical work space of the business unit for which we were doing a project. That might be on a floor of the executive office tower downtown, in a back-office work space in one of those industrial parks where there are no signs on the buildings and no public entrances, or occasionally even in the company’s technology center, where the standard IT work took place.
Every project we carried out delivered good results. I attribute that mainly to the fact we were in the middle of the users’ world and they watched everything we did, providing immediate feedback in the real-world context of their business operations. No other system I’ve seen or heard of provides that level of seamless collaboration between the makers and the users of software.
That was my first exposure to “agile” development, and it remains one of the most effective and positive experiences I’ve had with the approach.
Case 2: Insurance company
This was at a large insurance company based in Ohio that specialized in car insurance, in the time frame of around 2012-2014. I’m not sure of the total size of the corporation. Our development team was physically collocated with the call center personnel and their internal developers, who occupied space on the same floor of the building as the call center. We mentored the internal development team while carrying out a project to replace the old call center system.
We had a test room set up right in between the floor space occupied by the call center and that occupied by the development group. Two pairs of workstations were set up in that room, manned by call center personnel. Each pair comprised one of the existing workstations and one of the new ones.
With team members in the room watching, taking notes, and sometimes making code changes on the spot during live calls, the service representatives took real calls from real external customers. They did the work on both the new and old workstations, and we immediately saw anything that made that work difficult on the new system, and incorporated the lessons learned into the new solution.
Case 3: Large bank
This example predates the “agile” period, but when thinking about positive experiences it came to mind. This was a bank with a national footprint in the US in the 1980s. It was rigidly organized, and people were expressly forbidden to cross administrative boundaries or to go around the “chain of command.”
Between the development team and the internal customer group stood a functional silo for “business analysis.” The analysts were officially the sole means of communication between the customers and the development team. Ostensibly, they understood both the business domain and the technology well enough to serve as a bridge between the business people and the technical people, who were believed to be incapable of understanding each other.
The flaw in that setup was that the business analysts understood neither the business domain nor the technology. And why would they? They had no experience in banking and no experience in software, and they were paid far less than anyone else involved.
After a time of frustration for the customers and the development team, a couple of us walked across the street to the building where the customers were located, and asked them if we could park in their offices for a while. Soon, the development team was working in the users’ offices side-by-side with them. From that point forward, the project went very well. No one told management that we were in direct contact with the users, which would have been a firable offense.
Case 4: Continual improvement
This was at a company that had a few thousand employees located in different places around the US, and as memory serves it took place sometime in the 2010s. They were in the business of collecting information about the service histories of vehicles, which they then sold to car dealers and people who were shopping for vehicles.
One team supported five business managers. They handled an assortment of requests from these managers with no particular prioritization and no clear sense of which items might be more important than others. The work was scheduled by the “squeakiest wheel” method; the manager who made the most noise got their work done first.
The team’s manager was keen to try an “agile” approach, and was good at giving the team a lot of leeway to self-organize without letting them fall off the cliff. That was a critical success factor.
I got the team organized as an XP team and they started working with that method. At the same time, I worked with their five stakeholders to nail down some kind of prioritization of the work. Fortunately, the corporation had an annual business plan. It was straightforward to map items in the business plan with each manager’s area of responsibility. Priorities fell out naturally from there. No more squeaky wheels.
Meanwhile, the team took the idea of retrospectives and continual improvement to heart. They started with two week iterations, and before six months had passed they were operating a single-piece pull system with no fixed iterations, and were able to keep up with stakeholder requests efficiently enough to have Friday afternoons free for professional development.
They had also incrementally re-architected their application, from a “spaghetti” ColdFusion application to a ColdFusion model-view-controller application, well-covered by automated test suites at multiple levels. They did this refactoring without interrupting normal service to their stakeholders.
This team is one of the reasons I tend not to accept people’s claims that they “don’t have time” to refactor or that incremental refactoring is “impossible,” and why I tell developers they don’t need “permission” to refactor or to write executable test cases, because that work folds neatly into development work without causing any hiccups. It isn’t a guess or a wish; I’ve seen it and done it, and the outcome is better than when we don’t do it. Fact.
Agile practitioners often say we should question everything. This team actually did so. When they had reached the point that two-week iterations were too long for them, they switched to one-week iterations. When they reached the point that iterations as such were no longer helping them, they questioned the value of the iterations. They did this at the appropriate times and for the right reasons with no prompting from me. They were fully in the swing of “agile” thinking and action.
By the end of six months, the team didn’t really need any sort of formally-defined process with buzzwords and rules. They were “just doing it.” Best team I’ve ever coached, bar none.
Case 5: Beyond Tuckman
The previous example was a single team. I also had the privilege of working with an entire development organization that went well beyond Agile 101. That organization is the reason I generally don’t buy Bruce Tuckman’s model of forming, storming, norming, and performing.
This was not a large company. They had two software products that served the education industry. There was a total of about 70 people involved with building and supporting those products. They had two locations, with the developers and testers collocated in large rooms in each location. One location had more people than the other.
The two offices maintained continuous video and audio connections with giant TV screens against one wall, and had workstations set up in a way that enabled remote pair programming between the two sites. The setup made it feel as if everyone were in the same room. One day there was a power outage and the TV screens went blank. It was so natural for us to be connected that it felt as if half the building had been cut off.
The development group was not organized into “stable” teams. They formed up into small groups, often as few as two people, around the work to be done. Every Wednesday afternoon was “demo time.” Anyone who had something to show could demonstrate it at that time. The whole group attended.
As demand for work came in, it was prioritized and loosely prepared. Members of the development group picked the items they wanted to work on – of course there were times when a person had to work on what was left over, but they could get first pick next time. Interaction and collaboration across this entire group was seamless and stressless.
There was no need here for fixed team memberships or any sort of planning overhead such as we see with agile scaling frameworks. Everything happened in the most “agile” way you could wish for.
They didn’t reach that stage of maturity in a single step. It took time for them to identify and explore improvement opportunities after beginning with a general, beginner-level “agile” structure, based mainly on Extreme Programming. The key thing is they didn’t stop with Agile 101.
This organization is one of the main reasons I don’t buy traditional managers’ fears that there is no personal accountability with “agile.” Every member of this group felt personally responsible for their customers’ experience and for the value of their product. That didn’t have to be forced by management; it was a natural consequence of the way the group was organized, and the “ownership” they felt for the whole thing.
Besides that, this organization was supporting a product and not running discrete projects, long before most of the industry realized that discrete projects were not the best way to run the show.
Conclusion: Up side and down side
The up side in these stories is they demonstrate the effectiveness of several of the key ideas in the “agile” way of thinking. The fact the vast majority of attempts to adopt “agile” haven’t worked well is frustrating for many of us, as we know it would work well if only people would just do it.
The down side is that none of these examples was permanent. Of course, the 1980s example couldn’t have become permanent, as it was entirely unofficial. We would have been fired on the spot had management discovered we were collaborating directly with users.
But the other four could have become the normal way of working in those companies. Instead, the agile experiments were relatively short-lived, and the organizations reverted to the status quo ante as soon as key people, who had been sustaining the agile way of working, left the companies, and traditionally-minded managers took over the operations.
The track record of the agile movement to date doesn’t suggest large organizations, particularly those in the Late Adopter and Laggard groups with respect to agile adoption, stand much chance of transforming themselves in a meaningful or sustainable way. But agile thinking can certainly help smaller organizations achieve good results, especially those with a culture that is predisposed to experimentation and innovation, and where transparency and honesty are not politically or psychologically risky.
It can also play a positive role at small scale within larger enterprises, if agile groups are allowed to self-organize within appropriate organizational limits. Problems begin when the larger organization attempts to standardize agile across the board. At that point, it becomes just another bureaucratic mandate, and the value is lost.