|
On Beauty, Quality, and Relativity The saying “beauty is in the eye of the beholder” rings true whether you’re staring at a centuries-old painting, listening to a busker’s music reflect off the tiles in a subway station, or testing software. It’s one thing to evaluate quality, but how do we evaluate how we evaluate quality?
|
|
|
We're Not "Special" Often, when I comment on someone's blog post or respond to a tweet with a story about how my team succeeded with some practice, someone replies, "Yeah, but your team is special." I interpret this as meaning, "You're a presenter and book author. You must be an expert, so of course your team can do anything." This frustrates the heck out of me.
|
|
|
Management Myth #2: Only ‘The Expert’ Can Perform This Work How many times have you seen this in your projects: You need something specific done such as a new database, or a specific user interface designed, or you need a release engineer, or a user interface designer, or a part of the system tested and the normal person who does that work is not available? What happens on your project? Does it wait until The Expert is available?
|
|
|
Integrating Games to Change Behaviors, Part 2 Training people and introducing new ideas requires more than just clear, factual explanations or theorems. Brian Bozzuto explores how games, simulations, and other exercises play an instrumental role in helping people be comfortable enough with new ideas that they choose to put them into practice.
|
|
|
Agile Lifecycles for Geographically Distributed Teams: A Case Study In this case study of a distributed agile team, the developers were in Cambridge, MA, the product owners were in San Francisco, the testers were in Bangalore, and the project manager was always flying somewhere, because the project manager was shared among several projects. The developers knew about timeboxed iterations, so they used timeboxes. Senior management had made the decision to fire all the local testers and buy cheaper tester time over the developers’ objections and move the testing to Bangalore.
|
|
|
Agile Lifecycles for Geographically Distributed Teams: Using a Project Manager with Kanban, Silo'd Teams 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.
|
|
|
Management Myth #1: The Myth of 100% Utilization 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.
|
|
|
Empowering Agile Teams Teams, when truly empowered, will always make better decisions than any one individual. Where can you empower teams as you adopt agile?
|
|
|
Agile Leadership for Mid-Managers 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.
|
|
|
Specification by Example: Collaborating on a Scope without High-Level Control 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.
|
|