I’m at the 13ICSQ conference this week. One person (at least) was confused about agile processes: Conference attendee: “Agile processes are a license to hack!!!!!!!” JR: “No. Every agile team I’ve seen is highly disciplined. No hacking there. I’m sure there are people who say they’re performing agile development, and they’re just hacking, but truly […]
Release trains, the technique of planning releases on a particular date several times a year (such as quarterly releases, on the 12th of the last month of the quarter), can help you manage your development and test staff as well as machines and tool resources. I wrote about release trains a while ago here.
At a recent presentation about agile project management, I mentioned refactoring. One of the attendees said, “No, I don’t want to redesign the whole application every iteration. Agile’s not for me!” Well, I decided I couldn’t address the resistance if I didn’t first start with defining refactoring. I said, “Hmm, refactoring isn’t the same
In the past few weeks, too many managers have written to me, asking for help on knowing how “good” their people are. When I ask more questions, such as “What does good mean to you?”, they say they want to know who’s most productive. Then I walk through this analysis with them: Productivity is
Via Steve Norrie’s weblog, I found Kovitz’s “Hidden Skills that Support Phased and Agile Requirements Engineering”. In phased development, projects promise large feature sets to a customer for future delivery. In agile projects, the requirements are refined over numerous little conversations with the customer, day in, day out. Kovitz claims the skills required for agile
Earlier this week, I was at SPC teaching about project requirements and project management. If you haven’t thought about lifecycles, consider the differences between these kinds of lifecycles: Linear: Waterfall and waterfall with feedback Iterative: Spiral, where the whole product is up for grabs each time Incremental: Where you add to the product in pieces
Fred Brooks, in his classic, “The Mythical Man-Month,” talks about a chief programmer team (chief programmer, and programmers of lesser hierarchy until you get to the peon). The chief programmer team works when one person can keep all the details about the product in their head. If you use several hierarchical teams of chief
by Johanna Rothman. Originally published in Cutter’s e-Project Advisor, February 8, 2001. Gotta release it now? Gotta put in just that one more feature? Gotta do something else? The more gottas you have, the less agile your project is. E-project management is about the ability to adapt quickly to changing conditions. So, how can you