Thursday, January 12, 2012

Arduino | Blink LED Two

I recently acquired an Arduino Uno circuit board which is programmable via USB.  I can flash the circuit with a custom program written in a "C" like programming language.




/*
 * Example Arduino sketch
 */

int ledPinYellow = 10;
int ledPinGreen = 12;

void setup() {                
  pinMode(ledPinYellow, OUTPUT);     
  pinMode(ledPinGreen, OUTPUT);     
}

void loop() {
  digitalWrite(ledPinGreen, LOW);
  digitalWrite(ledPinYellow, HIGH);
  delay(250);
  
  digitalWrite(ledPinYellow, LOW);
  digitalWrite(ledPinGreen, HIGH);
  delay(250);              
}



Wednesday, October 12, 2011

End a Meeting, with Style

"Welcome to my meeting.  blah, blah, blah.  Thank you very much, good bye."

This is the standard format when holding a meeting.  It can be over the phone, in person, or even on Skype.  The meeting may have only yourself and one participant or it may have dozens of participants.  If you are leading the meeting, you are charged with making sure it starts well, stays on topic and it absolutely must end well.  I like to end my meetings in style!  Saying, "Thanks, good bye" is just too boring and doesn't motivate anyone to share in the team vision and all that stuff.

Sometimes facilitators say "You're dismissed."  Let's see how that sounds, "Welcome to my meeting.  blah, blah, blah.  You're dismissed."  It sounds like some is getting fired or at least they should leave and not come back for a long time.

If you are in the military, you might say "As you were" or "That's all for now."  For my team meetings, these sound worse than "Thanks, good bye."

I hold a lot of meetings; at least once per day.  One week, I tried ending meetings by saying nothing, really!  It confused so many people because they didn't know if they could leave or if I left to get something and would be right back.  Meetings need clear endings that make people feel like they are part of the group and can transition to the next activity.

Let's review some other popular saying:

In David Weber's Honor Harrington book series,  Captain Harrington would end each discussion by saying "Let's be about it."

Jack Campbell's The Lost Fleet book series, Captain John Geary says "To the honor of our ancestors" after every formal statement he makes.

Star Trek's Jean-Luc Picard says, "Make it so" or "Engage."

Marvel's Avengers, Iron Man gathers his team by saying "Avengers Assemble".  He'll even say "Avengers Disassemble" when he wants them to separate.

Even religious groups have their own peculiar sayings.  You may be familiar with the phrase "Go now in peace."

My favorite saying however, to end a meeting, comes from the "Back on your heads" joke.  If you want to use this quote to end your meeting, you'll first need to tell the joke.  It can be a little crude so feel free to make it PG to suit your audience.
http://www.jokesgallery.com/joke.php?joke=2223&id=1

What do you say to end your meetings?  Please comment below.

And by the way, back on your heads!


Thursday, September 8, 2011

Scrum : Tracking Impediments


On a Scrum team, an impediment is anything that prevents the team from being productive.  Ideally the Scrum Master is responsible for tracking and resolving all impediments.  However, when there is no Scrum Master, teams often turn to tracking tools like Bugzilla, JIRA, Mantis, and Team Foundation Server.

I've tried a few different techniques for collecting questions and impediments during a sprint: spreadsheets, issue tracking tools, post-it notes, the notes app on my smartphone, etc.  Every time I attempted to use an issue tracking tool to organize impediments, I come back to the same conclusion: it adds a level of separation between the scrum team and the Product Owner that prevents direct communication and mutual understanding.

The Agile Manifesto says it best, “Individuals and interactions over processes and tools”.
http://agilemanifesto.org

When there are a lot of questions and impediments it usually means the story is not well scoped or is too big and should be broken into smaller stories.  Sometimes teams work on many stories at once instead of one story at a time.  The term for this is Work in Progress (WIP).  Just like in the Lean Software Development, I encourage Agile & Scrum followers to limit the WIP so that several stories are not partly completed at the end of the sprint.  Limiting the WIP also allows everyone on the scrum team to have a mutual understanding to answers from the Product Owner, a core concept in Scrum!

 
In Scrum, there is a dedicated role called the Scrum Master who is responsible for resolving all impediments and making sure the scrum team (Dev & QA) have direct access to the Product Owner and their delegates.  I’ve seen some Scrum Masters use a tool or a spreadsheet but normally they just use a post-it on the task board so that everyone can see.  If the answer is also put onto the same post-it, there’s no need for an extra tool; the existing Scrum process has a built-in way to manage answers to questions & impediments.



Wednesday, August 31, 2011

Scrum: From Estimates To Done


Scrum teams require
A Definition of Done
Consistent profit

Software Developers and Quality Assurance are sometimes pitted against each other when giving Level-of-Effort estimates. The winner is usually the individual with the strongest personality; not really a way to give consistent or accurate team-estimates.

The way a Scrum team solves the Dev vs QA effort estimate problem is by incorporating both the Dev and QA estimates in a single Story size. Scrum prescribes Devs and QA to be on the same team, working on the same Story at the same time, and sharing a common Definition of Done (DoD).

I was on a team that went as far as putting the DoD as the first thing you see on the Backlog tool; it was even on a large poster when you walked into the office. Below is an example of a DoD. A story is not Done until all four of these are met.

DoD: A user story is Done when:
  • All acceptance criteria are met and accepted by the Product Owner
  • All acceptance criteria are met and accepted by QA
  • 80% of code is JUnit tested
  • All happy-path features have automation tests

I encourage you to come up with your own Definition of Done. Your team can review the DoD during the Sprint retrospective. You will see the story sizes become more accurate, you will have less assumptions about what should be accomplished for each story, the end product will be more consistent, and frankly the Devs and QA will get along better.


Wednesday, August 17, 2011

5000 Facebook Likes


Click five thousand likes
Your facebook friends will wonder
When you are silent