- Scaling hurts. Keep things as small as possible.
- Agile is a means, not a goal. Don’t go Agile Jihad. Don’t dump old practices that work.
- There is no “right” or “wrong” way. Just tradeoffs.
- There is no one-size-fits-all. But plenty of good practices.
- Build feedback loops at all levels. Gives you better products and a self-improving organization.
Here is an InfoQ article with a nice summary of the keynote.
Agile product development has become the norm in many industries (especially software). That means products are developed by small, self-organizing, cross-functional teams, and delivered in small increments and continuously improved based on real customer feedback. Pretty much as described in the Agile Manifesto – but replace the word “software” with “product” (because it really isn’t software-specific).
That’s all fine and dandy. However when things get bigger, with dozens of teams collaborating over organizational boundaries, things obviously get more complex and painful. Even if the entire organization is neatly organized into scrum teams, you can still end up with an unaligned mess! Here’s a picture that might feel familiar:
Before trying to “manage” this complexity, ask yourself “does it really need to be this big and complicated?”. Perhaps you are trying to build the whole elephant in one go. Perhaps your teams are organized by function, creating lots of dependencies. Perhaps your architecture is too rigid, too fragile, or too coupled.
So start by trying to simplify things. Some wise person said “Don’t scale agile – descale your org”. Maybe you can re-org into one or two teams with just the right mix of skills, all co-located and 100% focused and with direct customer contact. They may well be able to build the same product (or better) in half the time and for half the cost! Don’t fall into the mental trap of believing that more people = better. More people might be better in some cases, but the only thing you can be certain about is that more people = more cost and more complexity. The potential benefits are, well, only potential benefits.
But OK. Sometimes you really do need to get a whole bunch of teams and departments and vendors to collaborate on something big and complex. Let’s just say that’s the case. I’ll be nice and give you the benefit of the doubt.
If so, you most likely need a leader! Someone to focus entirely on coordinating the different teams, keeping the moving parts in sync, and keeping an eye on the big picture. And that’s what this article is about.
Agile relies on self-organization, which is super-effective (when done right). But with more than a handful of teams, self-organization sometimes needs a helping hand – someone to create and maintain the environment that enables self-organization in the first place – things like a clear goal, a short feedback loop, effective communication channels, etc. Essentially, make “1 + 1 = 3” (because of synergies) instead of “1 + 1 = 1.5” (because of misalignment).
Let’s call it the Agile Leader. And the main job is to create alignment!
At the team level agile methods already include leadership roles such as Product Owner and Scrum Master. But at a multiteam-level there is no formal leader role defined. That’s because smaller efforts usually don’t need a single appointed leader – the success of Scrum has shown us that effective leadership can happen without a single appointed leader. However, the more people involved, the more likely you are to need a dedicated leader, a full-time person who focuses on just that – regardless of whether you call your multi-team effort a “project”, a “program”, a “bet”, a “product” or whatever.
The leader doesn’t necessarily need to be one person, it can be a pair, or a small tight-knit team – as long as they collaborate tightly and speak with one voice. For the purpose of this article i’ll assume it is one person.
Example: At Spotify, most medium-to-large initiatives are led by a “TPD trio” – a small leadership team consisting of one person from Tech, one from Product, and one from Design. That way we make sure all three perspectives are always taken into account. However, for large efforts that span far beyond just tech and product and design, the trio isn’t enough. Should the trio be expanded, or should we have an additional leader role? And what should we call such a role? We’re still experimenting with that.
Think of the label “Agile Leader” as a placeholder for whatever you decide to call the role. If depends a bit on how you organize your work. Pick whatever title fits your context – Chief Engineer, Chief Product Owner, Project Manager (if it is a project), Program Manager, Uber Scrum Master, Release Train Engineer, Chaos Pilot, Road Manager, Zen Master, Coordinator, Driver, Project Coach, Catalyst, or whatever. Whatever you call it, it is critical function and it needs to be there for any complex cross-functional endeavor that involves more than a handful of teams. The person(s) in that role need to be motivated, dedicated, and skilled.
I intentionally call it Agile Leader in this article. The word “Agile” is there to emphasize that this article is about an agile product development context, which is very different from a waterfall context. I use the term “Leader” instead of Manager because, well, in a well-running agile organization most “management” is handled by the teams themselves. So the primary purpose of the role is to provide leadership, not management. But the distinction isn’t binary, of course.
The purpose of this article is to paint a picture of what a great Agile Leader does, so you can more easily find, grow, or become this person – and help your multi-team efforts succeed better! This is not a formal definition of the role, just my take on it.
So, in short: try to minimize the need for big, complex, multiteam efforts. If you can’t then at least make sure you have an awesome Agile Leader!Isn’t this a Project Manager?
Maybe, but not necessarily. A “project” is just one of many ways to organize work, and often inappopriate for product development. However, If you do work in Project form, and the projects are fairly big and complex and involve synchronization among many different teams and organizations, then the Agile Leader is effectively an Agile Project Leader. I wrote a separate article called What is an Agile Project Leader, with some discussion about the project model in general. But for the actual role description that article links back to here. Don’t get stuck in a loop
Again, the choice of what to call the role is highly contextual. The purpose of this article is just clarify what type of leader you will need to execute it in an agile way.What does an Agile Leader do?
My Spotify colleague Babar provided a nice summary, using a sports analogy:
- What does winning look like? Vision/Mission.
- What’s the plan? Strategy and tactics.
- What’s the score? Progress, status, feedback loops
- What is preventing us from winning? Continous improvement, people, teams, strategy, tactics.
Do we all know why we are here, what winning looks like? Do we know the plan, the strategy? Do we have a way of seeing where we are now? Do we see the impediments, things that are slowing us down? Are we continuously trying to remove the impediments?
The answer is most likely “no” to some of these questions (otherwise, congrats, keep up the good work). So that’s the job of the Agile Leader – do whatever it takes to turn these into “yes”. That won’t guarantee success, but it will certainly increase the odds.
In a smaller efforts using Scrum, this work is covered by existing roles and bottom-up cross-team collaboration. With large efforts we face misalignment across teams, and things falling into cracks between different parts of the organization. So the Agile Leader focuses a lot on communication and creating clarity. If everyone involved has the same view of where we are, where we are going, and why, then we are more likely to work together to move in that direction.Uh, be more specific. What does the Agile Leader actually do?
So what does this mean in practice? What does an Agile Leader actually do?
I hate to say it, but…. it depends! There. I said it.
It depends on context, and what’s working well today and what’s not.
Keep asking yourself: “What needs to happen that’s not already happening? What can I do to cause this to happen, without becoming a bottleneck myself?”
Example: You notice that releasing is a pain, and that we need better release coordination between teams. Instead of running around trying to coordinate this yourself, you bring up the problem with some of the teams – check if they agree that it is a problem, and discuss how we might deal with it. Together you decide to set up a recurring meeting where people that have stuff to release sync with each other, and provide a shared living document where they can see and edit upcoming releases. Initially you facilitate the meetings yourself, but after a while they become self-managing. You encourage the teams to automate as much of release management as possible. Over time the recurring meeting isn’t needed, because the teams talk to each other directly and release coordination is no longer an issue.
Although I can’t tell you exactly what an Agile Leader should do, I will give a list of examples. Think of it as different “lenses” you may wear as leader. You might be doing some of these things yourself, but for the most part you should be creating a context where these things get done without your involvement.
NOTE: I use the term “ensure” below. Obviously a leader can’t force these things to happen, so in this context “ensure” = “do whatever you can to create a context where this happens”. In practice this may involve facilitating, encouraging, arguing, challenging, organizing meetings, creating documents, visualizing stuff, informal hallway conversations, etc.
So, here’s the list. Take a deep breath:
- Vision/mission. Ensure the the work being done has a clear purpose, clear hypotheses, clear boundaries/scope (“what are we NOT doing”), and clear success metrics based on business impact rather than deliveries. Ensure this is crystal clear to everyone involved, teams as well as customers and other stakeholders.
- Iterative and incremental delivery. Ensure that the work is split into sub-deliveries, to enable iterative and incremental delivery rather than big bang. Avoid large projects whenever possible, instead try to split the work into a series of smaller projects whenever feasible.
- Adaptive planning. Ensure that plans are created and communicated to everyone involved. Ensure the plans are adaptive rather than predictive, and updated as we learn. Ensure that deadlines are communicated and forecasts created as necessary, and updated based on empirical data as the work progresses. Make sure any constraints (date or scope) are clear to everyone.
- Feedback. Ensure a short feedback loop with tight and frequent communication between teams and customers. Collaborative planning, demos, etc. Ensure that hypotheses and assumptions are field-tested early and that learning happens continuously. Ensure that progress is measured based on actual deliveries and feedback and business impact, not by compliance to plan.
- Continuous improvement and knowledge sharing. Ensuring that learning and improvement happens continuously as the work progresses (not just at the end), and that key learnings are shared within the teams as well as across different parts of the organization.
- Focus and alignment. Ensure that participants are focused and dedicated (not multitasking), and aligned with the same list of priorities. Bash silos. Ensure that people are focusing on achieving the highest possible business impact with the lowest possible effort and output (working smart is more important than working hard).
- Impediment removal. Ensure that waste and impediments are visualized, prioritized, and systematically removed. Encourage teams to own and solve their own impediments whenever possible. Collaborate with other managers and take ownership of impediments that are escalated.
- Decision enablement. Ensure that decisions are made in a just-in-time manner and by the people who have the best insight into the matter, decentralized whenever possible. Ensure that nobody (including you) becomes a decision bottleneck. Minimize the number of decisions that have to be made by you.
- Visualize status and progress. Ensure that everyone can see the “big picture” – dashboards and such showing where we are going and why, where we are now, impediments, etc. Keep it at a high level, leave the details to the teams.
- Flow. Optimize for end-to-end flow of value, not resource utilization. Look for bottlenecks and queues, and apply systems thinking and lean principles to streamline the delivery of business value.
- Self-organization and autonomy. Make the goal and current situation clear so that people can think and act autonomously, with no need for you to tell them what to do. Ensure people are given problems to solve rather than tasks to execute. Harness the collective intelligence of the group, rather than trying to be a mastermind yourself.
- Staffing and capacity planning. Work with managers to ensure that the right people and teams are available at the right time to maximize the velocity and chance of success.
- Budgets and estimates. Ensure that any budget and contractual constraints are known and managed. Ensure that estimates are done by the team closest to the work at hand, kept at a high level, and adjusted when necessary. Ensure that estimates are treated as estimates, not promises. Make costs transparent.
- Dependencies. Ensure that cross-team and cross-company dependencies are visualized and managed effectively, and that teams aren’t blocked waiting for each other.
- Cross-functional collaboration. Use techniques such as co-location and cross-functional communication channels to reduce siloing and suboptimization.
- Communication. Create an environment that facilitates high bandwidth face-to-face communication and minimizes the need for unnecessary documents, emails, and other low-bandwidth communication. Documents should be used to support communication, not replace it.
- Fast failure. Create a context where small failures can happen early and often, thereby reducing the risk of a big failure at the end.
Special point: Motivation. Motivation is the key currency for any creative, complex endeavor – much more important than man-hours. Motivated people build better stuff faster. The difference can be quite mind boggling! But motivation is not a separate point – you can’t just “motivate people”. Instead, people will be intrinsically motivated by things like Autonomy, Mastery, and Purpose.
A good guiding principle is “Don’t motivate people – remove the demotivators”. If people see you removing real impediments and creating a high-trust environment that helps them work effectively – that will probably motivate them a lot more than things like hawaiian t-shirt fridays, free drinks, and ping-pong tables.Uh, that’s a loooong list! Where do I start?
Distill it into a shorter list for your context!
For example, get together with some folks, rate each item based on “how important is this for us” and “how well is this working today”. Then shorten the list to the top 5 things that are important and not working well today. Use that as a basis for finding a suitable Agile Leader (or for prioritizing your work, if you are the leader).What about accountability?
So is the Agile Leader a single point of accountability? Is this the single wringable neck in case of failure (for some definition of “failure”…)?
No, certainly not! Everyone involved is accountable. But people should be accountable for their behaviours, not results.
That may sound crazy at first glance, but think about it for a moment…
A product may fail to succeed despite all the best efforts of the team – it may fail for random reasons, it may fail because of acts outside of the team’s control. And vice versa, a product may succeed despite crappy efforts from the team and leaders, it may succeed because of blind luck or because there was no competition. This is complicated by the fact that failure and success is usually hard to define, with a big fat gray zone in between.
An Agile Leader should ensure that, when things fail, they fail early! She does that by building in a fast feedback loop (frequent delivery to customers, validated learning, etc). She ensures that we learn from the failure and use those learnings in the next product, or next iteration of this product.
If we punish failure, we incentivize people to hide failure, and thereby minimize learning. If we punish failure, we incentivize people to avoid all risk, and thereby kill innovation. Failure (and the associated learning), should be celebrated, not punished! To a limit, of course. Keep the feedback loop short, so failures aren’t fatal…
So although the Agile Leader may act as the “face” of this project/program/product/whatever to external stakeholders, she is not personally held accountable for success or failure. She is however, held accountable for behaving in a way that maximises the odds of success. And this applies to all participants, not just the Agile Leader.What kind of person is suitable for the role?
At the minimum, the Agile Leader needs to (in my opinion):
- Passionate about the product, customers, users, and business impact.
- Be excited about the Agile Leader role and willing to focus on it 100%
- Buy into most of the role description above, and want to grow in that direction.
- Have at least some real-life leadership experience (in any context)
- Have at least some real-life experience with agile ways of working (in any role)
- Be willing to get training/coaching/mentoring for the skills that are weak or missing
- Be willing spend time learning and continuously improving their skills as agile leader.
There is obviously no “perfect” Agile Leader, but below is a “Definition of Awesome”. I don’t expect anyone to fullfill all these points, but the more the better :o)
In a perfect world:
- You are business-minded and passionate about getting people aligned towards a common goal.
- You have experience managing large, cross-functional efforts (e.g. spanning functions such as engineering, marketing, content, legal, and others). Agile or not. Some of best leaders I’ve seen come from big failed projects – they know how not to run a project.
- You are flexible and pragmatic about methods and processes, and are able to use your judgment to apply the model and approach that fit best with the context.
- You have deep understanding and experience of agile and lean thinking, and some experience with concrete frameworks and techniques such as Scrum, Kanban, Lean Startup, and Continuous Delivery.
- You steer clear of waterfall projects, but you also understand that Agile doesn’t mean No Planning or No Architecture.
- You know how to provide strong leadership and guidance, without become a bottleneck.
- You know how to get people inspired and rallied around a higher purpose.
- You understand that people are people, not just resources, and that focus and motivation matter a lot more than man-hours.
- You understand that people are most motivated and effective when given a problem to solve, rather than a solution to implement.
- You know how to get people talking with each other across departments and other organizational borders. You aren’t scared off by politics.
- You know how to enable self-organization in large cross-functional efforts, and how pull-based scheduling works in practice.
- You know how to make the important stuff visible.
- You have a knack for spotting waste and calling it out.
- You understand that plans are important, but they are a tool and not a goal, and must be updated as you learn.
- You understand that uncertainty is a fact of life when innovating, and is best managed through a tight feedback loop rather than detailed upfront planning.
- You hold people accountable for their behaviour more than their results. You reward people for learning rather than punishing them for failing.
I hope this doc helps you improve the success rate of your large multi-team efforts. But don’t forget – scaling is a last resort. Scaling hurts no matter how you do it, so keep things as small as possible (but no smaller…).
Big thanks to Alistair Cockburn, Mary and Tom Poppendieck, Anders Haugeto, and a bunch of Spotifyers and Crispers who helped improve this article. I’m honoured to have such an awesome group of advisors!
Note that this my personal opinion, my take on what an Agile Leader is (or should be). Some people may disagree, that’s fine. I’m also happy for feedback, although I won’t always have bandwidth to respond.
Further reading (there’s infinite material on agile leadership, but here are some things that I happened to have read and liked):
- Becoming a Technical Leader (awesome timeless book by Jerry Weinberg)
- Management in Mayberry (best leadership article I’ve read)
- Lean-Agile leaders (from SAFe)
- Agile Manifesto (new to agile? start there, gives you the historical context)
- Declaration of Interdependence (a manifesto for project leaders)
- Agile Software Development – the cooperate game (in-depth book by Alistair Cockburn)
- Drive – the surprising truth about what motivates us (all leaders should see this video!)
- …. or just google “What is an Agile Leader” and you’ll find lots of interesting articles, mostly saying the same kind of stuff as here. Makes me wonder why I bother
I wrote this article because of two observations:
- Many organizations use a “project model” when they shouldn’t.
- There is a lot of confusion and debate in the agile community about projects and project leadership.
I don’t claim to have “the answer”, but I’ve thought about this a lot and also experimented on my clients (don’t tell them… sshhhh). So, here is my take on project leadership in an agile context.
Oh, and by the way, this article is a Bait & Switch. I’m trying to get you to read What is an Agile Leader. You might save time by just skipping this and going there right awayBeware of “projects”
The word “project” is controversial in agile circles. Some companies use the “project model” as some kind of universal approach to organizing work, even for product development. However, a surprising number of projects fail, some dramatically. I see more and more people (especially within the software industry) conclude that the project model itself is the culprit, that it’s kind of like rigging the game for failure.
A “project” is traditionally defined as a temporary effort with a temporary group of people and a fixed budget. Product development, on the contrary, is usually a long term effort that doesn’t “end” with the first release – successful products start iterating way before the first release, and keep iterating and releasing long after. And teams work best if kept together over the long term, not formed and disbanded with each new project. Also, the traditional approach to planning and funding projects often leads us to big-bang waterfall-style execution, and hence a huge risk of failure because of the long and slow feedback loop. The project model just doesn’t seem to fit for product development.
I’ve spent many years observing and helping companies improve the way they develop products, and the trend is very clear – less project focus, more product and team focus. Seems to work a lot better! So it’s no coincidence that “Projects” and the “Project Manager” role are absent in the most widely adopted agile frameworks such as Scrum, Kanban, XP, and SAFe.What about project management?
So what happens to project managers then? Aren’t they needed?
Wrong! Project Management hasn’t disappeared, it’s just been redistributed. The thing we are managing is a product, not a project, and management is too important to leave in the hands of a single person. In Scrum, for example, the project manager role was deliberately split into two separate roles – Product Owner (focusing on the product), and Scrum Master (focusing on the team), and the team manages itself rather than “being managed” by a PM. So most of “project management” still happens but in a different way – mostly decentralized.What about projects? Should we abandon that model entirely?
No, don’t abandon projects entirely, just shift the default. In particular for product development, projects should be the exception, not the norm. In a typical agile context (Scrum, XP, Kanban, Continuous Delivery, etc), the project model and project manager role is often redundant and will slow you down.
But wait – what if you’re going to do something that requires a coordinated effort across many teams from different parts of the company that don’t normally work together? What if you have lots of external and internal dependencies, content licensing, hardware procurement, external vendors, regulatory compliance, and offices in multiple time zones?
THAT might be worth treating as a “project” – especially if it is a temporary effort rather than something continuous. Basically, if the whole thing has a “definition of done” then maybe it’s a project.
However, regardless of whether you call it a “project” or not, if it’s big and complex you will need a leader. And if you want the work done in an agile way, you’ll need an Agile Leader (or Agile Project Leader if you prefer). Doesn’t much matter what you call the role, there just needs to be someone at the helm (or a pair, or a small team fulfilling the role).
- Myth: “But we’re agile and self-organizing, all these teams will magically coordinate with each other and stay aligned without a leader!”
- My experience: You’re probably kidding yourself. Or maybe you are a rare exception.
- Myth: “Project Leader means top-down micromanagement and big-bang waterfall processes.”
- My experience: Only if the project leader doesn’t get Agile. Get the right person for the job (this article will hopefully help!)
- Myth: “All projects have to be agile”
- My experience: Not necessarily. If the work is complex and innovative, then yes. If repetitive we’re-cranking-widgets-and-we’ve-done-this-dozens-of-times-before, then probably not. Most product development falls into the first category. But I’m biased though, I’ve worked mostly with innovation-driven product companies.
So, in short: don’t use projects for everything – but when you do, make sure you have an awesome Agile Project Leader!So what is an Agile Project Leader?
This started out as a fairly long article. Then I realized that the role I was describing was really about agile leadership in general, and not specific to the project model at all.
An Agile Project Leader is really just an Agile Leader that happens to work in a project context. So I moved that role description to a separate article, so as not to scare away people who are allergic to the project model
Hop over and read that article, and mentally swap in the word “project” wherever it makes sense. Told you this article is a bait & switch
There are some things that may be different in a project context – for example the “change agent” aspect. By definition, a project is something different than your “business as usual” work, and most likely involves collaboration between teams and departments that don’t normally work together. Unfortunately, since we’re dealing with people, this usually means some amount of politics and diplomacy. Hence, a project leader needs to deal with organizational (and cultural) boundaries – either breaking down the boundaries or improving collaboration across the boundaries. That’s a tough job, so don’t forget to give your project leader a pat on the back from time to time.Final words
I hope this article (and the other one) helps you improve the success rate of your projects, regardless of how you solve the leadership issue! And don’t forget – despite all the talk about projects in this article, always start by asking yourself if you even need a “project” at all.
Big thanks to Alistair Cockburn, Mary and Tom Poppendieck, Anders Haugeto, and a bunch of Spotifyers and Crispers and Legoists who helped improve this article. I’m honoured to have such an awesome group of advisors!
Note that this my personal opinion, my take on what an Agile Project Leader is (or should be). Some people may disagree, that’s fine. I’m also happy for feedback, although I won’t always be able to respond.
(Why are you still here? Go read What is an Agile Leader!)
This is just a brief snapshot of a journey in progress, not a journey completed
Sample slides below.
Last night our Lego Mindstorms robot “Robit” somehow managed to win the Robot Sumo competition at the GOTO conference in Copenhagen!
Pretty frickin’ amazing considering that this was a big software development conference with lots of super-experienced developers competing, and our robot was mostly built by two kids – David and Jenny Kniberg (11yrs and 10yrs old) – the only kids at the conference. Their robot didn’t just win once – it outmaneuvered and outwrestled the competing robots in every match!
Here’s the final, Robit to the left:
So how could a newbie team win the competition so decisively?
Was it our robot-building skills? Definitely not. We build mindstorm stuff maybe 1-2 hours per YEAR. We are newbies.
Was it our coding skills? Probably not. We do have experience coding. But very little in Mindstorms. And this was a professional software development conference, so we definitely didn’t have the upper hand on coding skills.
Was it luck? Nope, blind luck wouldn’t help us win every match in such a decisive way.
Was it because we (the adults) work at Lego? Nope. Didn’t use any special parts, didn’t consult with any experts.
So what was it then?
A clear goal, a bit of research, and lots of integration testing!
First we set a goal. I wasn’t too optimistic – we’ve never done anything like this before, and I expected tough competition. So my suggestion was “Let’s built a robot that at least can stay in the ring and put up a fight!” So if/when we lose, it should not be because our robot ran itself out of the ring. Kids didn’t accept that – they said “No way. We’re gonna WIN!”.
Nevertheless, I convinced them to start in small steps. “How about you START by building a Minimum Viable Robot – one that can just move around the ring without falling out. Then keep testing and improving from there”. Agile, anyone?
We knew nothing about these kind of competitions so we started by looking at some youtube clips to see what kind of designs and strategies people were using. That gave us some ideas.
Dave invented his own robot from scratch and figured out how to program it to stay inside the ring. We weren’t sure how good it was at fighting though, so Jenny built us a second robot to use as sparring partner, the mindstorms base robot from the building instructions.
Upon integration testing in a makeshift ring, it became apparent that our first robot can’t win. It could navigate the ring beautifully, but it was simply too weak physically to budge the other robot.
So now we had a SmartBot (smart but weak) and a ToughBot (strong but stupid). We figured it’s easier to make the ToughBot smarter than to make the SmartBot tougher (because of the base construction). Plus we really are newbies at building these things, so we figured we’re best off using the default mindstorms bot as a base.
After installing some sensors and porting some of the code from SmartBot, our ToughBot was becoming a ToughSmartBot! We had our candidate! Robit was born! Time to train him up. The original SmartBot was gradually stripped of sensors and stuff and became DummyBot – our training dummy.
We gave ourselves a very concrete challenge – Robit must learn to beat DummyBot! Not just once, but repeatedly. Because if Robit can’t beat a weak stripped down half-broken robot that stands still or roams around randomly, how could it have a chance in the competition? So we went through a bunch of cycles of integration testing and tweaking the hardware and software. We kept failing over and over (often in funny ways), but every iteration we got a bit closer to winning. It was 100% learning by experimenting.
One interesting thing happened along the way. We noticed on the youtube clips that many robots tried to lift and topple their enemies. So Dave built a pretty elaborate construction for that, and I helped write the code to control the lifter. Upon integration testing though, to our surprise, it turned out that the lifter wasn’t strong enough to lift the DummyBot under any circumstances. We would need another motor to strengthen it and we didn’t have the patience to figure out how. Bummer!
So with some regret we removed all hardware and code related to that. In theory it was awesome, in practice it was useless. We wanted to keep Robit simple and focused on one thing – putting up a proper fight!
I hate to admit it, but I really didn’t think we would stand a chance at winning the competition, so my ambition level was really just to have a robot that would put up a fight before losing. I didn’t want to ruin the kids hope though, so I kind of kept that to myself.
After dumping the lifter, Jenny built a simpler solution based on a pic we found online – a simple static bulldozer-like slope at the front of the bot. We figured that would help us get under the wheels and push or topple the opponent. Nothing unique, most robots have something like that in the front.
More integration testing. Started working pretty nice, Robit could now push the DummyBot around! However it was hard to get the right angle of attack. So the software needed some work.
After lots of iterating, Robit ended up with the following winning formula:
- Start by driving forward and right for 2 seconds. That takes me a bit away from the line of sight of the other robot, and protects me from blind stupid robots that just charge without looking. Also gives me a better attack angle towards the side and rear of the opponent.
- Main loop (the proactive “win the game” loop)
- Turn clockwise until I see the opponent
- Attack as long as I see the opponent! The attack sequence is “move forward 3 seconds, then move back 1 second”.
- Secondary loop (the reactive “get me out of trouble” loop)
- Am I at the edge of the ring (color sensor sees white/blue ground)? If so interrupt the main loop and BACK UP!
- Is someone pushing me from behind (button sensors on my butt)? If so interrupt the main loop and BACK UP!
That’s it. A simple algorithm that turned out to generate a pretty advanced behaviour! During the actual competition, Robit managed to outmaneuver most opponents and keep hitting them from the side, and thereby avoid their weaponry. The “backup 1 second” part of the attack sequence was important because robots often get stuck in a deadlock while wrestling. By backing up and getting reoriented, Robit could turn and attack again and again, with new momentum each time. Once it even flipped a much heavier opponent on it’s head!
Here’s another example of a match – took about 10 seconds to outmaneuver and push out the opponent!
We were four people in the team – Dave and Jenny, me, and Lars. Although both Lars and I work at Lego (he is an employee and I am a part-time consultant), both of use are Mindstorm rookies. Due to time constraints Lars wasn’t able to participate in building or programming the robot, but during the competition he discovered that Robit had been damaged. If he hadn’t noticed and fixed that, we definitely wouldn’t have won.
As for my role, well, it was mostly coaching. I did end up writing most of the code, but that was in tight collaboration with the kids. Plus it wasn’t really that much code, once we figured out a good algorithm.
The big learning for me is how incredibly important and powerful it is to iterate fast! And to do end-to-end integration testing early and often. The usual agile stuff in other words.
We ended up with a robot that was mechanically one of the most simple ones in the tournament, and software that was also pretty simple but very well tested. So when Robit entered the arena he was already an experienced battle-scarred combatant! Robit kicked butt!
Here’s the source code – or “Robit’s Brain”
Initially I was hesitant to give it away, since we might compete again. But giving it away forces us to improve! So if we build another robot, it’s qualification test is if it can beat Robit in the test ring