Do people two level above, or two level below you on an organisational chart really understand your work? Can we operate as a functional tribe beyond Dunbar’s number, i.e. 150? Is the work done by individuals more important, or their job titles? What do organisations tend to do when they can’t resolve their dysfunctions? Here are 8 key struggles of large organisations.
Everyone wants their teams to improve. How do you know if they are on the improvement journey, and how do you assess improvement? Do you look at the way they work, and the way the work flows into the team? Are they getting better at managing dependencies, or do they see those as blockers? Here are 5 key areas to watch out for when you are looking into team performance.
People come out of a training session, or a conference. They start practicing Agile. Then over a period a time things change. They go from believing Agile can work to believing it’s a farce. This happens fast. This happens quietly. So who gets the blame? The team, the management, or everyone’s favourite, the Scrum Maser? Or the organisational culture? And what can we do from this point onwards? Have a look.
How do you know your teams are producing quality increments, sprint in – sprint out? Are they able to deliver high value features, and delay low value features, at a sustainable pace? Are the features integrated, and you don’t end up with unintended dependencies? Here are 8 key indicators that can help us understand quality, from an end to end perspective.
Technical debt is undone work that we’d need to do at a later point. But what constitutes technical debt? Once we know what it is, we can make more conscious decisions about when to carry some amount of debt over, and when not to. And we can measure the amount of debt we carry, and work out how to reduce it. Here are some key definitions of technical debt and a few examples to help us understand what technical debt is, and what it isn’t.
Some elements of game development are deemed sequential. Some people find it a bit difficult to follow a Scrum based approach. Can we try a Kanban based approach to manage flow from one phase (design, graphics) to next (coding – testing) and optimise cycle time? How would it work? Here’s an interesting perspective.
There’s always room to improve and get better no matter how good a team is. That’s the hallmark of a great team – the hunger to improve. Retrospectives present a crucial opportunity to inspect and adapt, and get better. Still, for most teams, Retrospectives are not as effective as these should be. Watch out for these 5 key Retrospective dysfunctions.
Do you feel like buried in the email hole? Ever trying to catch up with email. What to do? Delay reading email? Follow a schedule to read and respond to emails, so it doesn’t disrupt everything else? Use the 2-minute rule? Here are a few good ideas on how we can manage email better.