Skip to Content »
online discount medstore
advair diskus for sale
buy advair diskus without prescription
allegra for sale
buy allegra without prescription
aristocort for sale
buy aristocort without prescription
astelin for sale
buy astelin without prescription
atarax for sale
buy atarax without prescription
benadryl for sale
buy benadryl without prescription
buy clarinex without prescription
clarinex for sale
buy claritin without prescription
claritin for sale
buy flonase without prescription
flonase for sale
buy ventolin without prescription
ventolin for sale
amoxil for sale
buy amoxil without prescription
augmentin for sale
buy augmentin without prescription
bactrim for sale
buy bactrim without prescription
biaxin for sale
buy biaxin without prescription
buy cipro without prescription
cipro for sale
buy cleocin without prescription
cleocin for sale
buy dexone without prescription
dexone for sale
buy flagyl without prescription
flagyl for sale
buy levaquin without prescription
levaquin for sale
buy omnicef without prescription
omnicef for sale
amaryl for sale
buy amaryl without prescription
buy cozaar without prescription
cozaar for sale
buy diabecon without prescription
diabecon for sale
buy glucophage without prescription
glucophage for sale
buy glucotrol without prescription
glucotrol for sale
buy glucovance without prescription
glucovance for sale
buy micronase without prescription
micronase for sale
buy prandin without prescription
prandin for sale
buy precose without prescription
precose for sale
buy cialis professional without prescription
cialis professional for sale
buy cialis soft without prescription
cialis soft for sale
buy cialis super active without prescription
cialis super active for sale
buy cialis without prescription
cialis for sale
buy levitra without prescription
levitra for sale
buy viagra professional without prescription
viagra professional for sale
buy viagra soft without prescription
viagra soft for sale
buy viagra super active without prescription
viagra super active for sale
buy viagra super force without prescription
viagra super force for sale
buy viagra without prescription
viagra for sale
buy celebrex without prescription
celebrex for sale
buy colcrys without prescription
colcrys for sale
buy feldene without prescription
feldene for sale
buy imitrex without prescription
imitrex for sale
buy inderal without prescription
inderal for sale
buy indocin without prescription
indocin for sale
buy naprosyn without prescription
naprosyn for sale
buy pletal without prescription
pletal for sale
buy robaxin without prescription
robaxin for sale
buy voltaren without prescription
voltaren for sale

Tech Life of Recht » archive for 'SCRUM'

 X Driven Development

  • 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.

 Talking too much?

  • February 11th, 2008
  • 5:58 pm

Today we had a discussion about which agile practices work, and why some tasks just seem to take longer than necessary. One of the reasons seems to be that we don’t really reuse concepts and components very much. Every scrum team has responsibility for meeting their goals and satisfying the customers, but nobody is focused on maintaining a somewhat common architecture, and practices, both good and bad, are not communicated reliably to other teams.
This is not necessarily bad. Most of the developers are pretty bright people, who actually work at companies like Trifork because that way they won’t get some Enterprise Architecture(tm) pushed down their throat. Instead, there is an expectation that everybody will strive to do their best for the project.

The whole agile culture empowers the developers – this is one of the core ideas. The developers get to speak directly with the customer, design solutions, implement them, test them, document them – generally the developers are responsible for as much of the development as possible. A good thing, but maybe developers sometimes have a little too much to say. I don’t particularly like the term architect (mostly because “whiteboard” should have been prepended), but having Scrum teams without a proper architect doesn’t really seem optimal in the long run. By proper architect I mean one who has the capacity to create consistency across projects, and take decisions about key components, languages, and so on. The architect shouldn’t necessarily make all the decisions, but some things are just not worth discussing again and again. Examples of this could be whether to use a coding standard or not, or whether to include a completely new and untested technology. Another classic seems to be that decisions are never final. This means that somebody might spend time in integrating a new tool or component, even though an earlier decision was made against it.
Granted, some of the decisions made on a project are just plain wrong, at least in hindsight, but it just seems that experimenting with new technologies on a project which is due to deliver a working product isn’t the best idea.

As usual, the problem comes down to communication. Scrum and XP handles team communication pretty nicely. We have daily scrums, iteration meetings, retrospectives, and so on, but there are no practices to establish inter-team-communication. You could, of course, go for something like CMMI, which has almost complete focus on organization-wide communication, but that just doesn’t sound very good (theoretically it should be possible, though. My master’s project was about exactly this). In other words, we need some solid agile practices for enabling communication across the organization.

I wish I had some good ideas as to how this should be done. Ask Jeff Sutherland, and he’ll probably begin talking about scrum of scrums, basically arranging teams hierarchically, and letting the scrum masters communicate between the teams. On the face of it, this looks like a good solution, but somehow I don’t quite like it. In really large organizations, it’s probably the only way, but is it appropriate when you have 50-100 developers?

My best proposal is to separate the day-to-day development from the talking and the experimenting. Development happens in scrum teams, and the teams live their own lives, but the design decisions are coordinated with what we could call architects. Maybe librarians would be a better title, because their main purpose is to know what others are doing and have done, what has worked, and what has not worked. The talking and experimenting would take place at other times. This could be the 20% time which Google employees have to spend on something else, it could be something like the JAOO meetups at Trifork, it could be video blogs. Basically anything, the important thing to somehow promote a culture where both learning and teaching is essential. Of course, this requires some ongoing investment from the organization, like the 20% time.
If this separation exists, we as developers might be able to focus better on creating actual value, and we might also become better at learning from each other. It’s important to notice that the separation is there to avoid too much distraction when developing. However, everything good and bad that comes out of the talking and experimenting should be taken into consideration when making important architectural decisions – it’s just a question of where the experimenting takes place, and when the results are brought back into a project. Most of the time, our projects are relatively short, so after committing to some architecture, it doesn’t really pay off to change it.

I expect some of this will be addressed, for example at future JAOO and QCon conferences. In the meantime, it would be nice to hear about inter-team communication patterns – how to ensure common knowledge, and how new ideas, technologies, patterns, principles, and so on can be distributed in an organization full of independent teams.

 Celebrity status attained

  • June 21st, 2007
  • 11:42 pm

As some might know, at Trifork, we’re like Scrum quite a lot – just about everybody at the company is a certified ScrumMaster (mostly certified by Jeff Sutherland). Now you can also get the World Tour T-shirt, which is nice in itself, but guess who’s doing (half of) the modeling? You guessed it! That’s me on the picture, and no, I hadn’t shaved in a couple of days. One can only wonder why I was picked…