Organisations with a hierarchy can only change as fast as their leaders can change. That’s a constraint. Holacratic organisations strive to distribute authority and decision making to all of their employees. But how do things work when there’s no hierarchy, no permanent teams and no formal job roles? It may lead to chaos, right? Not necessarily. Here’s how it may work.
Do you consider technical debt, innovation, customer requests and support requests while prioritising your product backlog? How do you decide how much technical work should be prioritised, or should you devote most of the sprint to the business driven requirements? Here’s a model that can help you make sense of it all.
Are we value driven, or values driven? Small difference in how you spell it, but it’s a big shift in behaviour and culture. Are we too tribal in our thinking and actions? Are we too narrow in our thinking that we lose sight of why did start doing Agile in the first place? Good questions, all of these. Here are some thoughts on this.
Just because the word “build” comes first in the phrase doesn’t mean you go straight into building a product. Not at all. The idea of build, measure, learn is not to build a random set of stuff, and see what works. It’s a very disciplined way of building and, launching products. So, when do we start developing and coding then? When do we launch and what do we do after that? Here’s an excellent overview by Steve Blank – the person who started this movement.
What purpose do story points serve from a Product Owner, stakeholder and team perspective? What use are story points to the Scrum Master? Here’s a good primer.
Have you ever given a thought to the difference between guess and estimate? Guess stems from belief. Does it need to have any evidence behind it? Estimate stems from a Greek word which means “to value”. Now, does an estimate need to be based on experience, model, or some sort of data? Here’s a quick read.
Following TDD requires a big shift. It’s as tough, like adopting a new habit. What if you turn this into a game? Games are fun and are less tedious. Here’s a step by step guide on how you can gamify the adoption of TDD.
Now and then we come across a feature we want to remove from our product. How do we go about it? Remove it from the next build, release it and hope no-one notices – doesn’t sound like a good plan. Or maybe tell users in advance. Or announce it to potential users who already have seen this feature already? Here are 3 very practical steps we can follow while removing features.
DevOps has had a stellar year in 2014. But is it losing steam? It all started with a few motivated individuals and groups, all technical minded who wanted to change it for the better. Now it’s becoming mostly about how-to build more efficient development operations. Where do we go from here? Where’s the movement headed?
Technical debt like all other kinds of debt is expensive. At times it’s too expensive to payback. On the other hand bugs or issues have become part and parcel of development lifecycle, unfortunately. Should bugs be dealt as technical debt? Here are some perspectives.