Monday, November 14, 2011

Captions

Agile Retrospectives: Making Good Teams GreatCaptions is a retrospective technique that can be used as a collaborative and safe way to share feelings. The technique is fun and the results can be very insightful and hilarious at the same time.

The process is as follows:

  1. Announce a specific topic for discussion 
  2. Each team member gets n number of index cards where n is the number of team members. The cards are numbered sequentially in each stack. 
  3. Individually, on card #1, members draw a picture to illustrate the topic at hand 
  4. The decks are passed to the right 
  5. On the new deck received from the left, members study the picture on top, then move the card to the bottom of the deck. 
  6. On the next card, members write down a caption for their interpretation of the picture they just saw 
  7. The decks are passed to the right 
  8. On the new deck received from the left, members read the caption, then move the card to the bottom of the deck 
  9. On the next card, members draw a picture based on the caption they just read 
  10. This process is repeated for several rounds until each stack is back at card #1 
  11. Members take turns laying out the decks and reading out and sharing the results with the team 

Note: If the number of team members is even, then start with drawing a picture, otherwise, start with writing down a caption.

Adapted from: Putting the fun back in your retrospectives @ Agile2011

Wednesday, November 9, 2011

The Nordstrom Innovation Lab

At the Nordstrom Innovation Lab, a new team is applying agile and lean startup techniques to move quickly from conception to deployment. The team is acting like a startup within a large organization. They work in a collaborative open workspace and go through several iterations using frequent customer feedback loops to plan out their next iteration. They keep their planning simple and light-weight by using sticky notes and index cards and following agile engineering practices like pairing and test-driven development. Watch this team in action below.

 

http://nordstrominnovationlab.com/

Tuesday, September 20, 2011

The Spinning Lady

Look closely. Is she spinning clockwise or counter-clockwise?

Think of happy places, found memories, poetry, and music. Let your mind wander.

Look closely. Is she spinning clockwise or counter-clockwise?

Solve 3*5=?
Solve 15+5=?
Solve 20+5=?
Solve 25 + 3 =?
Solve 28/2=? 14.

Look closely. Is she spinning clockwise or counter-clockwise?




Pragmatic Thinking and Learning: Refactor Your Wetware (Pragmatic Programmers)Did she switch direction? The idea here is that our brain switches between left and right. If she is spinning clockwise, then we are using the right side of our brain which is responsible for feelings, beliefs, imagination. If she is spinning counter-clockwise, then we are using the left side of our brain which is responsible for logic, math, and science.


Adapted from "Refactor Your Wetware" @ Agile2011

Friday, September 9, 2011

Effective Daily Standups

Thanks to all that attended my talk on Effective Daily Standups at the SA Scrum Gathering Conference. Below is the presentation slide deck and speaker notes.



Saturday, September 3, 2011

Source Code Word Clouds



97 Things Every Programmer Should Know: Collective Wisdom from the ExpertsHere’s a neat way to look at code quality - use source code word cloud generators.
A word cloud or tag cloud is a visual representation for text data. Tags or words are listed and the importance of each word is shown with different font size or color. When applied to well written and clean code, word clouds give us a quick way of understanding what the code is about.
 
 Below is an example from http://fragmental.tw/2009/04/29/tag-clouds-see-how-noisy-your-code-is




Clearly, looking at the second cloud, we know a lot more about the domain than the 1st cloud.

Try it out using the original http://www.wordle.net or http://sourcecodecloud.codeplex.com

Adapted from "Code" @ Agile2011

Saturday, August 27, 2011

Back to the Future!

At the conclusion of the Agile 2011 conference, Todd Little jokingly looked back to the 1st Agile conference in 2004 when agile experts made predictions of the future and came up with the top 8 things that will happen once main stream gets hold of Agile Software Development:

8. The 1st Agile software development conference will undergo historical revisionism, in which it will be told as originally taking place on a farm outside Sundance, with lots of music and on-demand pairing, and announcements in middle of the conference to not eat the brown acid.

7. The Spike channel will ask Ron Jeffries to host an Apprentice-type reality show where agile teams will compete against each other to build software for rocket-packs, X-ray goggles, and invisibility rays. The catchphrase when he gets rid of the failing team each week is “You’re dead fish!”

6. GE will develop 3 year, six sigma certification programs for becoming Agile Certified.

4. You’ll see personal ads like ”Certified SCRUM master seeks product owner with large product backlog for promiscuous pairing”, and “Single Agile Developer with data envy and analysis paralysis seeks customer for private requirements collection; expect failure”.

3. Sun will come up with an innovative, elegant Agile programming language, get people to use it, and proceed to totally screw up the marketing for it and name it with really confusing release numbers.

2. Woman out at bars together will refer scathingly to the guy at the end of the bar who keeps starring at them as a “scope creep”.

1. A paperclip in Windows will pop up periodically and say, “Looks like you’re trying the waterfall method. Want me to pair with you?

Saturday, August 20, 2011

Measuring Code Quality

A common measure for code quality is to measure Cyclomatic Complexity. Cyclomatic Complexity is used to measure the number of linearly independent paths through a program’s source code. The more conditionals (if statements) or the more loops (for, while …), then the more branches run through the code and thus the code becomes more complex. But what is considered to be a good number for Cyclomatic Complexity? What should developers target?


A study by energy (http://www.enerjy.com/blog/?p=198) reveals the following:



There is a 50% chance of errors with a Cyclomatic Complexity of 38 and almost a 100% chance of error when Cyclomatic Complexity is 74. On the other hand, with a Cyclomatic Complexity of 11, the chances of errors drops to 28%.

So based on this study and the above graph, shoot for a Cyclomatic Complexity of below 20 per class.

Adapted from "Technical Debt Assessment and Reduction" @ Agile2011