Projects for the public sector have, for a long time, had a reputation of being overspecified, tightly controlled, contract-focused, and in many cases badly managed. Some call them waterfall projects. Luckily, it’s been a while since I was on a project like that – the projects I’ve worked on, also for NITA have been run as Scrum projects with a good amount of success. It has, however, mostly been smaller projects – a month or two, and without any real focus on the process from the customer’s side. Now it looks like we’re finally heading away from the classic waterfall approach, as NITA has openly confessed to Scrum (in Danish only). Just as important, Trifork is helping both with Scrum and doing the implementation. I’m not on the project at the moment (still busy with OIOSAML and REST), but I’d be surprised if I didn’t get involved at some point.
Tech Life of Recht » archive for 'methodologies'
- May 18th, 2008
- 2:36 pm
- March 13th, 2008
- 9:45 pm
As I wrote earlier, I spent the first three days of this week on a Kent Beck courseQCon London to give a keynote with more or less the same overall message as in the course: accountability and responsibility is just about everything. When you take responsibility, you earn trust, which again enabled you to have a better relationship with other people, including developers, customers, managers, and so on.
One interesting bit came up in regard to discipline. I’ve always said that XP and agile processes take discipline to implement and use. Kent Beck’s take on this was that it was just the opposite – not doing XP was hard for him. Instead, it’s more or less a question of habit, which is where the problem often lies: Changing part of yourself requires an investment, but it’s not completely clear when the investment will yield a profit. Ironically, this economical argument is also used to promote XP: push the cost into the future and pull the profit closer – for example by releasing often, not gold plating, and so on.
Adopting an agile process then becomes a question of how you change habits, and keep from falling back into the old ones. Leadership is one way, double- and triple-loop learning is another, and there are probably many more. Incidentally, this is exactly the subject I worked with at university together with Michael with just about the same results.
- February 28th, 2008
- 1:41 am
There’s a lot of xDD (x Driven Development) going around, and there has been for some time. Some are somewhat official, like Test Driven Development, but there are many others. A number of them should probably just be left alone to die, some are just plain stupid, but still… You don’t want to get caught in a conversation where you suddenly can’t give you opinion on Blog Driven Development. So, here’s the unauthoritative list of methodologies sorted by name, not relevance:
Acceptance Test Driven Development – Focus on real-life test scenarios.
Accountability Driven Development – make sure someone’s always accountable. Beware not to fall into Blame Driven Development.
Annoyance Driven Development – let your annoyances guide you. Probably best on one-man projects.
Asshole Driven Development – Let the biggest asshole make all the decisions. Also known as Jerk Driven Development.
Behavior Driven Development – Like Test Driven Development, just with better language.
Blog Driven Development – Think about how to appear smart on your blog, and implement something like that.
Budget Driven Development – Each man is allocated a maximum number of lines which can be added. A little like SCRUM, just with lines of code instead of hours.
Bug Driven Development – Implement program, release, fix bugs, repeat.
Comment Driven Development – Write code comments, then implement what you’ve described. Like Test Driven Development, just without the tests.
Configuration Driven Development – Store everything in configuration files.
Data Driven Development – Start with the data and work your way up from there.
Design Driven Development – Design is art so remember to add the right people.
Development Driven Development – Concentrate on developing instead of testing.
Dialogue Driven Development – Remember to talk to the client and ask questions.
Documentation Driven Development – Write the documentation first, then the code.
Example Driven Development – Write down examples, clear them with the client, then implement.
Feature Driven Development – Focus on developing value-adding features.
Language Driven Development – Use any language you want.
Meeting Driven Development – Don’t code before having a meeting. In fact, don’t do anything without a meeting first.
Model Driven Development – Let the developers off and give the users access to visual programming.
Muffin Driven Development – Punish developers by forcing them to give muffins when they make the builds fail.
Principle Driven Development – Go for the simple solutions.
Process Driven Development – Analyze the business processes, then model the system from that.
Proof Driven Development – Build small vertical slices of an application. Like prototypes, just the other way around.
Reality Driven Development – Take a look at what’s going on in the real world and learn from it.
Requirements Driven Development – Get a hold of your requirements and make the developers work based on them.
Resume Driven Development – Look at your resume and do whatever looks good on it.
Search Driven Development – Delegate responsibility and knowledge to Google.
SKU Driven Development – Strip down your solution to a minimal core, then make addons available.
Specification Driven Development – Add formal contracts to Test Driven Development.
Squiggly Driven Development – Write some code, check if there are any compile errors. Fix them. Proceed.
Story Driven Development – Write stories about your product before writing code.
Test Driven Development – First, write some tests, then make them run.
Wiki Driven Development – Somewhat like Documentation Driven Development, just with a Wiki.
If you want to be Scrum-compliant, add Agile to any of the titles. My own contribution to the list will be “Methodology Driven Development”, which occurs when you look at the list above, and pick one or more to implement in your project.
Of course, the list is probably nowhere near complete. If I’ve left something (un)important out then just comment on it.