Talks
Herding Tigers - Software Development and the Art of War
Summarized using AI
Herding Tigers - Software Development and the Art of War
by Danny BlitzThe video titled "Herding Tigers - Software Development and the Art of War" features a presentation by Danny Blitz, delivered at the Mountain West Ruby Conference in 2009. The central theme explores agility in software development and its parallels with military strategy, emphasizing the importance of adaptable team structures, such as 'tiger teams.'
Key points discussed in the presentation include:
- Agility in Software Development: Blitz advocates for admitting uncertainties and adapting processes to changes in business needs and technology.
- Tiger Teams Definition: He defines tiger teams as small, self-improving software groups that prioritize velocity and quality, employing a co-ownership model of work.
- Case Studies of Success: Blitz shares examples from his time at AT&T, where a project initially estimated at five weeks was completed in just seven days by a tiger team, demonstrating the potential impact of agile methodologies.
- Importance of QA: He stresses the role of quality assurance (QA) from the project’s inception, ensuring that QA experts contribute to requirement gathering and automated testing early in the process.
- Leadership and Autonomy: The presentation highlights the importance of leadership within teams, encouraging team members to take initiative while maintaining autonomy to foster creativity and rapid problem-solving.
- Reduction of Meetings: Blitz emphasizes minimizing meetings to maximize productive programming time, characterizing meetings as a significant time drain.
- Shared Psychology of Winning: He discusses the development of a group mentality that fosters confidence and encourages team members to embrace mistakes as learning opportunities.
- Maneuver Warfare Analogy: Blitz draws analogies between business strategies and military tactics, comparing successful agile companies to maneuver warfare strategies, advocating for rapid adaptability and speed in product development.
- Mistake-Friendly Environment: He promotes a culture where team members are encouraged to learn from failures rather than fear them, advocating for open communication and trust among team members.
The takeaway from the presentation is that agile is not merely a set of practices but a mindset focused on adaptability and a relentless drive for improvement. Blitz encourages viewers to embrace true agility by discarding the superficial applications of agile terminology and fostering an environment where teams can thrive through collaboration and innovative thinking.
00:00:12.639
Okay, well as you can see, my presentation is not particularly technical. I'm going to talk about agility and the lack thereof, how to achieve it, how we’re doing it at the company I'm at now, and how to build a tiger team. I will also discuss how it relates to warfare. First thing I want to say is blame Jim Wrick, please. He saw my first dry version of this presentation and pronounced it very dry and not very cool, so hopefully, I'm not going to give you too much of a jolt here.
00:00:35.840
But okay, I want to give you a warning here; I have some opinions ahead. I usually give this talk to upper-level folks, like C-level executives, to explain to them how it works. This quote is from a military book that is one of the best I've ever read, and it states, "Without concern, this is all worthless." That's absolutely true. It’s from 'The Passion of Command' by Colonel BP McCoy. I read a lot of military books to study how to build and run my tiger teams.
00:01:10.640
Let’s see, you want answers? I think I'm entitled to say, 'You want answers. I want the truth.' You can't handle the truth! I think you can handle the truth; that’s why I'm talking to you. So this is who I am: I have over 20 years of experience in systems building and management. I’m a manager. I’ve built military systems, banking systems, medical systems, and a lot of entertainment systems. You know, the way I look, I get hired for doing that sort of thing. I'm currently a software manager for AT&T Interactive. My boss Kobe is sitting up here, dressed like me—he’s a great big Viking guy in a motorcycle jacket.
00:01:48.360
So, hurting cats is a common description we use when we talk about organizing the chaos of software development. I’m going to show you what you guys looked like to me when I first showed up. That’s the baleful stare of a programmer who doesn’t want to be told what to do. Well, now that looks pretty harsh, doesn't it? But I have to tell you, I had to herd drunk cats. I had a band on the road, so this was my life.
00:02:30.160
So, enough of that. This is actually a poster from the wall of the whiskey. I’m going to shoot through real quick some of the junk I did while I was building systems. Then I got sick, so I stopped playing guitar. During that time, I had written songs for the Osbournes, dealt with Sony Television, and did songs for Dawson's Creek. E! Television shot a segment on me called 'Hollywood Rocks.' Budweiser was our sponsor, which was actually kind of dangerous for me. I signed my deal with Miramax while I was in the hospital.
00:02:54.399
Actually, I had a tech career running alongside that, so I was able to keep working. I built systems for the Department of Defense, and I lived in Washington, DC. I built City Bank's online banking system and their branch of the future. I was featured in 'Time' magazine in 1998 for that. I ran the last build to Ticketmaster. Dell hired me to write their online HR system, which was the first large system I built before I stopped programming altogether. Cisco had me build their International consultant site. I was the software director for Quest Diagnostics and was on one of the grand DARPA teams that built one of the robots you see driving themselves in the desert.
00:03:42.640
And of course, my very last gig before I went to where I am now was at CBS Radio, a big net system that I'm sure makes you all very excited. Yay! Boo! So now I serve AT&T Interactive, where they’re tolerating me very well. I must say thanks to my boss Kobe up here for putting up with me and letting me build my little tiger teams.
00:04:05.960
This is one of the best quotes about agility from General Patton: 'A good plan violently executed now is better than a perfect plan next week.' He was a man on the move, and I think we would probably agree that this is true. I don’t know if you would or not, but I think it's true. Let's not trivialize what we do when we talk about putting a whole system together. Software development is hard. So why is it so difficult?
00:04:41.680
I think it's because people don’t want to admit or accept the truth. Why won’t we admit the truth? Well, because we’re afraid. When that CIO or CEO is looking at us, we’re afraid. We don’t want to tell him the truth. What are we afraid of? We don’t know many things about the end result. That’s why agility is uncomfortable because we’re basically saying we’re going to figure it out as we go along.
00:05:11.360
So, why don’t we know what the end result will be? I’ll tell you why: It’s because business needs change, new competitors emerge, and technology tools change violently. You guys are a great example; I’ve been sitting here getting my head spun listening to you talk about the things you’re building. The technology tools are changing radically, and new product visions appear. You might hire someone new who has a great idea for a new Myspace, and he’s going to make you a billion dollars, so now you need to build a new system.
00:05:42.679
How should we deal with this? I say we admit the truth and build our process around these issues. So what is a tiger team? A tiger team is a small, self-improving software team with velocity and quality as primary drivers. I expect them to produce an enormous amount of product in a very short time frame with very low or no defects.
00:06:15.360
How do we do this? Well, first of all, let’s talk about what can we expect. We actually did this with one team at AT&T. We had a project that was slated for five weeks, and we finished it in seven days. The next project was roughly equal to the first, and we completed it in three days. We were accelerating because we were growing our process; the programmers themselves were essentially growing the process while I stayed out of their way. It was true agility: we were talking directly to the product people, and it was just super fast.
00:06:51.960
So what’s different about tigers? One thing is that tigers are a team. It’s not like four separate programmers working; they co-own all the stuff. They pick up the work and do continuous redistribution. There’s all sorts of things we do: retrospect, we use the buddy system—no more flying solo. You need somebody watching your back at all times.
00:07:14.520
This photograph, I want to say, is a remarkable moment I captured during a tiger team meeting. This was a one-minute long session, and I just walked up and snapped it without staging at all. It’s notable for who’s in it: there are two programmers on the left and two QA people on the right. We work very closely with QA all the time. We get along well, and we actually consider them part of our team; the QA people are tigers themselves.
00:07:37.320
What else is different? Well, tigers show leadership, and that’s something I insist upon. I look for leadership within the group; I give people room to move up if they want to take a leadership position. I encourage them to do so. I give them lots of autonomy to run. This mild-looking woman here is JIA, the leader of Team Lightning, our first tiger team. We started building more teams, and I couldn’t run them all, so we handed off the leadership to J.
00:08:08.160
J and I still work very closely together because she’s quite different from me. I’m sort of like a Berserker; I just go, and she’s very calm, calculated, thorough—and she wants to read all the requirements and write a plan. Those are things I don’t have the patience for, so we balance each other well.
00:08:54.600
Tigers self-improve, which is something I insist on strongly. Not only are you going to write the system and code, but you’re also going to get better at executing. I expect this to happen every single day—you're going to make some small improvement in the way you're doing things, whether it's pairing, using a new tool, or testing in a new way. Every day, you’ll do this. If you can improve 1% a day over one year, think about that—it’s not just 365%; it’s thousands of percent.
00:09:36.520
Ultimately, you're moving at the speed of thought. The bat phone rings, and you just respond quickly. Our systems get cranked out very quickly, and we focus on self-improvement. What else makes us different? We have almost no meetings; that was the first thing I did was stop the disease of meetings. We’re a big company where everyone wants to meet and talk and talk. If you get five people in a room for two hours, you’ve just wasted ten man-hours; that's a significant amount of programming time.
00:10:17.520
I just stop them. No more meetings. You can’t meet with my tiger team; they’re going to be isolated, and they’re going to do what they want to do. If you ask for a meeting with my teams, this is the look you’re going to get. What? You want to have a meeting? So what else is different about tigers? QA and test automation are the tip of the spear; this is very important. If I have my way, I have the QA person on the project from the very beginning.
00:10:52.680
Literally, from the first time the product person speaks to us, I want that QA person listening to what they have to say. The programmers are going to listen, thinking about how they can build this, while the QA person, who has a devious mind, is thinking about how to break it. So they're going to ask different questions, leading to much better requirement solicitation. The test automation engineer starts right away when the coding begins; they write a big suite of test code alongside the product code.
00:11:23.080
So if we need to rip out a feature, we can just rip it out, run our automation suite against it, and know if we broke something fundamental. What else is different? We have a shared psychology and intelligence in these groups. They actually grow this over a short period. It's a psychology of winning; they expect to win. Boldness is evident in the group, and they’re not afraid of much—excellence pushes one another. This is something that shocked me... these programmers started to really push each other.
00:11:49.120
Even my speed demons were concerned about the number of commits they were seeing, and they felt like they were falling behind. They aren't afraid of the dark; what I mean by that is we’ll start knowing almost nothing. The waterfall method makes sense because you want to know what you're going to build before you actually build it. However, we know our clients often have no clue what they really want when they first start; they have a vague notion of wanting something cool or blue, or whatever that is.
00:12:27.600
And so we listen to them, and we start knowing very little. We embrace starting in the dark, and when you think about it, if you look like this [referring to a tiger], would you be afraid of the dark? I don't think you would be. Part of the reason I call my teams 'Tigers' is to instill a fierce mentality. So who is on a tiger team? The short answer is that all the staff needed to deliver a product must be part of this team.
00:13:00.000
I have not won this battle yet at our company. Ultimately, I need DBAs, CIS admins, and one of each essentially to get everything done from Soup to Nuts. The product person comes and talks to me or the team, and we just bang it out—it's done. Currently, we have a tiger leader, typically four developers, which is an ideal number because we do a lot of pairing in real-time.
00:13:29.720
I don’t demand it; I don’t micromanage that way. If they want to pair, they can, or if they encounter a serious problem, they can quad or swarm. I’ve seen all four gather on one computer and solve a problem that might take someone half a day in just a minute. Not only do they solve the problem and escape the negative loop of frustration, but they also teach others how to do it.
00:14:06.000
The group actually starts to get smarter and smarter—that's what I mean by shared intelligence. Also, it’s often part-time. You may have an architecture person; we have an architecture department, which I’ve been a member of until recently. The CIS admins, DBAs, UI folks, graphic designers, and so on—everyone is essential. I also find it is critical to have a product staff member because I want that person in the room, preferably assigned to me.
00:14:45.680
When I ask them questions, I’d like to get an answer right then and there because that way we can just zip right through it. War Room development is my preference, in my opinion. I think having everyone sitting together works best. So why do I talk about warfare in this context? Business is battle, and our marketplace is the battlefield. Battle is typically subdivided into attrition and maneuver.
00:15:22.040
There is a third kind of battle that I'll mention. If you study with my eight-week program you'll learn about a self-defense system I developed over two seasons of fighting in the Octagon, called 'Rex Quando.' I won’t actually go into detail here, but attrition and maneuver are the two primary battle methods we typically discuss. In real attrition warfare, traditional tactics involve two big armies clashing head-on.
00:15:40.960
Companies do this as well; it’s like one big company grinding down another. Companies that engage in attrition warfare include Tower Records, GM, Ford, and I understand Home Depot is currently struggling with its position in the market. I don’t think attrition warfare is useless; in fact, I believe it’s very useful. You have to hold ground even in the market.
00:16:28.320
To illustrate my point, I’d like to mention a great American, President Dwight Eisenhower, who was a General. He and Patton were two types of leaders; Patton was a maneuver warrior. Patton took a more dynamic approach during battle, while Eisenhower's approach was more about grinding through attrition.
00:16:55.680
Maneuver warfare, on the other hand, is rapid, modern, and violent, characterized by unexpected movements. This reflects the current internet space; you simply don’t see what's coming. Companies adept at this style include Apple, eBay, and Facebook.
00:17:35.440
The US Marines are full of maneuver warriors. I walked into a Marines Officer recruiting station one day and they weren't too happy to see me. Ironically, the two great leaders I’ll mention were not Marines. Patton was not a Marine, which highlights the difference between maneuver and attrition warfare.
00:18:11.000
When the Allies hit the beaches of Normandy, they were grinding against the German army, taking half an acre a day; tens of thousands of men were dying in that attritional approach. Patton, however, took a different approach; he looped around them and entered Germany from an unexpected direction. This shocking approach terrified the Germans.
00:18:52.240
General Sherman in the Civil War took a similar stance—he decided not to engage the Confederate Army directly. Instead, he aimed to disrupt the institutions supporting them. He was known for his bold tactics, and even though I grew up in the South and was initially taught to dislike him, I’ve come to recognize that his methods saved many lives.
00:19:34.200
So let’s talk about business maneuver warfare. The landscape of modern business requires companies to be adaptable, just as in warfare. This is exemplified by eBay’s emergence from obscurity into a giant marketplace.
00:20:17.120
So I will finish by stating that speed itself is a competitive weapon. The military acknowledges this, and the same applies to business. The first to market holds a huge advantage. General Forrest famously said, 'Get their firstest with the mostest.' This is an ironic quip, as he was known for his eccentric battle tactics.
00:20:53.920
I hear the phrase 'speed kills' all the time, but it's not true. Speed actually mitigates risk. Yes, we will have bugs. We're going to blow it up a few times; I’ll just raise my hand and admit it. But think about this: fast teams have fast recovery cycles, and when they make a mistake, they can fix it quickly.
00:21:27.599
Additionally, speed enhances the team's ability, allowing more time for process improvement and developing shared psychology and intelligence. The end result is increased job satisfaction; when I started these tiger teams, everything moved faster, and I must admit, working slowly made me wish for a way out.
00:22:00.000
Speed allows agility to function effectively; it’s akin to an engine that requires a minimum rotational speed to function. Most agile methods refer to a minimum iteration length, typically 30 days. If you extend your iteration to 90 days, you're not practicing agility—you're doing something else.
00:22:32.400
On that note, if you ever see a souped-up car with outrageous power, it serves as a reminder to the importance of speed. Speed builds credibility within a large company.
00:23:10.080
Our product staff witnesses the work we churn out; it all happens so quickly that they can witness tangible results. It reduces the frustrations felt amongst non-technical staff who suspect we are stalling. Our aim is clear: we want to build what the company needs, and that requires swift action.
00:23:50.600
Cows are much bigger than tigers, and they seem to dominate at first, but let’s not forget: in the wild, agility and ferocity can prevail over size. I see frequent misuse of agile terminology in non-agile processes. For instance, people will label lengthy meetings as scrums, leading to false perceptions of agility. The truth is, if you’re just using the words without embodying the principles, you’re not agile.
00:24:27.960
Leadership is crucial for the success of tiger teams. I prioritize studying effective leadership because of its importance to successful teams. Faith and love are integral, as they establish mutual trust. When I go home at night, I sleep soundly, knowing the work gets done.
00:25:08.400
Hope also plays a vital role. Many have experienced working at companies without hope, and it's a brutal environment. When we’re successful, the credit belongs to the team. If we fail, it’s on me. It's a strategy to reduce fear, and this empowers my teams to perform effectively without fear of blame.
00:25:46.840
I implement a no-finger-pointing policy because accountability is crucial in my teams. If I see finger pointing, I intervene. Having the courage to embrace failure is essential; I expect mistakes when trying to innovate.
00:26:15.920
Make a mistake-friendly environment where no one feels they will be singled out for failure. I encourage team members to question things and express their thoughts and ideas. I protect my team from outside influences, particularly pointless meetings or negative attitudes that can derail our progress.
00:26:55.360
To summarize, agile is not just a methodology; rather, it’s a mindset of flexibility. It should signal a willingness to adapt and innovate. Even in large organizations, there’s often a struggle to implement agile processes effectively.
00:27:35.760
If you're interested in learning more, I've written a manual and am currently drafting a full-length book on this subject. This is available through my company, and you can reach me at herdingtigers.com if you want to talk further or challenge my ideas. I welcome any questions you may have.
00:28:07.360
Are you all pinned back into your seats? Rewarding failure has been crucial; I believe it encourages innovation. I generally don’t give monetary rewards but prefer to circulate a positive atmosphere. If someone does well, we celebrate together.
00:28:37.360
From the perspective of a junior developer, how do you promote this type of agility? I’m speaking directly to you all; you are intelligent and proactive. Talk about real agility and call out when things are done poorly. The goal is to move towards truly agile processes.
00:29:03.560
Thank you all. I hope this has sparked some ideas for you. Let's continue the conversation about how we can embrace agility and improve our teams.
Explore all talks recorded at MountainWest RubyConf 2009
+3