A series of notes for a 1 hour seminar with readings and exercises.
Work styles
Work roles
Handling conflict
Productive environments
Relationship to project flow
Meetings
Group size
To team or not?
Appraising performance
Correctives and escalation
Thursday, 28 July 2011
Design Fail - hidden in plain view
Invisible to Normals: Glyph: From the Ballad of Halo Jones (2000AD comic strip). Glyph was neutral in many ways (but more importantly?) was completely unmemorable. Like the bleedingly obvious setting staring you in the face but completely invisible until it gets pointed out. Even worse when you repeat the whole process at some point in the distant future, "where was that setting again?" (Ballad of Halo Jones): via Oisin. (Trope link)
Wednesday, 27 July 2011
Engineers act in social ways to define technical problems
Consider the statement; 'that engineers act in social ways to define technical problems.'
If we accept the conclusions from Curtis et al's (1988) study into the key challenges of technology design work and recognise that the core problem of software development work is understanding what the problem is, how is it then that engineers set about finding out what the problem is?
If we accept the conclusions from Curtis et al's (1988) study into the key challenges of technology design work and recognise that the core problem of software development work is understanding what the problem is, how is it then that engineers set about finding out what the problem is?
Monday, 25 July 2011
How to manage development jobs?
How best to manage development jobs? The ancient assumption is to treat the work as a whole product in the form of a project, one of the most resilient and biggest ideas (assumption) underlying high-tech development.
The following posts (via the Agile Chronicles Newsletter) challenge this idea of the 'one big thing' that everyone works on.
Teams over Projects by Brian Bozzuto (June 27, 2011)
You may find this counter-intuitive, but I would posit that many traditional organizations use broad project portfolios as a means of achieving agility. With the heavy ramp up costs of any given project, having multiple options to respond to change. We can ramp up or down our energy on any given project based on changing circumstances or priority. While it’s not terribly flexible, it does offer some level of adaptability. However, it comes at the price of running all these projects at the same time, which is a very steep tax when you start adding up the cost of multiple status reports, daily or weekly meetings, code branches, design documents and any other overhead required for running your projects...
Do You Have Feature-itis? by Johanna Rothman (July 22, 2011)
Feature-itis. It’s an agile Product Owner game. It’s when the Product Owner says, in his or her best George Carlin voice, “Gimme Features. I don’t care about no stinkin’ framework.
Kanban, Scrum/XP and the Paradox of Constraints by Jim Bird (July 13, 2011)
If you find it difficult to break your work into time boxes, if your work is highly interrupt-driven like in many maintenance and support shops, then Kanban offers an alternative control structure. I am not sure that I buy into its manufacturing control-line metaphor, and that all of these ideas map well from manufacturing to the highly variable work involved in building and supporting software.
The following posts (via the Agile Chronicles Newsletter) challenge this idea of the 'one big thing' that everyone works on.
Teams over Projects by Brian Bozzuto (June 27, 2011)
You may find this counter-intuitive, but I would posit that many traditional organizations use broad project portfolios as a means of achieving agility. With the heavy ramp up costs of any given project, having multiple options to respond to change. We can ramp up or down our energy on any given project based on changing circumstances or priority. While it’s not terribly flexible, it does offer some level of adaptability. However, it comes at the price of running all these projects at the same time, which is a very steep tax when you start adding up the cost of multiple status reports, daily or weekly meetings, code branches, design documents and any other overhead required for running your projects...
Do You Have Feature-itis? by Johanna Rothman (July 22, 2011)
Feature-itis. It’s an agile Product Owner game. It’s when the Product Owner says, in his or her best George Carlin voice, “Gimme Features. I don’t care about no stinkin’ framework.
Kanban, Scrum/XP and the Paradox of Constraints by Jim Bird (July 13, 2011)
If you find it difficult to break your work into time boxes, if your work is highly interrupt-driven like in many maintenance and support shops, then Kanban offers an alternative control structure. I am not sure that I buy into its manufacturing control-line metaphor, and that all of these ideas map well from manufacturing to the highly variable work involved in building and supporting software.
Subscribe to:
Posts (Atom)