Posts Tagged ‘teamwork’

LSRC 2009 – Day 3

September 27th, 2009

How Much Testing

This presentation was very interesting.  It looked at the age-old question of “how much should we test and what do we test?”  It started out going over several real-life stories of companies who had failed to properly answer the question.  One in particular had a test suite that took over 15-20 minutes to build, over 5 minutes to start the server once built, and then used “webunit” tests that took forever to run.  Also the tests only covered 21% of the system — four years later the coverage was 24%!  (As a side note: Selenium testing is hard, to do right.)

For testing it’s critical to get feed back as immediate as possible.  So if your test suite it taking hours to run then you have issues.  You also should ask yourself if your tests are actually failing from time to time, are they really catching bugs and providing value?

Tests should influence your design.  If you are not finding that tests are influencing your design, they you’re probably not doing something right.  The speaker didn’t seem to specifically push TDD or BDD, but I could understand what he meant by this.  In order to test code easily you have to have testable code to begin with.  Code that is not easily tested is probably overly complicated and not designed/abstracted well.

“How easy is it for you to write a new feature?”  This begs the answer as to why testing is a good thing.  Well designed code is easier to maintain and change, and with tests you gain confidence that your application is working as you expected despite the changes.  Martin Fowler often explains that modifiability is the more important attribute to your code (even above performance), and you gain this through understandability (code is easy to follow/read) and testability.  Writing tests helps you write well designed, understandable, and testable code.

There are a lot of reasons why folks are not writing tests.  The speaker addressed the concerns of both management and developers.  Surprisingly he explained that managers are no longer the road-block, and that most managers now want testing – but the developers are resisting.  To write tests first requires a shift in thinking, and for many developers who’ve been coding a certain way for their entire careers, find this shift sometimes uncomfortable.

Ultimately the answer to the question “How much testing,” can be answered by asking, “What’s the right level of assurance?”  If you’re a company like Twitter (for example) if you lose tweets, or a search doesn’t come back exactly right is it really a big deal?  If you’re a patient in a hospital and your heart-lung machine software fails, is it a big deal?  Obviously you wouldn’t necessarily worry if Twitter admitted to less than 70% code-coverage, but you might be concerned if your heart-lung machine was anything less than 100% code-coverage.

Be Awesome

This was a very fast-paced talked that just touched on values or principals you should adopt to “be awesome,” taken from the speaker’s personal experience:

  • Pair program (remote paring is hard, but possible)
  • Respond to change
  • Use micro-frameworks and tools
  • Creativity and craftsmanship
  • Monolithic processes are unfun
  • Are your apps a joy to maintain?

Cucumber

I got the pleasure of seeing Joseph Wilk in person!  He gave his usual presentation on Cucumber, although there were some new features thrown in there.  Tagging was one of them.  The slideshow was pretty involved and if you would like to see an example of his presentation go check out this video:

Outside-in Development with Cucumber and Rspec

View more documents from Joseph Wilk.

Herding Tigers

This was the last big talk of the conference.  It was presented by Danny Blitz, who’s a very dynamic and interesting character.  He basically talked about agile teams, which he refers to as “tiger teams.”  He didn’t really talk about Scrum or XP or the more formal Agile methodologies, but instead discussed his own take on the corporate environment.

Book suggestions:  The Passion of Command, Corpus Business

What is a Tiger Team?

Small development team where velocity and quality are the primary drivers.  The team self-improves, has no meetings (or very few and short), test-automation is taken very seriously with actual QA members on the team.

“A lot of companies fake agile, wtf is a 3 hour scrum?!”

Workplace Archetypes as Animals

  • Tiger:  calculating, cautions individuals who avoid fights they can’t win
  • Cow: herd mentality, afraid of risk, have no original thoughts
  • Bear: big, mellow, live and let live attitude, also avoid fights they can’t win
  • Leopard: unmatched in ferocity, not a good team player though (avoid these)
  • Elephant: C level execs, invincible in battle (even a tiger will not take on an elephant)
  • Hyena: scavenger, dangerous weasels, steals ideas, back-stabbing

Leadership Characteristics

  • Faith and Love
  • Hope
  • Success belongs to the team
  • Failure belongs to the leader
  • The buck stops here
  • Fearlessness (moral courage)
  • Listener and learner
  • Protector

Also good leaders should manage by intent (servant leadership), not micromanage.  They should reward failure, people will make mistakes – let them feel comfortable in making them, as long as people learn.  Demand to be questioned, if your team is afraid of you they will not question your decisions and warn you when something is wrong.  Glorify the lower levels.

Good “grunts” show politeness and professionalism.  (They got it easy.)

Agile is a buffet not a dogma.  Methodologies are wrapped around Agile, *it* isn’t a methodology itself.

1 comment »

Posted in Agile, Programming

Tags:

LSRC 2009 – Day 2

August 30th, 2009

Dave Thomas Keynote

Always a great speaker, Dave came down from Dallas to help kick off the conference.  Dave has been using for over 10 years, and he’s still using it.  He shares his reflections with us as to why he still enjoys programming in Ruby.

Ruby is an interesting language.  It can be described as a multi-paradaim language: object oriented, procedural, prototype-based, and functional (all at the same time).  He also points out that Ruby thinks the way he does, which also means – like Dave (or anyone of us) – it’s imperfect.

We shouldn’t worry about perfection though and instead should be pragmatic.  There isn’t only one way to do anything in Ruby, there is no “right way.”  It’s this ambiguity that helps encourage participation.  If Ruby were perfect there’d be no room for creativity, growth or adaptation.  Ruby is adding stuff – not taking away.

Dave also talked about his experience with being publicly “slammed” by Zed Shaw. He said he realized at that point in time that Ruby is not a community.  Ruby is a tool around which communities form.

Passionate people are messy, Ruby is messy.

Programming Intuition

A lot of people are programmers, very few are great programmers.  The difference in productivity between a good programmer and a great programmer can be a factor of 10.  Ruby rejects the idea that the world is simply two buckets of good and great.

  • Do one thing
  • DRY (Don’t Repeat Yourself)
  • SLAP (Single Level of Abstraction Principle)

How do good programmers think?  Does a good programmer simply boil down to command of the language and ability to recognize/use patterns?  NO!  Programming deals in abstractions and great programmers talk about code as if it were not abstract, but in tangible terms.  Good programmers can “feel” code, there is an emotional reaction.

Our brains are made to adapt to our environment (which we perceive through our senses).  Humans are wired to want physical attachments.  What senses do programmers use?

  • vision (why OO is “easier”)
  • hearing
  • kinesthesia (perception of movement, weight and position)

Code is not 2D, it’s not even 3D, it’s multi-dimensional.  So diagrams are not always useful.  Code sometimes has a “viscosity” and can be felt to push back or resist you.

What do we perceive as beauty?  Elegance?

Cultivate a Sense of Code

  • No specifications / think about it
  • Use tools that help you
  • Practice, use methods that provide immediate feedback

Experts operate on intuition, not on recipes or rules.

  • Master Ruby’s method lookup (it’s worth knowing)
  • Useful to limit scope of magic
  • Can modify individual objects with modules
  • Tr to replace inheritance with extends

Succeeding with Ruby on Rails

This talk was about the owner of Thoughtbot and how they got to where they are today.  Below are some of the notes from the talk:

  • Started in 2003 with 4 people
  • Not everyone wants to run a company
    • wanted to go into business to work the way they wanted to
    • happiness is very important
  • Perl was their “happy language” from Java, but Ruby and Rails ruined it
  • Decided to only do Ruby on Rails, revenue skyrocketed afterwards
  • Hiring is very important and hard
    • hire only people who want to learn and teach (passionate)
    • skilled
    • right attitude
    • salary (the best you can afford, not necessarily that money can buy)
  • Don’t compromise on core principals
  • Be nice

Identify what’s really important for you, don’t compromise on that decision, and be nice.

Hiring Process

When hiring people Thoughtbot first reviews a resume and code of the applicant, before they even do a phone interview.  Then an initial phone call is done, followed by a second interview if there is interest.  The 2nd interview is more technical in nature.  If an application is considered, they have to participate in a week-long immersive pair-programming situation with a developer on staff.  After this last step is then someone considered to be on the team permanently.

Core Principals

  • sustainable development (40 hrs a week)
  • all are technicians (even html/designers)
  • no contracts or outsourcing

Clients

When it comes to client relationships the approach Thoughtbot takes is to “do the best you can.”  This doesn’t always mean you succeed at every project, but you know that you did your best in trying.  Set expectations, be proactive and above all nice.

Thoughtbot does not believe in subcontracting and they insist you should work on the way you want to work.  If a client doesn’t want to work with you then you should ask them to find another team.  In the long run it isn’t worth being unhappy and you’ll just be frustrated (as will likely the client), all around bad.

Client Management

  • project planning form
  • Highrise
  • master services agreement
  • project lead (SM/PM rolled into one)

Design and Development

Like 37Signals, Thoughtbot is a big believer in design first.  They will figure out how a UI looks and works before coding.  This helps flesh out details you might not realize until later, when it’s more expensive to fix.  They practice pair-programming with an iterative, TDD development approach.  Pivotal Tracker is used to manage their backlog.

They also believe strongly that people should do what they enjoy.  Folks are encouraged to work on projects that interest them, there are not set roles or boundaries.  If a designer wants to get more into Rails, he’s allowed to take on some Rail work in a project.  There is always at least two developers per project.  If one becomes bored or wants to work on a different project it makes it possible to swap people out without affecting the project to terribly.

Open Source

Part of the culture at Thoughtbot, they’ve made many open-source contributions to the Rails space.  Abstractions don’t stay internal to the company.  By releasing open-source software they get their ideas validated and legitimized.  Payback includes recognition in the market space.  They also have to support the software less, because the community itself supports the software (crowd-sourced support).

The one suggestion for other companies looking to do open-source contributions:  keep quality high, incubate internally for a while before releasing, make sure it’s something you enjoy using yourself.

Products

The talk ended with the question about why and how do you keep Ruby relevant?

  • consulting scales w/ people
  • but we want a small company
  • products can scale without people
  • make products you use yourself
  • make products you enjoy using

How long will Rails be around for (be popular)?  How long will Ruby be around for?  We have to take responsibility for Ruby and Ruby on Rails so it remains popular.

No comments »

Posted in Programming

Tags:

Wired Article: What Bugs can Teach Bosses

July 22nd, 2009

I was reading an article in the Sep 2008 issue of Wired titled “What Bugs can Teach Bosses.”  The article looks at different animal species and relates them to work patterns and behavior for humans.  It got me thinking about how similar they were Agile principals.  I love when you can find examples in Nature that can be applied to every-day work life.

Ants and Bees – Broadcast Messaging

Ants use chemical signals to transmit messages and bees dance to tell other bees where to find food. This style of communication increases group efficiency by giving everyone access to the information and then individuals can decide what to do with the new information (if anything).

People in Agile organizations benefit from this style of communication as well, commonly referred to as “whole-group communication.”  At the daily Scrum team-members sync with one another doing a sort of “bee dance,” while throughout the day they might be updating themselves through CI build notices, participate in electronic group chats, or view burn-down charts and story boards. (e.g. leaving chemical trails).

Geese – Collective Leadership

Geese fly in a V-formation because it helps conserve energy and so that they can be guided by a leader.  You see, scientists have discovered that no single goose knows the entire route alone.  The lead goose will rotate out, letting other geese take their place.  Each goose knows, or has memorized, their portion of the flight path and they lead the part they’re most familiar with.

Agile teams can learn from this concept.  XP strongly recommends the use of “specialized generalists.”  This isn’t to say that you shouldn’t have experts on your team!  Teams can consult with their subject matter experts, playing off one another’s strengths and weaknesses — which is what makes them more creative and productive than any single individual.  Just like a flock of geese, don’t be afraid to change out leadership for the portion of the flight most familiar to expert individuals.

Worms – Interconnectedness

Worm brains have a mere 300 neurons.  This might be surprising, but the 300 they have are very interconnected.  This exceptional number of connections allows the worm to do a lot, with just a few brain cells.

On a Scrum team the ScrumMaster acts as a hub.  They’re the most interconnected individual working with the PO, tracking issues within and outside the team.  They can interface with other ScrumMaster’s, on other teams, adding to their interconnectedness .  If issues arise, the ScrumMaster can help serve as a guide and help the team avoid bottle-necks.  They can also help “fine-tune” the team’s strategy, especially as new information comes in.

So look at how your own team is working.  Are you leaving “chemical trails,” have you embraced broadcast messaging?  Do you recognize the expert talents of different team members and defer to them when it’s their “time to shine?”  Are you okay with stepping down once your expert role isn’t needed, letting someone else take the lead?  Is someone on your team playing the “hub” role, using their interconnectedness to identify, track, and resolve issues and clear bottle-necks?  There is a lot we can learn from nature…

No comments »

Posted in Agile

Tags:

Working Agreements

June 14th, 2009

Tomorrow is going to be the first offical sprint planning meeting for the team I am on at Trion.  I’ve been doing Scrum since 2006, and I have facilitated a good many planning meetings.  This time I’m not the ScrumMaster, but a developer — so it’ll be interesting to be in a different role.

The first sprint planning meeting is very important because it’s where the team will receive the first glimpse at the product vision.  They also meet one another and establish a framework from which they will work with one another — a working agreement.

Working agreements help teams codify what the rules of conduct are.  They can cover any variety of concerns from “No cell phones on ring during meetings,” to things like “Code is *done* when it has been peer reviewed, signed-off by QA and checked into the development branch.”  These rules help the team manage expectations, especially through the storming phase and into the norming phase.  It should be placed in a visible location near where the team is working.

A working agreement needs to be crafted and agreed to unanimously by the team (not management).  Consensus is very important here, because people cannot claim later to not of been ‘on board’.  The team should revisit the agreement during their retrospectives and decide if they want to add, modify or remove anything.   Below is a real-life example working agreement from a highly productive Scrum team:

  • Tell the Truth!
  • Use the Impediment Backlog for blocking issues
  • Address any issues to the correct party (at the right time)
  • Meetings: be on time, end on time, have an agenda
  • Communicate individual schedule
  • Use sticky note on monitor, email, phone call, etc.
  • Update backlog before SCRUM daily stand-up
  • Be present for core hours:  10am to 5pm PST
  • Communication – to the best of our ability
  • Publish phone numbers and calendar
  • SCRUM is at 11am PST
  • If unavailable for SCRUM, communicate status
  • TDD is a requirement for the project
  • Pairing or code reviews are required for any shipped code
  • When pairing turn off distractions (email, IM etc)
  • Define and adhere to DONE criteria for stories
  • Record accurate (actual) hours
  • Define and adhere to version control rules
  • Don’t break the build!

As you can see anything is fair game.  Working agreements grow over time as the team unmasks issues and finds solutions.  Having a punch-list of rules helps keep agreements fresh in memory so there is no reverting to bad habbits.

1 comment »

Posted in Agile

Tags: