Archive for the ‘Extreme Programming’ Category

• Best Links of the Week – Jan 19 2010

  Date: 2010.01.19 | Category: Agile, Pair Programming, Planning, PMI, Product Owner, Scrum, Transitions | Response: 0

  Continuing with links to the best of the blogs since last week.

  1. Three things I wish I knew before jumping – PMP and Certified ScrumMaster, Pat Guariglia, shares some lessons learned after his first Scrum pilot project in 2007.
  2. Mike Cottmeyer on the Agile PMP – InfoQ has a 78-minute video from Mike Cottmeyer’s Agile 2009 talk on how Agile’s approach to managing cost and time reduces project risk rather than the traditional approach of managing scope.
  3. Determining how Agile you are comparatively – discussion on the Comparative Agility assessment for teams looking to understand how Agile they are doing in seven areas: teamwork, requirements, planning, technical practices, quality, culture and knowledge creation.
  4. Demystifying the Product Owner role – Roman Pichler provides some truth about the Product Owner role and clears away some myths.
  5. Self-discipline & self-organization – Cutter Consortium Fellow, Jim Highsmith, emphasizes the need for discipline and excellence on Agile teams.
  6. Eight reasons why the estimates are low – some common reasons why software estimates are often too small.
  7. How pair programming really works – the IEEE publishes an article sharing four mechanisms that can improve pair programming.

• Best Links of the Week – Jan 12th 2010

  Date: 2010.01.12 | Category: Agile, Collaboration, Links of the Week, Open Workspace, Scrum, ScrumMaster, Simple Design, Team, Test-Driven Development | Response: 0

  Here are some links to the best of the blogs since the beginning of the year.

  1. The Role of Leaders on a Self-Organizing Team - Mike Cohn talks about the important role management continues to play on Scrum teams.
  2. Agile Scales, Waterfall Doesn’t – or so claims Vasco Duarte during this 48-minute video from the Agile Eastern Europe 2009 Conference.
  3. Scrum, But – in this 10-minute video Scrum co-founder, Ken Schwaber, explains the negative impact on your business of “We use Scrum, but…”
  4. Management 3.0: The Era of Complexity - Jurgen Appelo describes the new role of social networks as management dives into the 21st century.
  5. Faster, Better, Cheaper! TDD wins in a simple experiment – a side-by-side comparison of two software developers working on the same project – one using Test-Driven Development (TDD), the other not; the developer who used TDD increased his productivity by 50%!
  6. Agile Game Interview: Simplicity is Hard - Clinton Keith interviews Chris Ulm, CEO of Appy Entertainment, about why Agile is an essential factor in their successful launch of high quality, iPhone games.
  7. Embedded Collaboration - Dave Rooney kicks off this post with a classic quote from “The Princess Bride” to explain the real meaning of collaboration.
  8. Agile Office Space – the Motley Fool shows off their cool Agile workspace and describes the principles they used to create this space.
  9. Wives of Rockstar San Diego Employees Have Collected Themselves – apparently some people are fed-up with yet another death march in the gaming industry and interesting from commentary from Clinton Keith that Scrum is not the solution, but provides visibility and a reality check to wishful thinking.

• Speaking @ Fullerton Code Camp – Jan 30 & 31

  Date: 2010.01.04 | Category: Agile, Coaching, Conferences, Extreme Programming, Planning, Presentations, Scrum | Response: 0

  If you are looking to see me speak in person, be sure to come to the Fullerton Code Camp.  I will have three presentations on Agile.

  1. Experiencing Agile Through Games: Are you bored at work? Is your Agile team devoid of fun? It could be that you are following the mechanics of your process, but missed out on the critical insight, the “ah-ha” moment, where everything clicked and it all fit into place. Come to this session hosted by Carlton Nettleton and he will demonstrate as many Agile principles and practices he can in 75 minutes through a variety of short simulations and games. Walk away energized and excited about working on an Agile team.
  2. Agile Planning Workshop: Every time I speak about Agile software development, I often hear this statement, “Agile teams never know when they are going to be done.”  With the teams I coach, this is not the case.  Come to this workshop and we will walk through the steps I use when planning an Agile team.  Learn the practical tools and techniques for estimating, planning, reporting progress and keeping the stakeholders in the loop. This session will focus more on principles and tools used in Agile planning.
  3. Debunking Myths About Agile Software Development: With so many myths surrounding Scrum, Extreme Programming, Lean and Agile software development these days how is someone supposed to succeed with these processes when there is so much half-truth and opinions masquerading as practice and fact? In this workshop, we will look at the myths surrounding planning, deadlines, documentation, architecture & design, requirements, testing, pair programming and other common misconceptions about Agile teams. By the end of this session, Carlton Nettleton will provide real facts about Agile software development, refuting many of these myths once-and-for-all.

• XPSD Call for Speakers

  Date: 2009.12.29 | Category: Agile, Agile SD, Extreme Programming, Scrum | Response: 0

  A group close to my heart, Extreme Programming San Diego (XPSD), is looking for speakers to talk about their experiences applying Agile software development practices.  XPSD meets on the 1st Thursday of every month at The Linkery in North Park from 6 PM to 8 PM to network, share ideas and discuss trends in the Agile software development community.

  XPSD is an excellent, knowledgeable community resource on the topic of Agile software development, Scrum and Extreme Programming in San Diego County.  I am consistently impressed with the experience and passion in our group.  I am very proud of how much XPSD has grown over the years and I am glad we have created a friendly space for great dialogue on Agile in San Diego.  We are seeking speakers in these three areas:

  1. Experience reports on applying XP, Scrum or Agile techniques in your organization.
  2. Explanations on the business and management side of using Scrum on projects or the enterprise.
  3. Technical presentations on useful tools or the technical practices of XP or Agile software development (pair programming, iterative design, refactoring, TDD, testing, etc.) that enable agility.

  We provide a variety of ways for our speakers to contribute (see below), so if you just want to share some ideas on how something might work or to talk about what your team did, please get in touch with our organizers – Carlton Nettleton (carlton@lookforwardconsulting.com) or June Clarke (joonspoon@yahoo.com) – for more details.

  These are the formats we provide for our speakers:

  • Roundtable: a casual discussion where we can examine one or two ideas from a variety of perspectives for about an 60 to 90 minutes. The roundtable “host” provides a 10 to 15 minute overview of the topic(s) in order to frame the conversation and then starts the discussion with a provocative question.  This is a great format to get a number of expert opinions on a difficult problem you’ve been facing.
  • Lecture: in-depth discussion of one or two themes or ideas and is expected to be about 60 minutes, but no longer than 75 minutes. Great format for an experience report or sharing some results with a wider audience.  XPSD is an inquisitive group, so expect questions during your talk.
  • Short topic: intended to explain a technical topic or highlight a new idea.  This new, short format (15 to 30 minutes) is provided by XPSD to help new speakers, ideas, perspectives and experiences get in front of the members.
  • Workshop: illustrate a concept or technical skill primarily through audience participation and ideally should not exceed 90 minutes. Workshops are fun and members love them.

• Best Links of the Week – Dec 11th 2009

  Date: 2009.12.11 | Category: Agile, Daily Scrum, Extreme Programming, Links of the Week, PMI, Scrum, Team | Response: 0

  Here are links to the best of the blogs for the week of Dec 11th 2009.

  1. Agile Project Management (Part 1 of 2) – short article from Agile Journal looking to bridge common Agile vocabulary with PMI practices and concepts.
  2. “Ideal” Team Size and Ratios - Johanna Rothman explains the the optimum size for Agile teams.
  3. The Benefits of Feature Teams – more on teams, this time from Mike Cohn, and why traditional component teams are risky.
  4. The Daily 15 Minutes of Fun – description on how some Scrum teams have extended their Daily Scrum beyond 15 minutes.
  5. Where has XP Gone…and can We Have it Back? – Open Space report from XP Days London asking what happened to one of the more popular Agile processes from early 2000′s.
  6. The People’s Scrum – Tobias Mayer looks at how Scrum is really a framework for change, not a process or methodology.
  7. Why Hasn’t Vista Sold – not directly related to Agile, but discusses how poor software quality has trained our consumers not to purchase upgrades.

  Hope there is some good reading here.  Cya next week!

• More on Pair Programming

  Date: 2009.09.24 | Category: Extreme Programming, Pair Programming | Response: 0

  Obie Fernandez writes a blog post about how pair programming is not for the masses.  I find it interesting that his post addresses many of the items that were not discussed at the Agile 2009 session on how to debug pair programming.

  Three ideas identified by Obie are common stumbling obstacles I have observed when trying to consistently use pair programming with product teams:

  1. Most software people don’t understand pair productivity: unfortunately this is so true and it applies to both management and programmers.  From the management perspective, I cannot understand why pair programming is not embraced more fully.  You get higher quality code and the programmers are focused on doing work (as opposed to reading the Internet or working on side projects).  For the programmers, pair programming just makes the work more fun and less frustrating.  Granted, pair programming is not for everyone, but when coaching teams on this practice, I insist teams try it out for 3-4 weeks and learn what the boundaries are.
  2. Most software managers don’t want to invest in the necessary hardware: if you do not understand the value of the practice, you are not going to invest in tools that make it easier.  And yes, pair programming is an investment in the future quality of the system.  If you invest in something, you are serious about it.  Or put another way, put your money where you mouth is.  Spending a few thousand dollars on good machines gets people’s attention.
  3. Most software shops are not configured for pair programming: if you are not going to invest in tools and do not understand the value of the practice, why would you fight the office furniture police?  Why be a squeaky wheel in the corporate world if you don’t believe pair programming is valuable?  Management investments in the environment are cues workers use to know if management are serious about changing the development practices.  Nothing says change more than tearing down cubicle walls.  Being able to do that shows you have management support and goodwill.

  So, what is the solution?  I am not really certain I know the answer since solutions are context sensitive.  I believe some of the prerequisites are maturity within the developers, desire for code excellence by all parties and an open mind.IF we have these prerequisites in place, then we can begin to have a conversation.

• Pair Programming Gets Profiled by the New York Times

  Date: 2009.09.21 | Category: Extreme Programming, Pair Programming | Response: 1

  Thanks to Lisa Crispin for pointing out this article on pair programming in the Jobs section of the New York Times.  In the article, they do a profile of a company in Florida that uses pair programming.  It’s a very first person description of the practice, the benefits and some conflicts uncovered by pair programming.

  Unfortunately, since it is the New York Times, they make you login to the site in order to read the content, so use these credentials I created:

      username: lookforward9

      password: lookforward9

• Seems Obvious Now

  Date: 2009.09.14 | Category: Personal, Test-Driven Development | Response: 0

  Just wanted to reiterate the value of TDD – I am working on a programming challenge and was surprised how easy it was to add a hunting and killing algorithm to my program.  Since it was written using TDD, I had a nice suite of fast tests which allowed me to incrementally encapsulate my new algorithms and keep the system functional at nearly every step.

  At the most, I only had two, maybe three, broken tests while adding the new classes, pulling up fields and moving methods.  Not bad, not bad at all.

• Agile 2009: Debugging Pair Programming & Impact of Gender

  Date: 2009.08.25 | Category: Agile, Collaboration, Conferences, Extreme Programming, Pair Programming | Response: 0

  Mat Wayne ran an interesting session about overcoming resistance to pair programming organized around personas.  On each table there was a description of a different persona and some ideas on why that persona might resist pair programming.  Our job was to discuss in groups why the persona was resisting pair programming and some ideas on how to overcome the resistance.

  I tried to make the case that gender differences was an important consideration in resistance to pair programming.  In a room full of (mostly) men, it was hard to be taken seriously, especially after the few women in the room were pretty vocal opposing my viewpoint.  However, I think the people in that room\conference self-selected to be interesting in pair programming.  The sample was biased toward ignoring the impact of gender on pair programming.  Remember, the purpose of the session was to help people who do not want to do pair programming to become more interested in it.

  After talking with some friends, I think there are more gender dynamics at play when men and women work together programming and some of these might explain why women are not interested in (pair) programming.

  • Pair programming requires two people to work in close proximity.  Some women might not feel comfortable sitting less than two feet from a male co-worker for most of the day or not be interested in the unwanted attention from men.
  • Male programmers have a really strong geek hierarchy thing going on.  The more uber-geek you are, the more status you have and the bigger your voice on the Team.
  • Get more than three men together and you begin to create a “locker room culture” that is a normal part of male bonding.  This is often characterized by seemingly harsh, personal put downs of your ideas by your peers.

  I don’t think any one of these things is a definitive cause, but I do believe they add up and discourage women from participating on programming teams.  As coaches, we need to be mindful of gender and provide a safe environment.  It is not that women need extra help, just men need to be reminded to act like adults.

• Why I Encourage Small Teams

  Date: 2009.05.27 | Category: Agile, Collaboration, Communication, Extreme Programming, Scrum, Team | Response: 0

  Yesterday, I was having a conversation with a colleague about an issue she was struggling with.  She was describing to me how management sometimes has the notion that if we just double the project, say from 10 people to 20 people, we will get double the output.  In the classic Mythical Man Month by Fred Brooks, he made the bold statement that resources do no combine linearly.  Brooks documented his observation with a formula that describes, in part, how the exponential increase in communication pathways as the team size grows, is responsible for his observation.

   

       Communication pathways = [n * (n-1)]/2

  

   

  In my colleague’s example, the number of  communication pathways increase non-linearly from 45 to 190 after the team doubles in size.  Or if you want percentages, changing the team size from 10 to 20 is a 400% increase in communication overhead.  Wow!  I would call that communication overload.

  As a response to this observation, Agile teams and projects almost always try to keep the team size around 8 plus or minus 2.  When team sizes exceed this, it is impossible for people to maintain a network of communication links with all the participants.  

  OK, mister big shot consultant, how do you deal with big teams of, say, let’s pick a number, a hundred people? My first answer would be to subdivide the hundred people into smaller units each with 6 to 10 people, or create about about 10 to 12 teams.  Of course, now you have the added difficulty of coordinating that many teams, but no one said management was easy.  However, would you rather coordinate 55 communication pathways between 11 teams or 4950 communication pathways between a 100 individuals?