Tuesday, April 7, 2015

How JIRA Helped Our Team

A colleague at a different client asked about what out-of-the-box JIRA reports we use and how they benefited our team.

Whatever you think about physical card walls versus electronic tools, the fact remains that some teams use them and JIRA is a common one.

Like many good charts, many conclusions can be drawn from the reports below. I have explained one or two specific benefits that my teams have reaped from them:

Burndown: We used it to track daily movement of cards (or lack of same) at standup and it worked to identify that developers we incurring risk by working on individual cards for several days.

Sprint Report: We used it to look at what work was added/removed from the current sprint, and what cards were finished. It worked because it enabled us to detect that developers were pulling work ahead while there were still incomplete cards in the sprint. This gave us an opportunity to have a conversation about swarming to get cards over the finish line and breaking down silos.

Velocity Chart: We used it to to compare committed/completed of current sprint verses past sprints. It worked because we detected a trend of increasing overcommitment and the team was able to adjust sprint commentments so that PMs had better projections and the team reversed the growing feelings that they were failures.

Version Report: We use it to project when our project will be finished. It worked because the PM learned that the team was not going to deliver all the scope by the needed date. The PM and the business were able to agree on reduced scope and the version report projected a good delivery date.

Wednesday, March 11, 2015

What do you expect from a tech lead?

I've been thinking about the role of Tech Lead. It is one of those titles where I think everyone "knows" what it means but most of us haven't tried to define it.

It goes without saying that a tech lead has to be strong technically, but I think what makes or breaks a tech lead is whether they have strong leadership characteristics. I see those characteristics falling in three categories (Self / Team / Business):

Has an active desire to work with people
Possesses "confident humility"
Can accept a position with less than 100% of time spent working on code (sometimes a lot less)
Knows where the gaps in their knowledge are
Is not concerned with "looking good"
Can delegate work

Can facilitate conflict resolution and team decision making
Wants team and individual members (including self) to grow and learn
Wants team members to succeed and actively works to ensure they receive recognition for it
When necessary, can combine their own experience with the thoughts of a team and render a decision
Understands that people have different learning styles (visual, tactile, auditory, etc)
Shields team from outside influences, so they can get their work done (much as a scrum master does)

Understands the value that IT provides to business
Can speak to technical decisions in a way that addresses business partners' priorities
Understands and accepts that business may only wants to pay for "good enough" solutions, not "best" solutions.

What do you think? Do you agree/disagree with the characteristics I've identified?

Wednesday, January 14, 2015

What are the units for Story Points?

A co-worker and I were discussing estimation on agile software development teams (Yeah, I know - #noestimates. That was off the table here). I asked him what a story point represents. He said "effort", which PMBOK defines as "measurable work units", and pointed me to a post by Michael Cohn:
"...story points are about time—the effort involved in doing something. Because our bosses, clients and customers want to know when something will be done, we need to estimate with something based on effort. Risk, uncertainty and complexity are factors that may influence the effort involved."
My friend went on to write the following formulas:

(SumOfRemainingEpics + SumOfRemainingStories) / Velocity = Forecasted Duration (+/- uncertainty)


Forecasted Duration / Team Capacity = hours

I wasn't so sure that this demonstrated that story points are about time, so I re-wrote his formulas adding units (and dropping uncertainty):

SumOfRemainingEpicsAndStories(points) / Velocity(points/week) = Forecasted Duration(weeks) 


( (SumOfRemainingEpics(points) + SumOfRemainingStories(points)) / Velocity (points/week) ) x Team Capacity (hours/week) = hours

Management wants estimates of duration which we calculate according to the first equation by dividing points by velocity (Cohn mentions this too). In either formula, points cancel out. What that says to me is that units of story points don't matter. We can estimate in complexity, risk, time, or elephants! The upside of this is that non-timebased units for points prevents management from translating stories directly back and forth between points and hours, which can cause friction between the team and management

Monday, September 29, 2014

Agile Coach Camp Session - Every Tool Sucks

Yesterday, I returned from Agile Coach Camp 2014 in Indianapolis. Here are my recollections from one session:

Every (card wall) Tool Sucks:

Reasons for card wall tools:
  • reporting / analytics
  • distributed / dispersed teams
  • backup / archive
  • regulated industries?

Problems with current tools:
  • hardware costs not low enough for large monitors to show the entire wall
  • when not able to replace physical wall completely, keeping two things in sync is extra work
  • teams often do not keep electronic cards up to date
  • either restrictive workflows or so general-purpose as to make configuration difficult and costly
  • commercial choices are costly
  • continuous improvement of workflow not always easy or quick
  • no participan

What might help:
  • great reduction in price of technologies like large Microsoft Surface monitors
  • QR / barcode recognition, OCR
  • home grown tools? still runs risk of cost/time to improve workflow, process lock-in

Other ideas:

Friday, July 25, 2014

Automated testing against physical iOS devices

Update the iPhone's iOS version to the latest

Install Xcode, Apple's IDE for developing iOS software:

Install Homebrew, a package manager that allows user to install, remove and updated applications and packages:
ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"

Download SafariLauncher, a simple IOS application that automatically launches Mobile Safari after a certain delay:
git clone https://github.com/budhash/SafariLauncher

If you are not already a member in Apple’s iOS Developer Program, spend $99 and join.

Build SafariLauncher in xCode:
{ Tell about setting keys and missing field(?) }

Install ios-webkit-debug-proxy:
“The ios_webkit_debug_proxy allows developers to inspect MobileSafari ... on real and simulated iOS devices”
brew install ios-webkit-debug-proxy

Install appium:
brew install node
npm install -g appium
npm install wd

Launch ios_webkit_debug_proxy:
ios_webkit_debug_proxy -d
Go to http://localhost:9221/
You should see “iOS Devices” and nothing else
Connect iPhone
You should see “1. localhost:9222 - iPhone” where localhost:9222 is a hotlink
Disconnect iPhone.
Refresh browser. localhost:9222 is no longer a hotline
Reconnect iPhone
Refresh browser. Hotlink is back.
Click link and see: “Inspectable pages for iPhone:”
Launch Safari on iPhone and go to google
Reload browser on Mac and see a line added to the page: “1. https://www.google.com/” where https... is a hotlink
Click hotline and you will see ios_webkit_debug_proxy tool, which you can use like Firebug to inspect elements on the page.

Get the UDID of the iPhone:
When you see your UDID in iTunes, you may need to right-click it and select Copy. Keyboard shortcut may not work.

Run appium server:
In a new terminal shell, type:
appium --session-override

Write a test that uses SafariLauncher to open your website and make Selenium calls to test the site:
{Beyond scope}

Run your test against the iPhone simulator:
In another terminal shell, type:
mvn -Dtest=com.saucelabs.appium.SimulatorSafariTest test
Watch as the simulator starts (SLOW)
You will see SafariLauncher start (SLOW)
You will see the website launch (SLOW)
You will see your test steps performed.
Look at output of appium window.

Stop appium server:
In the terminal shell where you launched appium, type ctrl-c

Run appium server and tell it the id of the iPhone you want to use:
In same terminal shell used for , type:
appium --session-override --udid e8fae...719
Use the udid for your iPhone, not e8fae...719 shown above.

Run your iPhone test:
In the same terminal shell you used to run the simulator, type:
mvn -Dtest=com.saucelabs.appium.iPhoneSafariTest test
Fix any compilation errors
Watch iPhone screen.
You will see SafariLauncher installed
You will see SafariLauncher run.
After a delay, SafariLauncher will launch your website in Safari.
You will see your test steps performed.
Look at output of appium window.

Saturday, March 9, 2013

Sunday, March 3, 2013

I'll be Presenting at Agile and Beyond 2013!

I'm excited to announce that I will be presenting at Agile and Beyond 2013, this Saturday, March 9 in Dearborn, Michigan! It's a great conference, even if you don't come to hear me. ;) There are still seats open. The website lists the price as $129, but if you contact me I can give you a discount code that will get you in for $79.

I will be presenting the talk that I gave at Agile Groupies in October of last year, "Refactor Your Software Career." I will be talking about my three-year journey from stagnant developer to my awesome position today with Pillar. A key component of that journey is my idea of Transformative Networking, which is a way of identifying events that will allow you to simultaneously increase your tech skills and expand your network. In short, the events that I found the most worthwhile for improving my career met most or all of the following criteria:

creating value in desired field with others in person with people in target

If you can't make it to my talk, you can get my original deck here, or I will be publishing my new deck shortly after Agile and Beyond this weekend.