You adopt practice to “make the team go”. However, every practice you adopt has a cost. The time you spend “making the practice go” is somewhat then a cost of making the team go. I like to talk about the cost of your practices as “Feed the Beast!” But what you really want to make your team go is to “Ride the Beast!” where the practices we have adopted start to carry the team faster than they could go without them.Continue Reading
When you look at software development or corporate change projects, you often see some creative fiction. There is fiction in the plans, fiction in the designs and fiction in the requirements. This fiction is created by the notion that “Before we can start, we have to know everything required to get to done.”
Intuitively, we all know that this is not really true. We all know that information will “emerge” from our activities that will change how we get to done. We learn from our mistakes. We try things that don’t produce as good a result as we want. We clarify our understanding of the problem as we demonstrate portions of the solution.Continue Reading
It is always better to spend the least amount of (time, effort, money) to get what you want, right? If I can get a tasty meal for $10 why
would I pay $30 or $200 – for the experience of eating – that isn’t about taste. That is a different thing, isn’t it. We have different priorities for eating – being full, healthy, tasty, being served, fast service, being able to relax, a pleasant experience, being able to brag about my meal/experience. Each of these is a different reason for selecting a dining experience. Each of them is valuable to some people some times, but not all people all the time. The way we choose to spend our money to eat is not that different than the way we choose to spend our money on software capabilities; there are different reasons why we prefer one capability or a means of delivering a capability over others.
These are the principles that I use to guide my story elaboration – and thus my ability to challenge those who would ask me to do more than the minimum…Continue Reading
While I will not claim to be an expert at writing user stories, I am experienced. It is not always enough to simply follow the pattern. Like any analysis pattern, there are some things that one can do to improve their stories. Continue Reading
I have been “doing” user stories for a while, years now. I have been doing them mechanically without thinking about what makes them “good”. Not that I haven’t been working to make them better with each release on every project. My user stories have consistently grown better following the INVEST pattern. What I haven’t been thinking about is “why” user stories and the process through which we create them is good.Continue Reading
I read this article, and it seemed to me to say for organizations in general, what Agile has done for software development teams. Moving from a command and control – process/factory model, to a model that allows/incents/expects humans to invent, analyze, innovate, figure out. Is it possible that we are finally ready to tranform organization structure from its industrial age roots into an information age – service orientation. How many organizations say “our people are our most valuable resource” – but act like they have FTE’s – (HR/Manager speak for “universal man widgets”).
I highly recommend that you evaluate every difficult thing that is on your plate, and decide whether it is lack of talent/skill/knowledge or simply lack of motivation that is getting in your way. I hate this evaluation, because it always comes out the same. Arrgh!
This short post was a huge shot in the arm for me this week. Management is about constraints, leadership is about movement. Movement and constraint are opposing forces. Dang! Now that I am not in a staff management role (first time since ’04) this is much easier to see.
Mike Cohn is pretty much “the man” on user stories. I have had conversations with lots of agilists about stories epics and themes (story scope). What nobody (including Mike) really wants to get into is whether stories are about business capabilities or software capability. IMHO – when it comes to “requirements” for software – everything (not just agile) craps out on this divide. And it is a critical division because all the value is on one side, and all the work is on the other. Hmm. Never the less – I thought this was one of the best posts on story scope I have read in a long time.