Test automation can turn into a real pain in the neck if a designated team is in charge of it or if the automators work on it as a separate project. In this article, Lisa Crispin seconds Bob Jones’s recent call for whole-team test automation and elaborates on the dangers of relegating test automation to an isolated project rather than integrating it into the overall software development process.
This is a product development organization with developers in Italy, testers in India, more developers in New York, product owners and project managers in California.
This organization first tried iterations, but the team could never get to done. The problem was that the stories were too large. Normally I suggest smaller iterations, but one of the developers suggested they move to kanban.
Understanding what the business users are trying to achieve can significantly help you focus the project on things that really matter. In this excerpt from Gojko Adzic's book Specification by Example, the author offers some tips for effectively collaborating on the project scope when you don’t have high-level control of the project.
Johanna Rothman has worked with several management teams who want her to train them or their project managers to take over the agile training. While on the surface this doesn't seem an unreasonable request, when one considers the self-managing, self-organizing nature of an agile team, the incongruity of this thinking begins to shine through.
One of the most important roles of a leader is to serve as a role model for others in the organization. In this article, Naomi Karten describes a situation in which a CIO forgot this responsibility, almost taking action that would have undermined his efforts to reverse the IT organization’s plunging morale.
I missed one presentation in my last post. At Oredev, I had an opportunity to speak with the PMI Sweden folks (at least, the southern Sweden folks). I talked about Agile Program Management, and discussed my current thinking about agile program management.
Should you diligently produce multiple big documents before testing begins? Consultant Fiona Charles argues that you should do that only if you believe that documentation is your product as a tester. If your product is information, you should instead minimize test documentation and engage with the software to build the product your stakeholders are paying for.
Whether you’re concerned about your day-to-day work or the long-term goals you’ve set, a good attitude can make all the difference. In this article, Laura Brandenburg expands on some tips gathered from Jeffrey Gitomer’s Little Gold Book of Yes! Attitude.