A core part of Scrum and many other Agile methodologies is ‘inspect and adapt.’ Retrospectives are a key practice in reviewing the last iteration. You toss up on stickies or a white board the ‘What Went Well’ and ‘What To Look Into.’
- Pick one or at most two things on the list to work on for the next iteration.
- Only pick something that at least one person in the room has the energy to take on. If no one has the energy for the next iteration don’t try to force change.
A sign of team self-management success is when the Scrum Master is out or busy and someone just fills in. I’ve known one of our Scrum projects was moving along pretty well, but our organization still has a tendency to try to have another PM fill in at the daily standup. In the old command and control phase this made sense, but with a self-managing team it just becomes a minor impediment. Today I left a Scrum meeting with a big smile as one of the business analysts on the team had facilitated the standup.
Next step is having a rotating facilitator instead of always looking for the Scrum Master to lead.
A single number representing whether you’re six months worth of coding is actually not crap. Not code coverage, Checkstyle warnings or defects per thousand lines of code but a single score.
CRAP(m) = comp(m)^2 (1 - cov(m)/100)^3 + comp(m)
m = method comp(m) = Cyclometric complexity of method m. cov(m) = Test code coverage for method m.
In written terms:
Complexity bad. Tests good.
Right now there’s just an Eclipse plugin to try it out. Anything with a Crap number of 30 or above is a crappy method. And any project with more than 5% crappy methods is a crappy project. Alberto explained they wanted it to be an Agile metric so that it actually got used out there and part of that was keeping it simple. The other factor is it can easily be adjusted based on feedback and running it against many codebases.
What if you have a CRAP codebase? You can attempt to game the number to bring down the number of crappy methods. And how do you do that? You just write more tests against the high CRAP methods. And then it starts to occur to you that you could refactor as well. Gaming the system is writing tests plus refactoring. You can focus on a single number and encourage good behavior.
Assumption was soon after installing the developer tools for Mac OS X 1.5 Leopard I’d have a brand new spanking copy of Java 1.6 on my MacBook Pro.
$ java -version java version "1.5.0_13" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-237) Java HotSpot(TM) Client VM (build 1.5.0_13-119, mixed mode, sharing)
OK, surely it’s just defaulting there. Nope, no 1.6 version. No problem it’s supposed to be on the Apple Developer web site. I’ll just have to download it. Turns out there’s no mention of 1.6 at all. There’s the 64 bit support for 1.5 on Leopard, but no mention of 1.6. And there’s plenty of historical references to the Apple Developer site having downloads of Java 1.6 in the past, they’ve just pulled them all off the web site.
OK, we’re still not using 1.5 at work yet, but it would be nice to run 1.6 at home.
Dave Nicholette argued recently that Enterprise Architecture and Agile are not compatible partners:
The mission, scope, tools, mentality, culture, and personality types of enterprise architects and agilists are so radically different that (in my view) they call for separate administrative subdivisions in the enterprise. Not only is the nature of their work different, but the management styles, employment incentives, and career path options that work with one group don’t work with the other. The staid working conditions and deliberate pace of progress of enterprise architecture work would bore and frustrate an agilist. Conversely, the intensity and unpredictability of agile development would stress out the type of person who tends to prefer things standardized and repeatable.
I’m taking a little different tack on the meshing of Enterprise Architecture and Agile. Enterprise Architecture is a holistic attempt to define systems, processes, and tools across the entire organization though much of the focus ends up on the IT functions. Agile is a process within this and as it facilities better projects and faster ROI it lines up well with the goal of Enterprise Architecture. The central goal of Enterprise Architecture is to simplify IT.
Architecture within an Agile project is continuously evolved, but with the end goal that it should remain as flexible as possible while delivering at each iteration. You want the system to be as lean as possible, you shouldn’t be writing speculative code that might be used in the future.
Traditional ‘Ivory Tower’ style Enterprise Architecture does clash with Agile as it assumes a command and control culture with a heavy focus on governance. I see no reason Enterprise Architecture can’t be done in an Agile fashion. Even analyst firms like Gartner agree that defining a future architecture and then sticking it on a shelf never to be revisited is a recipe for failure. My belief is Enterprise Architecture efforts are only going to be successful through collaboration with developers, testers, business analysts, PMs/Scrum Masters, and business customers. And the critical cycle of ‘inspect and adapt’ on Agile projects is just as crucial to Enterprise Architecture.
My suspicion is with Agile and Lean ‘crossing the chasm’ lately we’re likely to see big changes in the approaches to Enterprise Architecture in many shops.