There has been some discussion and even minor ranting about the lack of technical content at Agile 2010 in Orlando:
Uncle Bob Martin:
I had similar conversations with Mike Hill and Joshua Kerievsky. I suppose even my session, Confessions of a Flow Junkie, could be considered non-technical since I only touched on Automated Testing as something that promoted Flow and didn't delve into the details.
So, what's different? Why does this seem to be the case? I agree completely that we could certainly use a renewed focus on technical skills, and am quite interested in the announcement about XP Universe 2011 by Corey Haines. I can also say that I attended 4 technical sessions at the conference - one by Rebecca Wirfs-Brock, one by Arlo Belshee, one by Llewellyn Falco and Jason Kerney and one by Josh Kerievsky. Those were the least well-attended of all the sessions I went to, excepting one that was listed as 'Expert'. I remember thinking more than once,
In one of the closing keynotes by Ron Jeffries and Chet Hendrickson, highlighted this very point:
I've been told many times now by both developers and managers that microtests take too long to write, but no one has told me how long it takes them to debug a problem. I have sat with developers looking over unnecessarily complex Java/C/C++/C# code, and was told that it wasn't their fault that the code was such a mess, and that they didn't have time to clean it up. I've literally been laughed at and told that a goal of 0 defects is a pipe-dream (with that exact term used).
I call bullshit.
We know how to write code that is for all intents and purposes defect free. We know how to adjust the structure of code over time to reduce technical debt and keep it flexible and understandable. We know how to do these things, but because they are more difficult to learn than a daily standup meeting, we don't do them.
I believe that's why the 4 technical sessions I attended didn't have the same size audience as the session on Scrum Metrics that, in my opinion, was bordering on the sale of snake oil. I believe that's why only 10% of the sessions in the conference were oriented towards the technical practices - the popular topics aren't in the technical realm. Does that mean there wasn't value in the other 90%? Hell no - my head is still spinning after Jeff Patton's excellent session, "Beyond Sprint 0: Using Collaborative Product Discovery to Plan Agile Projects".
The revival of XP Universe, the ascent of the Software Craftsmanship movement and the creation of groups such as the Agile Skills Network are all indications that we're once again acknowledging the elephant in the room that is the industry's horrendously poor track record with respect to low-level technical quality.
Considering civilization's current and growing dependence on software, that revival is occurring not a moment too soon.
Uncle Bob Martin:
Programmers started the agile movement to get closer to customers not project mangers.And again:
< 10% of the talks at #agile2010 are about programming. Is programming really < 10% of Agile?
I had similar conversations with Mike Hill and Joshua Kerievsky. I suppose even my session, Confessions of a Flow Junkie, could be considered non-technical since I only touched on Automated Testing as something that promoted Flow and didn't delve into the details.
So, what's different? Why does this seem to be the case? I agree completely that we could certainly use a renewed focus on technical skills, and am quite interested in the announcement about XP Universe 2011 by Corey Haines. I can also say that I attended 4 technical sessions at the conference - one by Rebecca Wirfs-Brock, one by Arlo Belshee, one by Llewellyn Falco and Jason Kerney and one by Josh Kerievsky. Those were the least well-attended of all the sessions I went to, excepting one that was listed as 'Expert'. I remember thinking more than once,
"Wow - the people who need to be here, um, aren't."My experience as a coach is that people are learning and using the management practices of Scrum reasonably well, but they're only scratching the surface of what they can do with the technical practices. I see plenty of development teams starting to use an automated build (and incorrectly calling it Continuous Integration), and that's a good thing. However, precious few are writing Microtests, Refactoring, using Simple Design, and truly using Continuous Integration.
In one of the closing keynotes by Ron Jeffries and Chet Hendrickson, highlighted this very point:
Scrum is so simple that if you actually did it, it has to work!Exactly. The technical practices that became part of XP aren't as simple. They take time to learn and integrate, and thus they aren't as popular. Once you have integrated them, though, they are indeed easy.
I've been told many times now by both developers and managers that microtests take too long to write, but no one has told me how long it takes them to debug a problem. I have sat with developers looking over unnecessarily complex Java/C/C++/C# code, and was told that it wasn't their fault that the code was such a mess, and that they didn't have time to clean it up. I've literally been laughed at and told that a goal of 0 defects is a pipe-dream (with that exact term used).
I call bullshit.
We know how to write code that is for all intents and purposes defect free. We know how to adjust the structure of code over time to reduce technical debt and keep it flexible and understandable. We know how to do these things, but because they are more difficult to learn than a daily standup meeting, we don't do them.
I believe that's why the 4 technical sessions I attended didn't have the same size audience as the session on Scrum Metrics that, in my opinion, was bordering on the sale of snake oil. I believe that's why only 10% of the sessions in the conference were oriented towards the technical practices - the popular topics aren't in the technical realm. Does that mean there wasn't value in the other 90%? Hell no - my head is still spinning after Jeff Patton's excellent session, "Beyond Sprint 0: Using Collaborative Product Discovery to Plan Agile Projects".
The revival of XP Universe, the ascent of the Software Craftsmanship movement and the creation of groups such as the Agile Skills Network are all indications that we're once again acknowledging the elephant in the room that is the industry's horrendously poor track record with respect to low-level technical quality.
Considering civilization's current and growing dependence on software, that revival is occurring not a moment too soon.
Comments
I was at Key Bank when Alan Buffington joined us and led us to Scrum and Agile. Ken Schwaber came in for a couple of months and worked with our management and PMs to learn the techniques to become ScrumMasters. It was interesting as there was no discussions going on about technology nor how the development folks might best work in this new agile environment. Of course, as self managed groups, we were left to figure out the best way to get the project done. I was one of the devs that found the opportunity to start practicing XP. We brought the technical practices up from the bottom. Very fun and interesting times.
My point is - there are definately two different areas of focus, managing projects and delivering software. It sounds to me that Agile 2010 focused more on the management side - and it's definately a whole area of concern. Some bleed-over to the software development seems natural and the two complement each other. As a hands-on software dev manager I am deeply interested in both! Wish I could have been there!