I really liked J. Schwan’s blog on Oscar and Albert. It’s a workplace parable about overcoming (or denying) the realities of off-shoring.
Sometimes it’s difficult to admit to ourselves, but in IT we are judged by more than how we do our specific jobs (even when it’s hard to find anyone who can do your job better than you). Honing our skills beyond a certain point (and to the exclusion of other, newer skills) can make us less competitive in both our local and global marketplaces.
This is not so much about a .Net programmer learning Ruby (although that certainly can help until Ruby becomes old hat). It is about a programmer taking a greater role in requirements definition, usability, user training, or any other area that enables him (or her) to build his capabilities and deliver value at the business level.
Tomorrow’s rewards will be won by the IT workers who focus on broadening their perspectives and adapting their skills. They’ll use this mindset to identify and satisfy the numerous new value opportunities created by our evolving global marketplace. Far from being out-sourced, many will get wealthy doing it.
No Comments »
Agile teams use the retrospective to collect a set of start, stop, and continue actions at the end of each iteration. The point of this technique is to collect feedback as a team and focus it (through one of the above verbs) into actionable steps toward improvement.
But retrospectives often produce a dozen or more actionable steps, and teams can grow nauseous from seeing the same things show up retrospective after retrospective with little or no progress made. So, how does a team break this cycle?
By prioritizing only one or two activities as goals for the next iteration.
It’s hard to remember to work on a dozen (or even half a dozen) things at once, even when you don’t have an iteration of work to complete at the same time. Remembering to focus on one or two goals is much easier, especially when your entire team is also thinking about those same goals.
Finally, the team needs to close the loop by discussing the outcome of each goal in the next retrospective.
- Did everyone really take the agreed-to steps to meet the goal?
- Was there a beneficial outcome?
- Should the team focus on the same goal in the next iteration?
- Was the outcome different than expected?
- Should the team take different steps to achieve the goal?
And there you have it: continuous improvement.
No Comments »