Too many managers believe in the myth of 100% utilization—the belief that every single technical person must be fully utilized every single minute of every single day. The problem with this myth is that there is no time for innovation, no time for serendipitous thinking, no time for exploration, and it often leads to a less successful organization.
Len Whitmore explores how the growth of agile changes the roles, responsibilities, and titles of mid-managers more so than any other management group, because agile practices require more leadership and less of what is considered traditional management techniques.
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.