Be Like Aaron

A colleague of mine died on Friday and the internet is aflame with sorrow and anger. I pray his family sees the outpouring and feels within the lives he touched and love he generated.

Aaron Swartz, a technical prodigy and activist was being prosecuted for allegedly stealing thousands of documents. A quick search will leads you to lots of details about the circumstances around Aaron’s involvement and the justness of Justice in his case.

Aaron and I first met last June and again in November, but I couldn’t say he knew who I was. Our meeting was on a bus and we were part of a rolling conversation covering the the state of business analysis at ThoughtWorks, activism, world affairs, media and branding, privacy, the security apparatus surrounding international travel, and more. In these many topics it was quickly obvious I knew about one or two issues. Aaron knew about everything else. It was intimidating, even more than usual, to be around someone who was so young and obviously better informed than I am.

As many have said, Aaron was a prodigy. And when you read enough, of his own words and those who knew him, you learn his technical abilities were only part of the story. In truth he was much more.

How many times have you wondered how something worked or why something wasn’t just a little better? Aaron wondered that, too. Aaron’s curiosity was childlike, asking why without any pretext or presumption. He understood the problem was with the systems trapping people into a course of action instead of the individuals. He worked to put together all the parts into a coherent whole and the motivation behind that whole. He believed he could work hard and make a change. He believe he, and we, could change the world. And then he worked to make it that way.

Forget about his prodigious skill. Forget about what he built so far. If you can, forget about all we have lost with his passing. Instead, dedicate yourself  to doing what Aaron did. Find a problem. Choose to understand the big picture instead of complaining. And then do something to fix it.

Aaron asked lots of questions, and then he offered himself and his talents to the solution. As we start 2013, I cannot think of a better resolution to make than to be more like Aaron.

Scale

Measuring the Analysis Process

I’ve previously written about measuring requirements and business analysts. I am concluding the series with my current thoughts on measuring the analysis process.

What_gets_measured_gets_done

This quote is a truism is because it’s how we work. Measurements help us identify areas we should focus on or improve. Measurements let us know when we succeeded, or not. I love the idea of measuring BAs and yet, I have spent years balking at the idea of measuring requirements and BAs. It doesn’t work very well in practice.* I had cause to rethink the how to measure BAs when one team I worked on took down the following action item, “Decide (if,) how and what BA velocity to track.”

512878595_dae3c75aab_o

Measuring Business Analysts; Don’t KPI Me

Good managers often ask, “How do I know my team is performing well? How can I spot which folks need help? Who should I reward for a job well done?” In today’s busy world, where managers have significant responsibilities in addition to nurturing their team, measurements and metrics can be a a help.

Unfortunately, it is really easy to measure analysts poorly.

book jacket

Read “Discover to Deliver”

In Discover to Deliver: Agile Product Planning & Analysis, Ellen Gottesdiener (author of The Software Requirements Memory Jogger and Requirements by Collaboration) and Mary Gorman tackle one of the largest problems facing Agile and Scrum software projects, how to successfully integrate the ideas and tools made so popular over the last decade into working, valuable solutions.

LaoTzu(310x398)

Test Driven Retrospectives

TL;DR: Retrospectives can lead your team to becoming a powerhouse. One method of ensuring you making real improvements is Test Driven Retrospectives, where you define the desired state during the retrospective. By writing provable statements ahead of working on the task, you ensure everyone has the same understanding and knows what successful change looks like.

easy-button

Agile User Stories Are Easy (IIBA Fort Worth)

I had the pleasure of speaking to the IIBA chapter in Cowtown last night. That’s Fort Worth for those of you unfamiliar with the Great State of Texas.

Total attendance was 15 people and we had some good conversation. There were not many questions during the presentation, but enough to let me know they were listening. I was touched a few folks from the IIBA Dallas chapter drove over for the meeting, thanks.

Holly Millet, a guest at the event, was kind enough to run the camera and record my presentation. If you are interested in seeing this, then please let me know and I’ll put it online and provide a link.

This presentation is at an introductory level, aimed at Business Analysts who have not worked in an Agile or Scrum for a significant period of time. I do not by any means cover everything it means to be an Agile BA, but rather focus on the elements of good stories, including writing Acceptance Criteria in a Given – When – Then format. This latter section should provide some value for anyone not already involved in the format. Unfortunately, with only an hour, I include enough content to push out interactive activities.

In August I coined the term Behavior Based Requirements to describe Given-When-Then and some of the related concepts to BAs. If this is your first introduction to this format for capturing and communicating value, you can find much more information on my resource page here.

As usual, I am posting a version of the slide deck here for attendees who want to view a copy of the slides. I typically shift the slide order just a tad to make more sense for reading at your desk. This slide deck includes references and mentions the mighty shoulders I stand upon when presenting.