Improving the world with software
Better software. Better questions.
Essays on software development, teams and the craft of building things that last.
Essays from 2006, page 2
50 essays from 2006
-
Reducing waste
Tim Ottinger has a very good observation on his site about the importance of reducing waste and the difficulty of achieving it through Agile in organizations that are just starting. ‘Nuff said. Agile software development is all about eliminating collateral effort. No unnecessary documents, no unnecessary meetings, no unnecessary code, no unnecessary anythings. The mantra …
-
The Buzzword-maisters and the bad manager
Reading a very “true” post in 37signals about our industry’s preference and dependency on buzzwords I came to think of my own experience with buzzword-maisters and their terrible destruction path. It seems to me that in our industry managers think they are smart but are very often tricked into choosing a particular technology/product just because …
-
Why do we use Agile?
The question in the title of this post is an interesting one. Many people use Agile for the right reasons (because they think that it can help them with their work in many ways), but there are some people that do it for the wrong reasons: Because they like some part of one Agile methodology; …
-
Systems Thinking applied to software
Henrik Mårtensson has posted two good pieces on systems thinking and software development in his Kallokian blog. Check them out here and here. It is worth it. I especially like this paragraph at the end of the second piece: Organize to optimize the value stream (flow organization), not to keep people busy (functional organization)! Both …
-
It’s the motivation stupid!
This is something I’ve come across many times in my career. I constantly see motivated individuals excel against all odds and theoretically more prepared individuals fail when they should have made it with time left to spare. Now Jason Yip just linked to an article about that same fact: “Motivation is more important than innate …
-
Command and control method of management
From Joel: In other words, the military uses Command and Control because it’s the only way to get 18 year olds to charge through a minefield, not because they think it’s the best management method for every situation. Go and read it, especially if you feel you are in a Command and Control company 😉
-
Performance measurements can kill your efforts to bring Agile to your organization
Dave Nicolette has written a simple but really insightful piece on why performance measurement should be done with care and at the team level if you want an Agile team to gel and succeed. The bottom line: measure what your team produces and let them decide who is not worth to stay in the team …
-
Why BDUF does not work
I have a really hard time trying to convince colleagues at work that Big Design Up Front (BDUF) does not work, that it is waste and the more time you spend coding the more likely you are to reach a better design solution. But before we go deeper into this discussion it is worth defining …
-
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 …
Nothing matches that yet.
Keep the conversation going
The essays work best in company. Join the community to keep the questions coming.