I spent the most recent four weeks conferencing. I had a blast. Because I kept traveling, I nicknamed this series of conferences my “Northern Hemisphere Conference Tour.” I’ve posted the slides on slideshare.net.
I am writing a book about agile program management. I have some portion of the first draft written. I don’t know how much, because I have not had any review. When I write, I can’t tell how much I’ve written until I have my first review. Then I will know how much I have that is good and how much is throw-away. (When I write a book, I have to write enough so my reviewers have enough context to review, but not so much that I’ve gone too far. I find it difficult to know how much to write before review.)
When we don’t understand what the words we use could mean to our customers and business stakeholders, we can trigger misunderstanding or strong emotional reactions that impair working relationships. To be successful, we either need to speak our customers’ language or, when we don’t speak their language, act with conscious intent.
In recent years within the object oriented and agile community, several approaches to software design and development have materialized and are in use by professional software developers. Test-Driven Development (TDD), Domain-Driven Design (DDD), Behavior-Driven Design (BDD) and Feature-Driven Design (FDD) are some of the more well known approaches. While these philosophies all imbibe the classic agile principles of an incremental and iterative mindset to software development, they subtly differ from each other.
Lisa Crispin explains how being nice goes a lot further than just displaying good manners; it can be the difference between a happy, productive team, and one that's completely dysfunctional and prone to failure. Learn how she's discovered this on past projects and how you can avoid the same pitfall.
In this week's column, Jeff Patton sends a reminder that software developers who neglect the practices of "iteration" and "incremental" will get caught either delivering poor quality software or delaying schedules in order to make time to iterate. We kick ourselves, or others, for not "getting [software] right up front" when we all know that the hardest part of software development is figuring out what to build. But there's hope, and it comes in the form of prototypes and frequent iterations.
Despite the fact that iterative approaches to software development are increasingly used, most of the people paying for IT software developmet have an expectation that we should be able to tell them—before coding starts—"what's it going to do, what's it going to cost, and when's it going to be ready?" This article exlains why that's an unattainable expectation and corrects the misleading "product-lifecycle-model" for estimating.
Models are useful in different settings in different ways. Models can test facts, ideas and understanding, simulate operation, and aid coordination between systems and people. In this column, Becky Winant lists six model patterns she has seen in practice in software development organizations, talking about where each is appropriate, and the strengths and weaknesses of each.
Including a testing/QA component early in a software project necessarily prolongs the schedule, right? Not so, according to Ross Collard. In this, the third of a three-part series, Collard explains how to anticipate risks and to aggressively manage the process to prevent disaster.
Including a testing/QA component on a software project necessarily prolongs the schedule, right? Not so, according to Ross Collard. In this, the first of a three-part series, Collard explains how speed and quality assurance don't have to contradict each other. Read his examples of how testing can actually help reduce the time to market.