Testing legacy code is tough. It was never designed for tests. The app uses EJBs including old fashioned entity beans. After spending some time trying to get a few tests written against a stateless session bean using MockEJB, I hit upon a new idea. Maybe I want to test at the Business Delegate layer and just mock the calls to the stateless session bean.
With a little dash of EasyMock and a bonus setter method to inject the stateless session bean I now can start opening up a seam for future tests. I’d still like to test the EJB layers, but now I have a seam in the application to work from. (Kudos to Michael Feathers for naming the technique)
David Geary, a JSF expert, notes in a recent podcast that he sees three generations of web frameworks:
- Classic Struts
That gels with my experience, though I’ve only barely touched GWT.
Some of the toughest problems on projects are caused by pulling together a group of individuals. Often one or more don’t work out.
On an Agile project you commit to your work every day and explain what you accomplished the day before. There’s nowhere to hide hours of surfing the web or spending a whole day writing a few lines of code. Productivity and effectiveness are evaluated every day. If you’re struggling but really trying the team will pull together and try to help out. Just putting in time by sitting in your cubicle for 8 hours a day and attending the standup isn’t enough.
At this point it becomes a management issue. Scrum puts pressure on management to act. Jump in, give the difficult feedback and get the employee on track. Management isn’t just about having an office, filling out budgets, and running team meetings. Management is defining expectations and helping people live up to them.
If line management can’t arrive at resolution it becomes an organizational issue. As Scrum or other Agile approaches expand and become the norm the organization must adapt. Letting a team flail with a weak link is unacceptable. Large scale organizational change is hard. Ken Schwaber’s estimate is only 20% of organizations will successfully complete a Scrum implementation.
I’m not sure why, but as an organization we often have wordy Sprint goals that take up half a page and include all sorts of obvious qualifiers like “will be deployed and tested to QA with no serious defects.” The backlog items are squeezed into tortured sentences and stuck up somewhere in the team room. These sort of goals are ineffective. No one can remember them. Have a goal like “Have the CEO order a new widget” are a lot easier to get behind.
A developer reminded me of a good rule of thumb from Scrum and XP from the Trenches by Henrik Kniberg:
The sprint goal should answer the fundamental question “Why are we doing this sprint? Why don’t we all just go on vacation instead?”. In fact, one way to wheedle a sprint goal out of the product owner is to literally ask that question.
Are you kidding? Perfect reason to get a training request turned down. Don’t help me out with an elaborate giveaway.