When on the Scrum Master Podcast, I was asked a very important question: How do I get a systemic view of the organization. This is worth going deeply into. Let’s start with why this view is valuable. The more I work with teams, I find there’s a limit of change I can make. Or, rather, they can
Category Archives: agile
A developer’s life is not simple. Developers need to contend with adding new software features, quickly, from different customers, while keeping up with technology. And do some support work in the middle. And, also meetings. However, the road to improvement through this complex situation can be a strange one. It sometimes starts with these suggestions, heard around
It’s a great privilege to be a featured author on DZone’s 2015 edition of Code Quality and Software Agility. Along with other cool articles and infographics, you can find my “Refactoring in a Legacy Code Jungle” article there.
I didn’t think that my Story Points story would garner such attention. Reactions were divided to two groups: the “Great Post” type, short and supportive. And the “You’re doing it wrong” type, long and argumentative. I can’t fault people for telling me “You’re doing it wrong” after I used it in that post. It did make me
I don’t like story points. I think this is part of my crusade against complexity. You can catch a glimpse of it here. Story points were invented as supporting beams for the bridge between business and development that would later be called agile. They started with a very good concept that wasn’t there before: The story.
The main dysfunctions we concentrate on when talking about estimates are how they (and the people who gave them) are treated once they are given. Management asks for estimations and then either: Disregards them completely and sets a deadline that ignores the estimates, made by the people who actually know and will do the work. Inflate them
I was asked a hypothetical question: If someone caused a major failure to the business, would that be a reason to fire her. I said no, because: It is unlikely that a single individual can actually be the only accountable person in such a scenario. If the error wasn’t malicious, that makes the failure a combination of judgmental
To improve we need transparency. We cannot solve problems we don’t see. We can’t improve an invisible process. We need people to speak out about how they feel, how their work is affected. In order to improve, my team needs me to admit I’m late, and not hide I’m working for two weeks, digging a hole, and find out
After some feedback from the Done Fallacy post, I feel I need to explore done-ness a bit more. How we work and talk make up some very interesting distinctions. For example, let’s think about what the word “done” really means. It sounds simple, but the meaning changes over time. Let’s take a story, for starters. When we
One of the earliest ideas you learn as an agile practitioner is “Done, Done, Done”. There’s a lot of thinking behind it, but for me it boils down to trust. When you don’t know what “done” means, the next person who gets you’re deliverable might be surprised. As a rule, we don’t like surprises. So regardless