Posts Tagged ‘conference’

Software Developer and Evolution Conference 2010

August 20, 2010 Comments off

Looks like this October i’ll be making my way east out to Winnipeg where I have the opportunity to present two sessions at the Software Developer and Evolution Conference.  I’m very excited as not only will this be my second conference of the year that i’m presenting at, it’s also going to be my first time in Winnipeg.  If you know of any fun family things to check out in Winnipeg please leave a comment!

My first session is about self organizing teams, participating on and leading.  There’s a lot of things to think about when it comes to creating and fostering self organizing teams.  I plan to talk about some of them from the perspective of a manager and leader, as well as a team member on the team.  I’m also coming up with a good exercise that I hope will be fun and help illustrate my points.

The second session will be on iterative development.  I did this session at the Prairie Developer Conference in Regina, and i’ve used the feedback I received from the attendees there to refine the presentation to hopefully be even better, and i’m also incorporating an exercise in to this one as well.

I’ll probably be making more posts on those two topics in the coming weeks, so check back for more.


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. 

Agile 2010 here we come!

August 5, 2010 Comments off

This year i’m extremely happy to be one of the 4 lucky people selected to attend the Agile 2010 conference.   I’ll be attending along with David Ford, Jesse Redl, and Marcos Tarruella. 

This conference is an all you can eat buffet of Agile information, whether you’re a developer, qa specialist, manager, team lead, scrum master, executive, or alien, there is something there for you.  Did I mention that it’s also being held in Orlando Florida at the Disney Dolphin Resort?

There were so many sessions during each time slot that I had a hard time deciding which ones i’m planning to attend.  I eventually managed to boil it down though and hopefully I made good choices!

Some of the sessions i’m the most excited about are:

  • Improving Decision Making in Your Agile Team by Meghann Drury and Ken Power
  • Making feedback work in your teams by Sumeet Moghe
  • Leading a Self Organizing Team by Mike Cohn

There are many others i’m attending that should be very valuable as well.  I can’t wait to get there and meet as many people as possible.

By Chris Dagenais

Let’s Learn from Each Other: BarCamp Saskatoon 2009

December 4, 2009 Comments off

Last weekend members of Saskatoon’s technical industry congregated at Louis’ Pub on the University of Saskatchewan campus for the annual BarCamp, a technical conference “for the rest of us.” For those of you who are not familiar with BarCamp, here is a little history as explained on the website.

The idea of BarCamp came from Foo Camp where a bunch of the best techie minds in the world got together to talk about new technologies, and to create opportunities for cross-fertilization between people and technologies.

Since only the top minds from O’Reilly, Google, Yahoo, Intel, Apple, etc. were invited to attend, two people in California decided to make a Camp for the rest of us. Now, there are BarCamps somewhere in the world almost every day.

This was the first year that I attended BarCamp so I wasn’t quite sure what to expect. I did understand that it had a laid back atmosphere which is quite apparent since it is held in a bar, but I also knew that the caliber of the talks would be high. The idea behind BarCamp is that everyone who attends has to participate in some way ranging anywhere from helping set up to leading a presentation.

As to be expected there was a high number of Point2ers in attendance, and impressively four of the nine presenters were from the office. Dave Kellow gave a spirited talk on Agile Modeling explaining why it is important, and discussed ideal ways of approaching the subject. Nate Heagy gave a brief, but extremely informative and entertaining presentation on Why You Should Get Good at Javascript. He used this as an opportunity to showcase an iPhone app he wrote using this technology as leverage. Chris Powell teamed up with his buddy Mark Poppen to give an information session on Starting a Web-based Business. Sean Reilly then wowed the crowd with his extensive knowledge of effective Functional Testing techniques, and why they are so important.

The time between all of the great presentations provided an opportunity for the attendees to mingle and find out what each other was up to. Being in a relatively small market, Saskatoon has a limited number of events like this so it is rare for members of the industry to get together and just hang out. Even though many different companies were being represented the atmosphere was of collaboration,  not competition. Everyone was there to learn from each other in hopes of bettering themselves professionally.  It’s events like these that will have a positive effect on Saskatoon’s technical community moving forward.  On behalf of Point2 I would like to thank everyone who made this event possible.

So you may be asking how I contributed at this year’s BarCamp. Well I didn’t help set up or lead any presentations, but I did shoot a lot of photographs to document the event. You can view the shots from the day here. The local media was also there to cover the conference and you can read the resulting article here.

By Hemant J. Naidu

Aligning Purpose

October 14, 2009 Comments off

In August I was fortunate enough to attend the Agile 2009 conference.  I saw two excellent sessions presented by Pollyanna Pixton.  I later found out that four other sessions (attended by Tefon) included recommendations of the book Stand Back and Deliver, authored by Pollyanna and 3 of her colleagues.  These presenters were so convincing Tefon even purchased the book while still at the conference.  It was a good read, but the chapter on the “Purpose Alignment Model” was by far my favorite.

The Purpose Alignment Model is a simple tool designed to do exactly that – facilitate an alignment of purposes.  The underlying premise is all product features or development that a company performs can be placed on two scales:  how critical and how differentiating they are to the operation or success of the company.  With everything placed on these scales, they can then be combined into a graph.

Purpose Alignment Model

Purpose Alignment Model

This simple graph can make discussion about any number of product features or work processes significantly easier and more effective.  When discussion about a feature starts by first placing it on the graph above, it is placed sharply into perspective.

What constitutes a mission critical differentiating feature?  One simple method for determining this is to ask ‘Could this feature be the center of an advertising campaign for the product?’  These features are the driving force to a product’s adoption and define the identity of the company.  If every feature gets a ‘yes’ answer to this question the model is being used wrong.  Trying to differentiate with every feature will result in little more than a mediocre product.  A select few features should be placed in the ‘Invest’ quadrant and these are the features that, naturally, should receive heavy investment.  If these features aren’t the most polished and solid in the product, get to work.

If an honest assessment of everything about a product is completed with this model, the majority of what might initially have been placed in the investment quadrant will end up falling into the parity quadrant.  The parity quadrant is interesting.  Most of a product’s features will invariably not be differentiating, so why waste resources trying to develop them?  These features are mission critical, make no mistake about it, they have to work and they have to work well.  Parity features will drive the sticking power of an application, thus it is still critical to get them right.  The key point, however, is that parity features only need to reach parity.  No wheel reinventing required.  Parity features aren’t innovative.  Look at what the market is doing.  What is the accepted best practice?  Do that and nothing more.

If a feature is differentiating but not critical to the success of the business, find a partner.  Don’t waste resources that could be spent getting parity features to parity and investing in mission critical differentiating features.  Find a partner who is investing in the feature and use them.

If a feature is not mission critical and not differentiating, who cares? If a feature in this quadrant is being worked on, ask why.

If every feature to be worked on is placed properly relative to each other on this graph the result is an amazingly powerful communication tool.  Suddenly everyone from the CEO to the developer implementing the feature can easily be on the exact same page.  With an aligned purpose across the whole team, from executive to business to development to IT, more time is spent making a profit and less time debating about how to make a profit.

By: Dustin Bartlett

Coaching, Leading, and the Experience Design

August 27, 2009 4 comments

Day four at Agile 2009 was the last day for regular sessions. My morning started off with Coaching Self-Organizing Teams by Joseph Pelrine. This workshop was very interactive, and was littered with activities that Joseph was hoping would get us self-organizing ourselves. He proposed a number of hypotheses and defined five different states of a team’s flow using a cooking metaphor.

  • Burning
  • Cooking
  • Cooling
  • Gelling
  • Solidifying

In order to move teams to the ideal “cooking” state, you need to control the amount of “heat” that you apply. Apply too much and your team will “burn” out. Don’t apply enough and they team will “cool”, and maybe start to turn into a “gel” where they become very constrained. Using his ABIDE principle he identified things you can do to control the heat, thus initiating change.

I went into Min-Gu Lee’s session on Executive Leadership Challenges for Agile Adoption with fairly high expectations. Unfortunately it geared itself towards the government sector or huge organizations riddled with bureaucratic overhead. Many of the things he mentioned could be applied or at least thought about in smaller companies, but I think most of it could be considered common sense.

I wanted to get as much information as I could on making feature teams function properly so I took in Andre Frank’s session Feature Teams – Collaboratively Building Products from Ready to Done. He gave an experience talk on how his company LiquidNet moved their Scrum teams down the feature team path. I think the title was a little bit misleading since the focus was more on the Scrum process they put together with little discussion around how they overcame challenges associated with feature teams.

Declan Whelan from my old stomping grounds of Guelph, Ontario gave an interesting talk, Learning is the Key to Agile Success: Building a Learning Culture on Your Agile Team. I was eager to see how Point2’s approach to creating this environment correlated with his findings. A lot of what he presented could be considered “touchy-feely”, or as Declan put it “all “rainbows and flowers”, but everything he said made sense.

Not getting into the details of the “rainbows and flowers”, he did speak of changes we made to facilitate this at Point2. Such things included changing the work environment, setting up workshops or study groups, implementing an e-forum, and making it a recurring process. He also recommended a number of books with one catching my attention called The Fifth Discipline by Peter M. Senge.

The day was wrapped up with a banquet where they revealed an iPhone application that was built during the LiveAid sessions over the week (in which Ryan had a hand in). The application provides a way to make donations to Mano a Mano International, a charity for “creating partnerships with impoverished Bolivian communities that improve health and increase economic well-being.”

The keynote by Jared M. Spool titled The Dawning of the Age of Experience was awesome. The industry examples he used around Netflix, Apple, and Southwest Airlines made everything he said so clear. By the end of his talk it was obvious that all companies need an experience design to, “not build crap.”

That wrapped up Agile 2009 in Chicago, Illinois and I think I can speak for all of the Point2 crew that the experience was incredible. It was great to be around so many great minds in the software development industry and participate in the discussions they ignited. I came here with a goal of learning as much as I could from other attendees while passing on my experiences to others. I think I can leave Chicago feeling I did that.

By Hemant J. Naidu

Agile 2009 Wrap-up

August 27, 2009 Comments off

The conference is pretty much wrapped up. The banquet and keynote put the finishing touches on a wonderful week of learning, collaboration, and meeting people who share the same passion for how to create awesome software.

In the coming weeks I’ll be posting about the things I’ve learned and how we can make our company better. I need some time to absorb how all of the different sessions tie into each other. It didn’t seem to matter if the session was about UI, project management, distributed teams, or coaching – everything kept coming back in some subtle way to the Agile Manifesto.

Once my subconscious has some time to mull this over and make sense of it, I’ll post. I’m going to do it just in time because as they say in Lean, JIT happens.

By: Ryan Shuya