I am sick to death of Agile Initiatives because they usually fail. The core problem is that the typical approach used to initiate Agile is inconsistent with Agile goals of empowerment and engagement.
Following up on my Why We Need to Teach Kid to Code, here are some fun ways to help them learn. So cool – wish some of these were around when I was an 8 year old learning to code on my Atari 800!
We are at a point in time where people who write software are much like the craftspeople and artisans in times past. Software is not yet something that can be easily manufactured on an assembly line. So are you a codesmith?
Bad managers, who are by definition less trusted, can easily rationalize away any attempt at quantification. One quantifiable measure would be employee turnover.
I don’t estimate stories in sprint planning. Nor do I re-estimate stories in sprint planning. I estimate stories in a separate estimating meeting and usually at least a couple sprints in advance, if not more. There are a few reasons why (re)estimating during sprint planning is a dangerous practice:
While not every Agile practice can be taken out of software development and used someplace else the roots of Agile mean that the principles, values and ideas which Agile is built on can be. In your domain Agile as now known might work quite well, but in someone else’s domain there may be more need to think deeper.
Obviously when you hire, you want to find a good mix of experience and talent. But a perfectly balanced straddle between the two is impossible. So when forced to choose between them, which do you choose: experience or talent?
Agile is often seen as a team process, and certainly agile lends itself to team activities. So can you apply agile to the Sole Home Office developer?
On the importance on non-programming skills in the job of a programmer.
In this post I discuss three pitfalls of agile software development faced by developers when trying to make changes in the development process at "non-agile" companies.
In our ever going search for simplicity, metrics help us minimize a whole uncertain world into a number. We like that. But metrics are over-simplification. We should use them like that.
We can refine our estimates, if management needs them. The question is this: why does management need them?
The moral of the story is that real options thinking, systems thinking and many other such concepts present or yet to come may be more appropriate in some cases than Lean/Kanban thinking. Lean/Kanban thinking is useful, but it isn’t all there is.
Today's quote is: "In most cases being a good boss means hiring talented people and then getting out of their way." This advice (hire smart, don’t micromanage) is so simplistic, it’s hardly worth saying. The profound stupidity is equating this with “being a good boss“. No, hiring smart people and not micromanaging them is the absolute, bare minimum you should be doing as a boss.
Right now I want to blog about a book because I want to recommend this book. The book is: Scaling Up Excellence by Robert Sutton and Huggy Rao. I hope this book becomes more widely known in the software development community, and particularly those concerned with “Agile” and “Scaling Agile.”
Do you create a list of actions by analyzing the data you collect in your Retrospectives? Read on for 3 simple steps on how to run your Agile Retrospectives.
From software developer Curtis Lassam (who writes about comics and code) comes a comic series called Cube Drone. This is Cube Drone #3: Coffee.
I used to be Superman. I could do anything I wanted, and no one would tell me I was wrong. But Superman can be wrong. And when Superman makes a mistake, it can be a crucial mistake for the organization. In short, we don’t need Superman. We need Batman and Robin.
If you are considering doing capacity planning on what the teams can do based on their estimation or previous capacity, don’t do it. First, you can’t possibly know based on previous data. Why? Because the teams are interconnected in interesting ways.
So chances are that, should you follow any kind of formalized project management, it’s likely to be a form of Scrum. And if so, we’ll just betcha that you’ll nod along with this piece:
For those who attended this week's Agile Denver meetup, here are the slides and some additional resources for you…
Planning and elaboration go hand in hand as items move from unknown problem -unknown solution to known problem-unknown solution to known problem – known solution.
During backlog creation, user stories need to be compared and contrasted in order to promote maximum value delivery. The product owner might need to use different techniques, such as T-shirt sizing, in order to better prioritize the project’s stories.
Like the graphene example at the beginning of the post, thin stories have remarkable properties far beyond the fact that they are just "thin". The value gained by learning how to split Stories effectively is enormous owing to the flexibility it provides by deferring decisions as long as possible and the removal of the need to estimate at a granular level.