Code is constantly changing. I can spend 2 minutes on Twitter, LinkedIn, and YouTube and find new frameworks and approaches to building a career than I ever could at any time in history. And yet we still push back against learning. What are we doing wrong and what is holding us back?
Teams don’t just work and they don’t just magically come together. It takes work and time. As soon as I see an email that ends with “let’s do this as a team” – I know there is something wrong, that the bridge isn’t there and this is a half-hearted attempt to deal with the problem. Building bridges between teams is not easy but if you’re writing your team announcements or motivation quotes in an email.…
I don’t worry about the falls. I don’t worry about the slipups. I don’t worry about things that are missed. Because we’ll figure it out, we’ll learn how to get better, we’ll figure out what we did wrong and fix the problem. The recovery is what I look for, if you can bounce back from defeat, from failure, from mistakes – that’s what will always matter. Will you blame your team? Will you beat yourself?…
That’s the question you need to be asking yourself as their Dev Manager all the time. What can they do? What can they do that they are not doing? What can they do if I let them have a run at it? What can they do if I took a step back? What can they do if I left the planning up to them? The goal isn’t to overload your team and gives them MORE…
The goal of every sprint should be pretty simple, irrespective of the release, and one that the team can easily get behind… “Did we do what we said we were going to do?” This is a statement that everyone can get behind – whether you’re pushing self-organization, leadership, accountability, responsibility – it’s clear what the beginning and end goal of the sprint is. But often we lose sight of the goal when it’s supposed to…