BT

Agile 2010: Where Were the Programmer-Focused Sessions?

by Shane Hastie on Aug 21, 2010 |

 At the Agile 2010 conference in Orlando last week, Uncle Bob Martin  tweeted about the low number of programming sessions on the conference schedule:

  • < 10% of the talks at #agile2010 are about programming. Is programming really < 10% of Agile?
  • #agile2010 Code is 25% of the manifesto. Code should be 25% of the conference. No?
  • #agile2010 Programmers started the agile movement to get closer to customers not project mangers.

This resulted in a flurry of twitter responses and some ongoing discussion amongst those who were there and those that weren’t.
J. B. Rainsberger was one of those who attended, and blogged on the topic afterwards.
He states:

I just came back from Agile 2010, which I rather enjoyed. We had some intense discussions, and plenty of whining sessions, about the relative lack of content for programmers. I found out that about 1/6 of the conference attendees identified themselves as “developers” and about 1/5 identified themselves as “consultants”. If we suppose that even half the consultants are programmers, then only about 1/5 to 1/4 of the attendees had medium-to-strong interest in deep content for programmers. It turns out that the number of such sessions amounted to about 1/5 of the program, and by all reports, most had lower-than-expected attendance. If the conference offered enough content for programmers, then I have to ask two questions:
1) Why didn’t more programmers attend Agile 2010?
2) Why didn’t more of the programmers who attended Agile 2010 go to the deep technical sessions?

His blog entry garnered more than 20 responses, including the following::

George Dinwiddie
I still consider myself a programmer, though I earn my living by coaching and consulting these days. But I don't go to the Agile conference to learn programming techniques. And I'm not sure that the conference format is conducive to doing so. How much hands-on programming can you do in 90 minutes? I tend to use non-programming simulations, so that the action is more visible, and even that is hard within a 90-minute time-box
And
The Agile Conference hasn't cast out the programmers. It's not taken over by "them". It's a big tent where we can meet and understand others who come from a different direction with different assumptions.

Mark Simpson 
The reason I did not attend Agile2010 was money; nothing to do with the program. I can't afford such a conference unless my company helps (I did afford Agile2009 - but that cannot be the norm). And i if I had gone to Agile2010 I am reasonably sure I would have gone to plenty of non-programmer type sessions. This is the stuff I have _real_ problems with - I need help on non-programming stuff more than the coding.

Damon Poole
I'll answer with another question. :-) Is the problem with getting more organizations to *actually* be Agile rather than just check the box in an Analyst survey one of individuals coding, or of organizations changing? I'm thinking that while there is more that individual developers can do to be more Agile, the greater problem is at the ecosystem level

Jason Herman(http://twitter.com/iamtourmalet)
I am a developer and did attend the conference. There were not too many deep technical sessions that I attended, partially perhaps because there were not too many that were relevant to what I do . . . I suppose to sum it up, the "soft skills" of Agile are the ones that are the pillars on which we stand and will sustain our Agile initiatives for many many sprints to come and I attended those in lieu of some of the deep techie sessions


Liz Koegh(One of the recipients of the Gordon Pask Award at the conference)
I didn't submit any technical sessions because there was only one stage, and I felt I had a better chance of differentiating myself on the other stages. A lot of people had submitted various BDD-related technical sessions and it looked a little crowded. I also feel that at the moment, my biggest challenge as a developer is coding the right thing, rather than coding the thing right.

It felt like the right kind of balance, to me, so maybe it's just that those people who weren't happy with the balance are making themselves heard more than those who were. Corey's Code Retreat afterwards rocked; I would definitely like to see another of those next year.

She went on to blog about the value of the Code Retreat run by Corey Haines  after the conference, which was a deeply technical programmers learning session where programming pairs were focusing on learning and applying new ways of writing code. She points out that this can’t be achieved in a 90-180 minute conference session, it needs intensive concentration in a non-distracting environment to let the ideas flow.  Uncle Bob Martin also blogged on the session and what it was like working with her. 

 

Another commentator who wrote about the lack of developer focused sessions is Mike from the “A Software Craft” blog: 

What do I see dominating the Agile2010 program? Lots of good sessions on learning, communicating, coaching, creativity, adoption strategies. Sessions that I would probably come out of saying "interesting" and "thought-provoking". But ultimately, sessions that were easy to digest. Not sessions where I encountered concepts that are fundamentally difficult and require hard work to master. Not sessions where I struggled to write good tests and emerged with a determination to rework and discuss the examples over the coming weeks until I finally felt I understood it.

 

Perhaps I'm a minority. @HackerChick tweeted about a tutorial on TDD where only a quarter of the attendees showed up with laptops, prepared to get their hands dirty. Perhaps Agile2010 isn't the conference for me. A conference where the technical track is only 1/15 of the program. And the technical track includes sessions on "The Butterfly Effect" and how to "Walk and Code". But I worry about another crop of agile converts, filled with all the soft skills and strategies they need to succeed, headed for failure because they don't know about the hard work and dedication needed to build that essential ingredient: the agile developer.

Llewllyn Falco responded to this post with

I deeply agree that there should be more technical talks, but I don't in the least blame agile2010. I was at most of them, and they where not full. I think agile2010 is accurately measuring judging the demand, I wish there were more people showing up wanting to code. of course they could just go to the code retreat afterward on saturday. it's free! if you're are already here it's barely any money at all, and even cheap if you just flew in for the day!

Kurt Häusler also responded with
Also if you think about the stages that developers and organizations go through with agile, they usually start off with the technical practices, which can be learned from books, but proficiency comes with practice. Even then the developers are going to feel much more comfortable exercising their technical skills and making decisions that effect the way things get programmed. The management aspects are however more difficult to grasp. If a manager has been CSPO certified but is otherwise uninterested or unengaged in agile and lean, or thinks it is only something that is relevant to developers, then this is the ideal candidate for visiting a conference like agile 2010 and finding out how his management practices and philosophy can catch up to the technical practices that the developers have already been working with. A conference is ideal for this, as they can talk with others and share knowledge and go into detail on special circumstances.

But it is all a difference of perspective. Apparently a lot of people are involved in situations where management has applied scrum, yet the developers neglect to apply XP practices. I suppose this might be your situation. I have never been in a situation like that, but I have experienced the reverse. Competent developers, that learn and apply the XP practices fairly well, and did so without the help of a conference, maybe even with a basic scrum process, involving only the developers, struggling to make further progress because management are simply not as engaged in agility as the developers.


Cory Foy, one of the stage producers for the Team Room Agile stage, also blogged about the non-programmer focus of the conference, and makes a strong call for a more technical focused conference – bringing back the XP Universe conference which was merged into the Agile 20XX in 2005.  

He announced the intention to run an XPUniverse 2011 conference focused on :

The hands-on practices that enable us to deliver software which provides incremental value in an iterative fashion. And a hands-on conference where you are expected to have your laptop, where you will be taking back practical exercises and practices to your development team. A conference focused on the developers, testers and the customers they love and who love them. A conference focusing on the fundamental principles of XP: Rapid Feedback, Assume Simplicity, Incremental Change, Embracing Change, Quality Work. And a conference small enough (~300 people) to be able to connect, explore and learn.


What do you think – does the world need an XP Universe conference in 2011? Did Agile 2011 have the right mix of technical and non-technical sessions

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Technical Practices by Cory Foy

First off, I want it to be clear that the XPUniverse conference Corey Haines and I are organizing is not meant to be a fraction of the community. We are working very closely with the conference organizers of Agile 2011 to make sure it is something beneficial to all. In addition, I'm currently exploring with the organizers of both Agile 2011 and SQE conferences ways to bring deep hands-on practice to both conferences in a way that wouldn't traditionally fit into a 90- or 180-minute session.

Personally, for me, Agile 20xx and the SQE conferences are exactly what we need - a chance to focus on the entire value stream. While many of us would agree that Clean Code is a large part of insuring adaptability and flexibility as the product grows, I believe the dysfunctions lie elsewhere. In fact, I'd garner to say that even with Clean Code in every facet of an organization, they would have trouble taking advantage of it. It's that dysfunction that I see the Agile at SQE conferences helping to put a light on, and I think that's a great thing.

What I think we'll find is a balance where we can help introduce more of the XP Practices to developers at the big conferences, and then help them focus on improving those skills in the smaller ones. I'm sure it will take a couple of tries to get right, and I'm particularly thrilled at the passion from all sides and the willingness of the community to step up and find a way to make this work.

Agile is not just about Group Hugs and being Warm and Fuzzy by Patrick Dooley

Don’t get me wrong. I am all for group hugs and being warm and fuzzy. Agile as a management paradigm is definitely the right direction. It gets a lot of things right. Unfortunately, IMHO Agile leadership without technical expertise will never attain the success it could attain.

Industry has accepted the wisdom that to manage experts, one must not be an expert. It is believed that management is a skill somehow orthogonal and independent to any domain expertise. We now have the unfortunate situation where it is not unusual, and perhaps rather more likely that teams of experts are managed by individuals who do not share their expertise or their enthusiasm. All of my experience indicates that this is certainly the case in the software industry. Perhaps the software industry is experiencing this to a greater extent than any other industry because:

• It is a relatively new field and we are still trying to mature as a profession and,
• Very few industries in modern times have grown so rapidly and have had such deep pockets for so long.

Agile is now becoming the prevalent management paradigm. I do not think it is a coincidence that the agile community is focusing less and less on technical knowhow and more and more on management skills. The same set of professionals who managed via waterfall, are now attempting to manage via Agile.

To be successful in creating complex systems, one must be able to intuitively replicate - in a software framework - the complex and utterly sophisticated mental model that a finely tuned, high performance mind creates when attaining domain expertise. In other words, one must create a “Dynabook” - an extension of the mind itself. In my humble opinion, there exist too few software professionals that have attained this level of craftsmanship.

The only community in the agile space that is attempting to tackle this problem - and in my view successfully – is Eric Evans and the proponents of Domain Driven Design (DDD). Unfortunately in my experience, this is the one branch of XP that agile coaches tend to ignore. It is treated as if it were a rather awkward and embarrassing relative one is particularly distressed to admit to.

I admit he isn't pretty, nor is he very cosmopolitan, or flashy, or sexy; it might even be pleasurable to ostracize him and even publicly humiliate him, but I sincerely believe that, in the end, we will be the ones left with egg on our faces.

Re: Agile is not just about Group Hugs and being Warm and Fuzzy by J. B. Rainsberger

The only community in the agile space that is attempting to tackle this problem - and in my view successfully – is Eric Evans and the proponents of Domain Driven Design (DDD). Unfortunately in my experience, this is the one branch of XP that agile coaches tend to ignore. It is treated as if it were a rather awkward and embarrassing relative one is particularly distressed to admit to.

I admit he isn't pretty, nor is he very cosmopolitan, or flashy, or sexy; it might even be pleasurable to ostracize him and even publicly humiliate him, but I sincerely believe that, in the end, we will be the ones left with egg on our faces.


Which agile coaches have you seen intentionally ignore DDD? The BDD literature expressly mentions DDD as a focal part. I might guess that many agile coaches see DDD as an intermediate step and so few get to make it that far, but I don't know of any actively pooh-poohing it. Any articles I ought to read?

Great conference by Arin Sime

For me personally, Agile2010 was a really great conference. In my job I do both development tasks and process/management tasks. I also led a session on range estimation at the conference, so you may consider me biased if you want, but I really got a lot out of the week.

I only went to one technical experience report, but that's because I was more interested in the process and people related topics. I agree with the sentiment expressed by some on this page and other blogs that the challenges that I have run into with agile and traditional methods have been more people and process related than technical in nature. Agile methods help me deal with those challenges much better and the conference tracks gave me a lot of ideas of how to further improve our company's Agile practices.

Some of the best sessions I went to were about agile coaching, and I was pleased to see many options there. Since my role in Agile projects has grown over time, I found that I really benefited from the focus on mentoring and non-technical coaching aspects in those sessions, and I had some real epiphanies.

That's not at all to say that the more technical practices aren't important - they are very important and I would be interested in the efforts being made to provide other ways to get those sessions out there. Those types of sessions just weren't my focus for what I wanted to learn at this conference. Considering that many of the sessions I attended were standing-room only, I think there was a lot of similar sentiment among attendees.

Agile conference by XebiaLabs XebiaLabs

Hi Shane—thanks for bringing up the fact that the Agile conference lacked programmers. Programmers shouldn’t shy away from agile, because agile methods, such as deployment automation, require the help of programmers. Deployment automation can keep up with the faster and more frequent deliverables that agile makes possible, and programmers are needed to create those deliverables. Did you happen to see Wilco Koorn, Senior Consultant and Scrum Master at XebiaLabs, and Jeff Sutherland’s session at Agile 2010 discussing the benefits of deployment automation?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT