Technology and process innovation
In an agile/lean software development team, discussion is invited, but coordinated. I've noticed that people who are passionate about technology or process often feel friction if they don't get a good hearing for their idea. Equally, the technical/process leadership have to help everyone on a team achieve consistency. Regardless, there should be no "status quo"...
I've been playing around with a pipeline approach to technology/process, where the team can
- achieve consensus on the current state, and next steps
- get rid of things that aren't working
- propose blue-sky ideas
- get support for taking almost-working ideas through to completion
So, every iteration, we can build up a map of our technologies and practices, and then select and shine the elements that we think are important.
- Deprecated - was useful once, but we should remove uses of this practice/tech when it is found
- Definite - should be (and is being) used unless it is seriously mismatched to the problem at hand
- Sound - this is a really good, proven idea/tech that isn't being used yet (or only sporadically), but we think it should be adopted
- Tentative - this would be really good, but it might have some issues that make it unsuitable
- Radical - as a concept it solves some problems we're having, but it may raise more issues than it solves
For instance, we might have the following map (example: for a Java based web site)
- Deprecated - Struts, JDK 1.4
- Definite - JDK 1.5, Struts2, Spring Dependency Injection, Maven, Hibernate, Continuous Integration, CVS
- Sound - Test Driven development, Subversion, Freemarker
- Tentative - BDD and acceptance criteria executed with Rspec and selenium, continuous pairing
- Radical - Scala
- Out - consensus is around not using this tech (e.g. .Net on a java project to name a simplistic example)
This is just a snapshot. You can see a mix of practices and technologies here.
Each iteration (for some value of each), I would like the team to produce the following:
- System guardians for each definite technology/practice
- A safety-factor of 1-5 from each team member for every element on the map
- A vote/score for each sound/tentative/radical idea on the map - this is the priority associated with adoption
- Actions that can be taken to move prioritized items towards definite (for instance, a 15 minute "topic of the day")
In this way, there is a collaborative understanding of what works, what doesn't, and what we are doing about it.
Some thoughts around this:
- I think it's OK for a initially unpopular idea to stay up on the map, because it allows the proponent to feel included, and it stays in the collective memory for times when the idea is the right one.
- No definite process/technology is immune from deprecation - although part of the criteria for moving from sound to definite is to address issues of how to phase out the old process/tech
- Items can be split - there are situations where a technology provides some benefits, but only if it is used in a particular way. So, Spring DI may be definite, but Spring MVC may be out.
- A lot of discussion around these things will happen in the retrospective anyway, but the innovation map should be persistent and displayed on the team room wall.
- The "system guardian" pattern is great for identifying subject matter experts, and then making them able to move on to other areas. Essentially, each system guardian is responsible for finding 2/3 other people and paring with them until they are also system guardians. Once you have 4/5 names as guardians, the knowledge will propagate quickly.
The DebtStream Guards
In agile delivery, there is often a pattern of reserving a pair or two (depending on team size) for technology and process maintenance - the technical/process "debt" stream.
I've used this stream effectively to
- Simplify the build
- "Proof of concept" 3rd party software integration
- replace crufty code with a big restructuring
- etc...
This team is rarely made up of the same people. In fact the idea is often to seed a pair who will then roll into the main streams of development, spreading their experience, and backfill them.
posted by Nick Drew @ 9:40 am
0 Comments:
Post a Comment
<< Home