Since most readers of this blog are likely to be practicing or budding Agilists, replace “you†with “your coworkers†or “your manager†as appropriate.
Even remote team members should be in contact on a daily basis for Scrum/stand-up meetings and throughout the day over the phone/Skype/IM/email. On-site, co-located teams really have no excuse to work in isolation.
Often a consequence of #1. Scrum is a good way to report status efficiently, facilitate face-to-face communication, and make commitments to each other rather than management.
This happens if you're not doing continuous integration on a clean (not a developer's) machine at a minimum of once a day, but preferably whenever someone checks code in to source control. You are using source control, right?
Good old Waterfall, Big Design Up Front, and Cover Your A**. Instead, favor open, continuous communication with the customer or her representative, including continuous release/demonstration and feedback. This allows you to adapt to changing, or simply miscommunicated, requirements.
It's really amazing how many developers, including (especially?) senior-level developers, haven't grokked the benefits of unit testing. Somehow any practice with the word "testing" in its name is up to QA to figure out, if you're lucky enough to have a good QA department and process. Unit testing is a "white-box" (or glass-box if you prefer) test — leverage your knowledge of the implementation to fully exercise the code under test. QA typically operates at the black-box level, without understanding the fine-grained implementation details, like a user.
Sounds like #5, but a bit different. Everyone is responsible for quality, especially developers. The sooner a bug is found, the cheaper it is to fix.
No one knows for sure how long it will take to design, implement, and integrate a software component. But the person who is designing, implementing, and integrating it should be able to make the best guess and will have more incentive to produce accurate estimates.
A lot of architects are great. I've worked with a few that were hands-on and knew their stuff. They knew the environment, languages, libraries, and legacy code as well or better than most of the developers. But architects who don't get their hands dirty can be dangerous, especially if they opt not to consult with their lead developers on important design considerations.
Without continuous integration, a good test suite, and solid design, touching even the seemingly most innocuous line of code is a risk to distant, often unknown, relatives than depend on the behavior of that code.
Definitely related to #9, but that word "refactor" is especially scary to some, especially if you don't have a good test suite for a safety net. It's also scary if your team doesn't understand what refactoring is, and uses it to describe massive redesign — management is once-bitten-twice-shy when it comes to that sort of thing.
Comments
Good consolidation
December 24, 2007 by Anonymous (not verified), 1 year 2 weeks ago
Comment id: 1415
Jeremy, that was good ...but I would like to know if Stand-Up meetings are not possible is it okay if we go for an alternative solution ( I am not able to think of any alternative though ...)
Alternatives to stand-ups
December 26, 2007 by jeremy, 1 year 1 week ago
Comment id: 1424
If conventional scrum stand-ups are not possible, an alternative might be a short conference call, maybe on Skype or other VOIP solution. It's not as effective, and adds more overhead.
You could also send a daily email to everyone on the team to let them know what you've done and are doing, and to let the team know if you are blocked.
If you're on a larger team (say 8 or more) and it's just too hard to get everyone together at one time, you could split up into logical groups of 3-5, but try to get the whole team together for at least 15 minutes once a week or so. The important thing is for the team to be making commitments to each other, not just management, and to share knowledge and get help from the right people when needed.
Post new comment