The Limits of Energy
Saturday, November 17, 2007
Sometimes people just won’t do what you want them to do—what they should do—no matter how hard you try to persuade them. Why is that? (Continued)
Sometimes people just won’t do what you want them to do—what they should do—no matter how hard you try to persuade them. Why is that? (Continued)
I’m just back from XPDay Manhattan, one of those small conferences that Matt Heusser and I have praised before. This conference was a mix of prepared talks and open space. I think this is an excellent format. It provides material for those who haven’t yet identified a topic they want to discuss, and it also draws in active participation from the attendees. The participation was enthusiastic! Some people traveled a considerable distance to attend.
Coming up very shortly is the Simple Design and Testing Conference. This is an open space conference in York, PA starting Friday evening, November 30, at 5:00 PM and running through Sunday lunch, December 2. Last year’s was my first experience with the open space format. This year, Naresh Jain, the organizer, is asking people to submit a position paper with their registration application. This doesn’t have to be a big thing, and I don’t think anyone will be denied based on the content or position taken. The point of this exercise is to encourage participants to think ahead about the issues that are important to them. It’s a small price to pay for a free conference. I hope this helps fan the flames of passion for the craft and career that you’ve chosen.
P.S. The slides from my prepared talk are available.
Or the business customer?
As I talk with developers and team leads who are leading agile initiatives in mostly non-agile companies, I continue to hear comments about managers who “don’t get it,” and Product Owners who won’t participate, and other complaints that suggest that not everyone has reached the new status quo (per Satir’s Change Model). Sometimes communication issues seem to be delaying progress. Sometimes some of the participants don’t seem to be aligned with the goals of the agile team. At least, it appears that way from the developers’ point of view. In all honesty, perhaps the agile team is not yet aligned with the business needs.
I’m trying to get the point of view from the other side. When these problems arise, I want to know how the Managers and Product Owners feel about the way things are going. Surely they see things from a different vantage point, and have different insights. I’d like to know what those insights are.
I’m looking for real stories and feelings–not descriptions of the way things are supposed to work. I want to know what you see happening (or not happening) around you. I realize that such real-world stories may be a little too sensitive to post in public comments. If you’d like, email them to me at blog-response AT gdinwiddie.com and I’ll keep them in confidence.
And if you’re not an upper manager or product owner, but you’re having difficulty with one. Please ask them how things look from their side and let me know. Or have them let me know. Or invite me to come and discuss it with both of you. I’m really interested!
Do you have a hard time keeping track of those articles that you read and think “I could have used this when I was talking to ….?” Do you sometimes need an article to back up a point that you’re making, but don’t know where the data is? Well, I do. I’ve started lists a number of times, and keep misplacing them.
This time is different. When a discussion on one of the mailing lists got into studies demonstrating the effectiveness of Agile Software Development, I decided to start a list in a place that won’t get lost. That place is http://biblio.gdinwiddie.com/, the Agile Bibliography Wiki.
I’d really appreciate it if you’d use it too.
The new Carnival of the Agilists is focused on the Agile 2007 conference. You’ll find a bunch of references to blogs discussing the conference. There’s some interesting stuff. There’s even a pointer to my good friend, Jack Ganssle, who is not an Agilist and is highly allergic to people touting a New Methodology. Jack is interested in things that work, and work well. I was glad to see he had some good things to say. The reason he did, is that people talked about things they had done and the results they got from doing them. Telling those stories works ever-so-much better than telling your theories.
I found it amusing that the first response to the Carnival of the Agilists post was one complaining that the drinking water wasn’t obvious enough, being provided in coolers instead of bottles. All I can say is that if this is the biggest complaint, the conference was a great success!
Pair programming has been widely touted as a effective means of generating excellent code in a cost-effective manner. It has also been widely reported as a waste of time or as uncomfortable. Many people reject pair programming without trying it. Others, however, still don’t like it after being forced to use trying it.
I’m convinced that there’s an art and a science to pair programming. I don’t think it comes naturally to most people. It’s sometimes easy to pick up by osmosis, but I’ve heard too many complaints about pairing to think that’s a common occurrence. I’d like to hear your real-life stories about pair-programming situations. If you don’t feel comfortable leaving your story as a comment on this blog, send them to “pairprogramming at idiacomputing.com”. (Continued)
Back in March of last year, David Maister was interviewed by Wayne Turmel and he said some amazing things. I’ve been meaning to talk about this for some time, but the work of transcribing from audio has tempted me to put it off. I highly recommend listening to the whole thing.
David Maister is a business consultant, but what he says here is extraordinarily appropriate for most of us technical people, too. He describes starting out with the same vision of success that I had, and how completely wrong it was. (Continued)
The Carnival of the Agilists has posted a new issue. Every two weeks, they post a pointer to the interesting articles in the Agile arena. If you can’t keep up with all the blogs and mailing lists and online publications, this is a good way to hit some of the high points.
I’ve never really liked stored procedures. I always put it down to the fact that I’m a programmer, not a database person. I like keeping the functionality in the code. The database is just a place where objects go when they sleep.
My current client uses stored procedures for all database reads and writes. It probably made sense when the code was ASP, but Java JDBC code has all the expressibility you could want.
Today, I learned a new reason to not like stored procedures. (Continued)
Esther Schindler, a senior editor and columnist at CIO.com, recently asked on the agile-testing yahoogroup,
If you could get the (client) boss(es) to understand JUST ONE THING about computer consulting and contracting, what would it be?
It would be that software development is not a commodity. The cost-value equation is not just enhanced by cutting costs, but more effectively, by enhancing value. It’s not just a matter that software is produced, but what software is produced. Does that software clearly express the nature of the business? Is it an asset that can be extended and adapted as the business grows and changes? All too often, the only measure applied seems to be the hourly cost of the software production (neglecting even the number of hours required). Too often I get the feeling that I, the consultant, pay more attention to the long-term value to the company than do the employees and executives of the company. (Continued)