Johanna Rothman writes about tracking the stuff you can’t fix today, but need to someday:
Technical debt needs to be as visible as everything else. Maybe more so, because the more debt you have, the slower any future development will be.
Johanna Rothman writes about tracking the stuff you can’t fix today, but need to someday:
Technical debt needs to be as visible as everything else. Maybe more so, because the more debt you have, the slower any future development will be.
Johanna Rothman writes in Waterfall Projects Create Naivete:
But a waterfall project organization, where you have milestones such as “requirements complete” or “feature freeze” or “feature complete” provide a disservice to the entire project and management team. We know the requirements are not complete. We know the features will change. Saying they are complete or frozen won’t change reality. But those complete or frozen milestones provide a sense of inevitability about the eventual ending of the project, and infer that since we’re “meeting” (ha!) the project milestones, that we will continue to. That’s the naive part. (See There is No Such Thing as Percent Complete and Showing Project Progress (NOT percent complete) for why.)
What methodology do you think is the best way to manage and track a project? Tried and true Waterfall? Up and coming Agile?
“In mid 2006, YouTube served approximately 100 million videos in a single day. To maintain a website of that scale, one would imagine YouTube has hundreds of DBAs. But in fact, there are just three people that make it all work. Paul Tuckfield, the MySQL DBA at YouTube shares horror stories about scalability at YouTube and how he coped with them to keep the show going everyday, while learning important lessons along the way.”
So here is the question. How do you stay productive? Do you manage your Time, or do you manage your Attention? Linda Stone wrote an excellent piece at O’Reilly Radar on Is it Time to Retire the Never-Ending List?
In the cases where people reported managing their time, they more often reported experiencing burn-out, they didn’t know how much longer they could go on at their particular job or lifestyle. There was often a sense of helplessness and overwhelm.
…
In almost every case [where people manage their attention], these professionals reported experiencing “flow” (a la Csikszentmihalyi) in their work.
Andy Hunt, co-founder of The Pragmatic Programmers and author of many books, recently posted Stage 0: Not Ready for Agile where he was disallowed to give his Pragmatic Agility talk in an organization because the hiring manager didn’t go through the “proper channels” even though no such channels existed.
I really liked the whole article, but he noted a number of behaviors that indicate a company is not ready for Agile that I found particularly insightful:
You’re not ready for agile if you … grow uncomfortable with uncertainty. In an agile project, you will not know the project end date or even what features will be delivered in the next iteration. You cannot stand this, and will insist on fixed dates and costs right up front.
You’re not ready for agile if you … treat developers as a commodity; a uniform, fungible resource. They are all alike. You can’t trust them to think for themselves, you’ve got to make the important decisions for them.
Personally, I feel quite comfortable with uncertainty - especially with software – where it is an act of invention, not an act of manufacturing. And I think the best asset you can have on any software project is highly skilled craftsmen (not “fungible” developers).
But you need a team to make Agile work – not just one person. So the question for me is this: How can you shift this mindset for the various players in your organization?