I’m working on this idea, and I don’t know if it appeals to you guys. I’d like your input on whether this is something to explore further. Here’s the deal: I’ve encountered teams who, when working with SOA technologies have been dragged into the mud by the sheer complexity of their tools. I’ve only seen this in Java, but I’ve heard from some C# developers that they recognize the phenomenon there as well.

Changing your perspective even a small amount can have profound effects on how you approach your system. Let’s say you’re writing a web application in Java. In the system you deal with orders, customers and products. As a web application, your classes include staples like PersonController, PersonRepository, CustomerController and OrderService. How do you organize your classes into packages? There are two fundamental ways to structure your packages. Either you can focus on the logical tiers, like com.

An “Agile” project is one that actively seeks to incorporate changes as the project progresses, rather than assuming that the plans from the beginning of the project will work for the whole project duration. Not all organizations want to adopt “agile” as their project metaphor. And some organizations that do adopt methods such as Scrum do it without becoming as “agile” as Scrum promises. Instead of criticizing these organizations of “agile heresy”, I would instead like to offer some useful experience from Scrum, even if the word “agile” doesn’t appeal to you.

I hate giving promises for things I can’t control. I can promise that I will attend a party or that I will set aside time to help you with your problem. I cannot promise that the party will be fun or that your problem will be solved. Giving promises on effort is honest, giving promises on outcomes is dishonest. A team that commits to an estimate is promising something they cannot control.

As a user, I can add social security number, so patient logs have social security numbers As a developer, how would you react if you were given this user story? Would you throw it back in the face of the product owner, or would you try and understand it? How about the following dialogue? Developer: “What are we hoping to achieve with this story?” Customer: “We hope that the patient logs will have social security numbers.

Do you know how to apply coding practices the technology stack that you use on a daily basis? Do you know how the technology stack works? For many programmers, it’s easy enough to use test-driven development with a trivial example, but it can be very hard to know how to apply it to the problems you face every day in your job. Java web+database applications are usually filled to the brim with technologies.

I recently attended the XP Days Ukraine conference in a rainy, but beautiful and Christmas-decorated Kiev. I conducted a coding dojo and gave a talk where I demonstrated pair programming live together with Dima Mindra. After the talk, I got a few questions about how to run a Coding Dojo. This article is meant as a guide to anyone wanting to start up a Coding Dojo, whether it’s in Kiev (Mikail/Aleksey), in Odessa (I’m looking at you, Dima!

The next half year, I’m scheduled to give the talk “Experience Agile Programming” in Kiev, Gothenburg and Riga. In the presentation, I pair with a local developer and show a coding kata in Java, Ruby or CoffeeScript. After the presentation, I engage the audience in a discussion of what they saw, when they would use it, etc. I might also show a few more programming tricks if time permits and the audience requests it.

Instead of using Scrum, maybe we should use MyScrum. It’s like Scrum, with the stuff added that you think will super charge your MyScrum. This is my MyScrum: I want to measure velocity every week I want to demostrate the product with a cadence that makes sure users show up to the demo I don’t want to have story point estimates, I want to have story point budgets I want the product owner, not the team, to own the budget/estimate (but they team may veto) I don’t want commitments or forecasts from the team, I want measured historical progress I want to plan per story, not per sprint I want the developers who will develop a story to follow it (or pass the baton to other developers) from detailing to deployment.

The term Extreme Programming (XP) was coined in the nineties. Originally, it described a set of practices that have mostly been widely adopted today. Among these practices were continuous integration, test-driven development, user stories and frequent releases. These practices are hardly radical or extreme today. So what does “extreme programming” mean now? To me, the idea behind Extreme Programming can be summed up as follows: What would happen if we take what we know works, and do it to degree that seems at first unreasonable?