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.
For those who attended this week's Agile Denver meetup, here are the slides and some additional resources for you…
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:
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.
Bill had two very different experiences interviewing for two different positions at two different companies: one as a software engineer, and one as a VP-level manager.
For a one week sprint, it’s possible to do Review, Retrospective, and Planning all on Wednesday morning.
By definition, any work that has not been completed to the satisfaction of the DoD remains undone. Taking work off a Product Backlog just because it is on a Sprint Backlog is therefore precocious and a mistake.
From software developer Curtis Lassam (who writes about comics and code) comes a comic series called Cube Drone. This is Cube Drone #2: Nyan.
I understand that you have to qualify large number of folks, at your very algorithmic-centric company, but when it comes to measuring what I do, a programming test isn’t a thing.
Coding (computer programming) is the art of creating anything from computer games and iPhone apps to computational models that help us improve health care. As our kids grow up, this ability to code will become as fundamental as reading and writing to their success, regardless of what occupation they ultimately choose.
Lean is more than just minimizing waste. A popular misconception of Lean is that it is suited only for manufacturing. In this article I will be discussing non-value added process and implementing Lean in software development.
Since the Agile Manifesto was published in 2001 much has changed. It's time to rethink yesterday’s manifesto in a new light and deconstruct which concepts were home runs and which still need to evolve.
Most companies have some variation of the same process for interviewing developers. There are a myriad of reasons for the candidate to say No. The important thing is for you to learn from their NO.
So, regardless of whether a change is imposed by the management of an organization, is requested by and driven by those most affected by the change, or any combination of both, the fundamental mathematics remain the same.
Hopefully these articles have helped the reader decide if a) agile will work for them and b) if they are already working in an agile way.