Improving the world with software
Better software. Better questions.
Essays on software development, teams and the craft of building things that last.
Essays, page 24
314 essays in the archive
-
Agile does not give you recipes, it makes you use your brain…
In a post in the Agile project management mailing list somebody asked if it would not be time for an Agile Project Management Body of Knowledge book (APMBOK) inspired, probably on PMI’s PMBOK, the Project Management Body of Knowledge. What I think about this question is that PMBOK and Agile represent completely different approaches to …
-
Don’t stand there, just do it!
Brian Marick in his blog talks about the trend he is noticing at Agile 2006 of people talking about leadership as the “silver bullet” to implement Agile (my interpretation). I could not agree more with this comment, that kind of leadership is not what Agile needs. Agile needs old-school managers to learn to stop wanting …
-
We always tested/refactored, we just did not do it right or called it that…
I was browsing the software blogosphere and ran into this post by David Chelimsky about why he started doing TDD and refactoring. I just could not help to see my own story in that post. Was it like that for you too?
-
Chaordic projects and the empirical quest
The scientific process relies heavily on empirical observations. We must, in the software development industry, also rely on empirical observations of successful software development projects and follow the learnings from those projects. With software development projects the hard part is that most of what happens is not quantifiable and if it were – by decomposing …
-
At last, more on the XP 2006 conference
XP 2006 Conference, Day 2 highlights During the second day in the conference I attended the scientific paper session in the morning. Of the three papers presented the most interesting was the one on TDD and the effects it has on how we develop code. The gist of the paper was that in order to …
-
Hard value versus System value of Agile Methods
First a clarification. I’ve used “hard” value as opposed to “system” value in this article, and my definitions are:“Hard value”: any value that can be or is systematically quantified in terms of money or time and normally focus on details (e.g. the value of TDD, the value of incremental development).“System value”: any value that can …
-
Day 1 at XP 2006 conference, part 2
During the morning session for today I attended the research paper session presentation on “Foundation and rationale for agile methods”. There were four papers: Distributed cognition account of mature XP teams: in this paper presentation the thing that struck me the most was the practice of “fluid pairing” as described by the presenter. In this …
-
Day 1 at XP 2006 conference, part 3
The last event for today was the keynote speech by Brian Hanly (acutally it was Sean Hanly who did the keynote, thanks Lasse for the correction), founder and director of Exoftware which is a major sponsor for the conference. His point in the talk was that Agile needs to cross the chasm of adoption from …
-
Day 1 at XP 2006 Conference
The day started today with a talk from Pekka Himanen about the Hacker Ethic. His introduction on how the Open Source development teams are able to produce so much and so high quality code was interesting as it was rooted on his Learning Philosophy and how interaction between people can make a team/community much more …
-
Highlights of Sunday tutorials on XP 2006 conference
Yesterday was my first actual day in the conference here in Oulu. The day started for me with the tutorial from Mary Poppendieck about Lean (Agile) Software Development. I had read her book and learned from it a lot. In the tutorial she touched on several interesting aspects that are not very obvious from the …
-
XP 2006 conference starts
Today started the XP 2006 conference here in Oulu. I have a lot of positive expectations regarding this conference. Reading the proceedings from last year’s conference I got a lot of great ideas to apply in my work, I expect that this year, being present will be even more productive.
-
What “done” means and it’s importance.
Today a colleague at work described his experience with one of the principles of Scrum: “Done means done”.This very simple phrase has very deep implications. One is that you are never really done until a feature is ready for release. Some teams will define that differently, but his team defined that “ready for release” meant …
Nothing matches that yet.
Keep the conversation going
The essays work best in company. Join the community to keep the questions coming.