Archive

Posts Tagged ‘Technical’

Agile 2010 Session Roundup

August 12, 2010 Comments off

So far my experience at Agile 2010 in Orlando has been great.  Great location, great conference center, great people, and great information.  It’s been a very busy and exhausting week so far, although i’m sad to think that i’ll be flying out around this time tomorrow and it’s all coming to an end. 

My first session monday morning was titled “The Incentives Trap”.  It was a session exploring what motivates people, primarily focusing on intrinsic vs extrinsic motivators with some exercises to prove out how the different types of motivators affect the work ethic and productivity of teams.  I was on the “square” team which was divided in to developers and testers.  My role on the team was a tester.  I got paid $1 for testing a story and $1 for finding a bug.  The developers got $1 for developing a story and $2 for fixing a bug.  Only the project manager got paid for delivering value.  Can you see who got screwed over in this scenario?  Lets just say the project manager probably didn’t eat that night.  It turns out that generally the team which is allowed to self organize, and is working for a charity for “NO PAY” is the most productive team that delivers the most value.  Why?  Because they are passionate about what they are working for, they are working for a charity because they believe in the cause and want to make a difference.  That’s why it’s important for your development teams to understand and believe in the work they’re doing, it’s the only way for them to be intrinsically motivated to be productive.

This is lining up to be a long post, since that was only the first session I attended, and i’ve attended 2 – 5 per day…. 

My next session was titled “Beyond Scope, Schedule, and Cost: Optimizing Value”.  It was a reasonably good session in which I primarily just came back with some interesting statistics and a couple of ideas.

  • doubling the number of people working on a project typically quadruples the number of defects.
  • 65% of features do not deliver their expected/planned value
  • what is a more successful project?
    • estimated to get 5 value points done in a week and achieved 5.
    • estimated to get 8 points done in a week and got 6

Tuesday morning was the keynote by “Dave Thomas”.  It was a lot of what you would expect to hear at an agile conference keynote.  There were a couple of things that surprised me though, like when he exclaimed “you know we’ve made it now because the tool vendors are here, but let me tell you, if you can’t do it with paper cards, no tool will help you”.  I don’t disagree with him, but the tool vendors are the major sponsors of the conference, so I found it a little ironic that he was denouncing their usefulness to all of the conference attendees.

In the afternoon I got to see a session by Johanna Rothman which I was quite excited about as i’ve been reading her blog for quite some time now.  Her session was titled “Agile Managers: The Essence of Leadership”.  The purpose was to talk about what role managers and leaders play in an agile organization, as many managers often feel lost.  There weren’t really any surprises here for me as we’ve got it fairly well figured out at Point2 (we can definitely improve on execution of it as a management team, but we have our place figured out at least).  The session was a nice indication for me of how well we’re doing, and it was great to see that Johanna is just as good of a speaker as she is a writer on her blog.

Wednesday started out with quite likely my favorite session of the conference so far “Scrum Metrics for Hyperproductive Teams: How they fly like Fighter Aircraft”.  It was given by Jeff Sutherland and Scott Downey, Scott had the title of head agile coach at MySpace and now holds the same title at Napster which I thought was pretty cool.  They had a lot of good information which I couldn’t possible discuss in it’s entirety in one paragraph, so i’ll just stick to a couple of points that stuck out for me which we’ll need to try.  The first is we need a “keystone” story, probably estimated at 3 points, which because the reference point for all estimation done by the team for the rest of eternity.  Why do we need this?  Because as the team gets better they will naturally migrate their estimates along with their increased productivity which makes it hard to track improvements over time.  It also makes it hard to have consistent estimates across sprints when you don’t have a never moving reference point to estimate against.  Another thing I want to try focusing on is getting as many people as possible working on getting the top priority store from in progress to done.  We typically have a pair sign up and work on a story until it’s complete.  If 3 pairs can all work on the same story to get it done faster, we should do that.  A sprint that ends with the top half of the stories finished is better than a sprint that ends with all of the stories 75% done.  The other big area that I want to try some changes is in the team standup meetings.  For now i’ll just say that the scrum masters are doing do much of the driving at the meetings.  Their role in the standup should essentially end with making sure everybody on the team has shown up.  More about that when I get back 🙂

I had another great session on Wednesday morning called “Coaching Agile Teams: Using Silent Work Techniques to Get to Astonishing Results”.  It was a very interactive session with a lot of activities.  I learned a number of techniques in this session on how to get a greater quantity of ideas out of brainstorming sessions about projects/products, as well as some ways to get much more innovative ideas.  Jesse and I are planning to run at least 2 workshops once we’re back based on the exercises I learned in this session.  I think it’s going to be very valuable for having the entire team feeling more involved in providing ideas that can help shape our roadmap and product decisions.  Jesse and I are both really excited about it.

In the afternoon I went to a couple sessions that didn’t produce too much worth writing about with one notable quote “There’s a big difference between half-assed and half done” referring to people’s natural tendency to prefer delivering something half done with a high level of detail over delivering something finished to a lower level of detail.

Today, thursday, is a bit slower.  It’s the last day of real sessions so everybody is starting to look burnt out (everybody at the conference including presenters).  I went to a session about Design Complexity this morning that was quite interesting.  I had a short debate with the speaker about building what you need instead of what you think you need, as she was advocating spending effort up front designing your implementation to be extensible in the way you think it will need to be extended at the time.  We agreed that if you know it’s going to be extended immediately after this isn’t necessarily bad to do, but we disagreed on if you only “think” it will be extended in that way, but had no plans to do so.

I later went to a session titled “Confessions of a Flow Junky” focused on helping create an environment where people can get in their “flow” to become really productive.  The speaker asked how many people have tried pairing and astonishingly half the room raised their hand, the speaker was pretty impressed.  Then he asked how many do it regularly, and only about half a dozen people put up their hand.  When he asked who know how pairing helps flow, I was the only person in the room with my hand up, so he asked how.  I told him “you feel obligated to the person beside you not to screw around” which had the desired result of everybody laughing, and the presenter agreeing, saying it’s one of the littlest known benefits of pairing.  I enjoyed the session, in particular because after the previous comment I had made, people were asking me questions at the end of the session about how we do things at Point2 and how I thought they could make improvements to what they do.

Networking at the conference so far has been great.  I’ve met a lot of cool people from all over the world.  I’ve met a few people from Ireland, a guy from Finland, a couple from France,  many from the US of course, and a surprising number of Canadians.  I actually happened to run in to a girl that I went to school with at Kelsey in Saskatoon that I haven’t seen since we graduated in 2000!  What are the odds?  I also happened to run in to one of the presenters that I met at PrairieDevCon in Regina this year and it sounds like I might get an opportunity to present at a conference in Winnipeg this October so i’m looking forward to finding out more about that. 

I wanted to post some pictures but uploading them over the hotel wireless hasn’t been working so that will have to wait for later. 

Advertisements

Overview: Here Comes Everybody by Clay Shirky (Part 2)

May 5, 2009 Comments off

herecomeseverybody Part 2.

In part 1 I focused mainly on some of the changes to how things can get done with the new tools at our disposal.  In Part 2 I will talk about some of the fundamental paradigm shifts that are happening because of those tools.

http://agileshoptalk.wordpress.com/2009/05/05/overview-here-comes-everybody-by-clay-shirky-part-2/

By: Chris Dagenais

Overview: Here Comes Everybody by Clay Shirky (Part 1)

April 28, 2009 Comments off

herecomeseverybody Part 1.

I started reading this book because I’ve always been interested in people’s behavior, and in particular how that behavior is modified when people are in groups.  I’ve read some of Clay Shirky’s work previously and have always found it very interesting and well thought out, although usually it is a bit long winded.

Here I’ll overview a few of the main concepts that Clay discusses in the book that I found the most interesting and what my thoughts were on them.

http://agileshoptalk.wordpress.com/2009/04/28/overview-here-comes-everybody-by-clay-shirky-part-1/

By: Chris Dagenais