In the software world, the term 'imposter syndrome' has become a part of the common lexicon. It's so prevalent in our industry that even the mighty Jon Skeet wrote about it ... twice! Now if somebody as talented as the 'Chuck Norris of programming' has a hard time accepting praise, how are we supposed to?
A common thing agile teams are asked to do is plan, given historical performance, how much work they think they can reasonably commit to in a fixed increment of time. I'm going to tell you that in most cases, this is the most destructive thing you can do to a team, a product and your business.
Why? Because you are passively planning to be mediocre.
In the spirit of the new year, I'm going to share a confession and resolution. One that, at face value is significantly simpler and easier to keep than any gym membership you might have in mind. In practice, though, this takes real courage and confidence to bring to the workplace but when harnessed properly, I'm convinced it brings results like nothing else.
In our efforts to create a better workplace (which is a good cause), some cultures have grown into a state where we expect positivity from everybody we work with at all times. So much so, that negativity, scepticism and uncertainty have started to become socially unacceptable attitudes.
I wrote recently about how important it is to know your 'True North'. Having a crystal-clear picture of what you as an organisation stand for, is the single most important thing you can agree on. When you apply that practice to strategic planning and alignment, what you have is Hoshin Kanri.
Open yourself a new tab and do a quick image search for the term 'Professional'. You won't be surprised by the results. What you're inevitably confronted with is an abject sea of pinstripe, handshaking, and clipboards. Why is it that the notion of professionalism has become so inextricably linked with appearance? Is there really a meaningful correlation between how we dress and how we act? I think there is, but not in a good way.
The majority of businesses that produce a software product choose to sell their wares by having the most features, or as I've most commonly heard it put; the 'richest feature set'. Businesses like this will court new clients only to find that winning that particular deal comes with a catch.
Sometimes the capacity and skill set of the team vary drastically from sprint to sprint and even mid-sprint. When that happens you'll want to pay close attention to how the team is doing against the sprint backlog. All else being equal, that's the job of the burndown chart.
The trouble is, it doesn't handle this situation very elegantly at all because it assumes even capacity and that isn't always the case.
Here's a simple way you can get around that problem.
That awesome quote is attributed to Peter Drucker; a man of many skills and one who's wisdom I have an enormous amount of respect for. Like all great ideas though, it's a little too abstract to be of practical use without some extra thought and effort.
Without the extra effort, these ideas will inevitably be abused by people in support of their own agendas. It's not their fault of course, we all do that. In this case, I see more and more that we are starting to miss the point in an attempt to measure everything.
I sat in a presentation once in which the topic of discussion was mission statements and vision statements. I've got to be honest, I still don't think there's much difference. As a matter of fact, a lot of time seems to be spent talking about what the actual difference is. It's kinda confusing.
Most companies have them though. Do you know yours? Maybe you do, maybe you don't but let me ask you this. Does it have any effect at all, on your day-to-day activities? Do you use it to help focus critical decision making? Not in my experience. Not even once.
The purpose of the daily scrum (you might call it a standup), is for the team to plan the day. Think about that for a second. When was the last time you left a daily scrum where the team had a plan? That isn't the way it normally plays out.
The agile manifesto was written in 2001. That is 15 years ago ! With the amount and rate of change our industry has undergone in that time, has our understanding and application of those ideas held true to the original goal? No really, has it? Does Scrum really value 'People and interactions over processes and tools'? Not in a lot of organisations. Some, but not many.
A friend of mine recently asked me for advice on convincing his boss to start adopting some ‘agile-inspired’ principles in the department he looks after.
He explained that there is an anti-agile culture where he works and that questions over working practices generally got shot down quite quickly. That made his life more difficult because he hadn’t got the freedom he needed to make improvements where he felt they could be made. How could he sell agile to an organisation who don’t want to have the discussion?
Trust people and they will be trustworthy and trust in return. Develop people, and they will develop the organisation. Give people a problem to solve (not a solution to implement), and they will out-perform any team that have been simply told what to do.