The larger the effort, the more we need to estimate. And, the more your estimate will be wrong. The more we estimate, the more we have schedule games. That’s why I suggested you use agile approaches. You can break things down, and iterate.
What I mean by transparency is about letting the sunlight in to your overall operations, by default. In the case of Healthcare.gov, one of the numerous contractors applied this on front-end development, but the entire rest of the supply chain did not.
I picked up Daniel Kahneman’s "Thinking Fast and Slow" after a recommendation by Mike Jones in early 2013 – it’s taken me quite a while to get through it. The book starts by describing our two styles of thinking…
This year’s Agile By Example (or simply ABE) was my 2nd visit to this conference, I’ve missed only the first edition. Last year I felt really refreshed by the conference built not only around code, coding, testing and developing software.
The Puritan Gift is not a book primarily oriented to programmers, but to knowledge workers and managers in general. Its goal is to show, through history, the evolution of American and Japanese management over the last two centuries, its strongest moments and its decline through the Cult of the so-called Expert and of corporate consultancy companies.
This week, for the first time ever, DZone is releasing the first in a series of checklists for software developers. Our first checklist covers Test-Driven Development (TDD). To complement this exciting new endeavor, I dug through the DZone archives and put together a Top 10 list of TDD resources.
In an open, self-regulated market, the tools gravitate toward their corresponding, welcoming environments. Low-trust tools go to low-trust, highly regulated environments, and high-trust tools are used in agile, high-trust cultures.
My recent “#NoProjects - why projects don’t make sense” post stirred up a fair bit of discussion, both on the blog and especially on Twitter. But, while that post railed against “projects” it didn’t say much about what we should do instead. So let me try and put in place the outline of how I see a #NoProjects world working.
Continuous Delivery and Service Management fundamentally differ in terms of both action frequency and ordering – while a Continuous Delivery pipeline will offer a single workflow encapsulating the same actions in the same order, the Service Management domain requires multiple workflows and adhoc actions in order to respond to operational issues.
I personally think that being “agile” is truly what makes a company “Agile.” Just like how happiness is a journey and there is no “permanent” state called happiness, being “agile” is a journey and there is no final/permanent state called “Agile”.
Agile principles are all about learning as you go and using the new knowledge to redefine the goals of the project. This is perfect for the developers and the immediately involved business representatives. But for a C-level exec it becomes hard.
Many software developers I’ve talked to have expressed interest in the idea of someday either starting their own business, or in some capacity working for themselves. Before you do really quit your job, you should first understand why it is a good idea to quit your job.
Are you working in the way you are because it’s a good idea, or just because someone told you to do it? I die a little bit inside when people say “should we do Agile or not?” The assumptions behind this question are all wrong: That there is one way to “be Agile”