As a longtime associate of ThotSpots, I regularly contribute to their blog as well my own. Here are two recent examples:
Why Having a “Backlog” Sucks the Life Out of a Project
Put Your Wisest Developers on Maintenance, Not the Rookies
Click here for the complete list of my contributions over the years: http://www.thotspots.com/author/craig/
Retrospective meetings are probably the most misunderstood and underutilized aspect of agile development.
If you know the expression, “the three most important things in real estate are location, location, location,” then you can relate when I say that the three most important things in software development are feedback, feedback, feedback. And, one particularly powerful feedback mechanism is the retrospective meeting. It’s how the developers give feedback to themselves — about their own processes.
I like to hold retrospectives early and often, at least once a week, sometimes once a day. That way, I can capture ideas while they are fresh on everyone’s minds. To make up for it, the retrospectives are kept short, 15 minutes MAX. In fact, if they go longer than 5 minutes, then something is wrong.
Why so short? Continue reading Only One Retrospective Action-Item at a Time
When entry-level developers are assigned a business problem, they tend to latch on to the first solution that comes to mind. Not only does this have a tendency to lock in an inferior solution too soon, but it may even cloud thinking to the point of missing some important requirements.
Telltale signs of this mistake are in the developer’s vocabulary, so mentors should pay attention. When the rookie attempts to gather a program’s requirements, does he or she jump straight to using programming terminology in describing those requirements, like hash maps, FIFO queues, reference pointers, and LIFO stacks? Or, does he or she carefully stick to problem-domain terminology like definitions, breakdowns, groups, relationships, andpriorities?
If your rookie is indeed having trouble distinguishing the problem-domain from the solution-domain, then the following techniques may help. Continue reading Rookie Mistake: Jumping to Conclusions with Presumed Solutions