Analysis In the Spotlight

It’s is with great pleasure that I announce Business Analysis is getting some official attention from both the Agile and Scrum communities! The first set of attention on us comes from the Agile Alliance . . . .

 

During this year’s Agile 2013 conference I talked with many great business analysts and product owners (including co-presenters Inger Dickson and Chris Matts, as well as Kent McDonald, Jake Calabrese, Ellen Gottesdiener, “Kupe” Kupersmith, and Leslie Morse). Toward the end of the conference I remember telling Kent and Kupe we should “take over” the upcoming BBCCon. (The Building Business Capabilities conference is the primary meeting for IIBA, Business Rules, and has tracks for Biz Architecture too!)

Agile Open Jam poster for BBC ConferenceMy simple idea was to run a conference within a conference. I don’t remember drinking during this discussion, but it certainly had all the bluster of a late-night, never-gonna-happen, kind of conversation. For those who don’t know, I am also known to push those conversations into the waking hours. So much so, I generated a list of topics we could share within our “sub-conference.”

As we all know, ideas are cheap. It takes execution to make something great. That’s where Kent McDonald shines. He took our conversation (I do not recall if I ever showed him my notes) and made it real with a proposal to form an official sub-group within the Agile Alliance dedicated to Analysis and Product Management. Further, he received official blessing, permission, and funding for us to share our knowledge at BBC and upcoming events.

Here is the official announcement:

New Agile Alliance Program

Analysis and Product Management in Agile

The Agile Alliance board recently approved a new program, Analysis and Product Management in Agile, with the purpose of providing a way for practitioners in the business analysis and product management communities to share stories, questions, and puzzles about using those skills in an agile setting and to share ideas between communities. The program Chair is Kent McDonald.

 

(Un)conference in a Conference
We’re pleased to announce that the first activity of this program is to facilitate an “(un)conference in a conference” at the Building Business Capability (BBC) conference where attendees can take part in conversations about the intersection of business analysis, business process, and business rules with agile principles and techniques.

 

The members of the Analysis and Product Management in Agile program will curate the outcomes of the discussions and make them available to Agile Alliance members on our website.

 

The Building Business Capability Conference is being held at the Mandalay Bay Resort & Casino in Las Vegas NV November 11 – 15, 2013.  It is the only conference that combines insight into Business Analysis, Business Architecture, Business Process, Business Strategy & Transformation and Business Rules & Decisions to facilitate creating the agile enterprise.  The conference is filling up quickly but registration is still available on the BBC Conference Website: http://www.buildingbusinesscapability.com/

 

We’d like to thank the International Institute of Business Analysis (IIBA) and the organizers of the Building Business Capability Conference for helping us put together a means for members of the analysis, business rules, and business process communities come together to discuss agile approaches.

Agile Alliance Newsletter, Oct 23, 2013

Special kudos go out to Kent for organizing this program and Ellen, who did most of the communication and coordination between the program and BBC. The (Un)conference will run in an open area outside the sessions and keynote Wednesday through Friday. I am one of the hosts, along with Kent, Ellen, Jake, and Mary Gorman.

If you want more information, here are the write-ups by Kent, Jake, and Ellen. Also, Yamo recorded a special podcast with Ellen and Mary. I joined for the last few minutes (at the 30:05 mark) to discuss the Open Jam.

 

Shifting focus to the other good news . . .

Apparently, the Scrum Alliance is also on board with our skill set, too! The next Global Scrum Gathering has a track dedicated to Scrum Product Owners (link to their call for Papers). I’m told this is the first time this has happened, previous conferences pushed their CSPOs into a track with other topics.

 

Note: I am a member of all 3 organizations discussed; IIBA, Agile Alliance, and Scrum Alliance.

TinyStories

How to Improve Your Requirements with Tiny Stories

I presented How to Improve Your Requirements with Tiny Stories at ProjectSummit & BusinessAnalystWorld held in Boston on October 21-22, 2013.

I firmly believe using the Given – When – Then of Behavior Driven Development (BDD) is relevant for business analysts. This talk is probably my best presentation of the material in the last few years.

You are welcome to view the accompanying presentation below. I sill share the link for the accompanying video upon request (and after I upload it to YouTube).

pairon

Pair Programming: Looking from the Outside-In

Last week I learned more about Pair Programming than I gained from all my previous years of working with developers. (As a Business Analyst, I have never paired for a significant amount of time, but I think I’ll be forcing that issue soon!) My team had an hour-long discussion about pair programming that filled me with new insights. Here’s a summary of my notes so you can gain some insight into this engineering practice.

Project Background: ThoughtWorks was hired to develop a set of branded websites for our Client. The team was a mix of ThoughtWorkers and Client developers, analysts, and project management. The first few months were pretty rough with a scope significantly bigger than the timeline. Worse, while we thought we could avoid the 15-year old legacy code and a myriad of systems, we couldn’t and it added significant roadblocks. The result is we struggled for a couple months in the middle of the project. We turned things around and were very happy with the end product, which was due to go live in two weeks. Except the project was cancelled!

The team history — struggling against the seemingly insurmountable scope and environment, turning the project around, and the sudden cancellation (for business reasons, nothing to do with the project itself) — built the environment for very open and honest discussions. Of the 25+ people on the project, almost 15 of us met to talk about Pair Programming. Most of the folks were developers, split evenly between the Client and ThoughtWorks. The Client developers were new to paired programming when they started with this project. Their total experience with pairing ranged from 1-7 months. The final third of the audience was spread among QA, BA, an iteration manager (think Scrum Master), and a Client program manager.

I kicked off the meeting by asking the Client devs if they had experience with paired programming before this, what they liked, and didn’t like about the experience. Starting off positive, they really liked the knowledge sharing and the cross-pollination of new ideas and information.

A month later I was exhausted, but I was completely on board.

Then we got honest and they said it was really awkward at first. “Do I touch the keyboard? Do I not touch the keyboard? I was pointing at the screen with my finger and the other person said they couldn’t see what I was pointing at.” Quickly, another Client dev jumped in and said, “It was intimidating. I don’t like to look stupid. When I work on my own it’s a process of doing stupid stuff, it doesn’t work, doing stupid stuff, it doesn’t work, and finally one day it works. It [paired programming] is like a test.”

“I thought the math meant we could do double,” said a third Client dev. “I was not on board and a month later I was exhausted, but I was completely on board. I would not go away from paired programming at all. You have fixed 10 things without even typing anything because you’re pair is catching things.” After a bit more discussion he came back and finished with, “It’s a different math, but I think the speed is double. It’s more efficient. When you’re with a pair, then you are not checking emails, you are not on YouTube. You are not doing any of that. You have almost no waste of time. It’s quite exhausting.”

From one of the ThoughtWorks devs with less than 2-years experience, the comment came “I learned paired programming and when I write code on my own it seems so much slower. If I could sit down with someone I could talk to it would go much faster.”

ThoughtWorks’ technical lead for the project had some interesting comments on using pair programming. For him, the largest benefits were for the project, not the particular piece of code developers were working on. “The only way to keep everyone marching to the same drumbeat is pairing and rotation. It only works when you have to work with everyone else. I’ve never found any other mechanism for keeping standards on a team.” Everyone was on board with the idea paired programming is about optimizing for the team, not the individual. Reinforcing this point, there are studies pointing to conditions where pairing is less effective, particularly on simple tasks and novice-novice pairing without enough mentoring.

Beyond the general statements about pairing, the team also discussed the best techniques for pairing. One Client dev said, “I found myself doing better where there was only 1 keyboard and we had to pass it back and forth.” They found it’s more engaging when you’re driving. And everyone agreed it is up to the more experienced of the pair to make the other person type.

There is no doubt the confidence of pairing developers is higher than those who work solo. This comes out in a couple ways. First, when giving a daily update on your progress that has been stalled by a bottleneck, it takes the pressure off when you can say, “We’re working on it.” Second, when you’re  in an environment with siloed knowledge, after pairing for a couple days you are willing to say “I’ll try working on that.” On the other hand, if there’s a bottleneck and the key resource is out of the office, the tendency is to look the other way. The devs do not volunteer to help and everyone has to wait for the expert to come back.

The QA lead for the team said he didn’t track the numbers to prove it, but there was a better chance of the story passing a desk check. There is a lower chance of passing the desk check if just one person worked on the functionality.

The conversation went on for a bit more, covering topics such as pair switching, optimizing space and environments, gold plating, and even introduced new ideas like the Ping Pong Pattern. (Did you know using this method in some programming languages may result in switching every 60 seconds?!)

The evening after this meeting I read The Shame of Pair Programming, by Tom Howlett. It’s a great, short read about how bad pairing can be demoralizing. It’s takes both vulnerability and strength. I didn’t see where our team suffered this problem, but it’s something to be watched for. As we talked about in our meeting, it’s not about being an introvert or extrovert, it’s about you. You need to learn how to speak within the pair.

This project was quite the ride. And despite not going live, the closing retrospectives made this one of my favorite projects ever. I feel like I learned more from our ending conversations than on some of my much more successful engagements. Please, continue my learning by adding yours. Add your comments on how paired programming worked for you. This way I, and everyone else, can learn a bit more.

Blow-up the Iron Triangle

I am presenting at the 7th Annual UT Dallas Project Management Symposium being held August 15-16, 2013. 

The conference theme is Project Management: Optimizing Value to Stakeholders. I thought this topic, Blow-up the Iron Triangle: Rethinking Software Project Approaches and Goals to Increase Business Value was not only catchy, but very relevant to the theme.

My inspiration was Jim Highsmith’s article, Beyond Scope, Schedule, and Cost: The Agile Triangle. It’s a great introduction to the concept and I expand on it a little bit with an example and the implications. I want to give a big shout-out to Jim for reviewing my accompanying paper and giving feedback.

You are welcome to download the paper and view the accompanying presentation below.

Impact Mapping @ Agile 2013

I was delighted to co-present a workshop with Inger Dickson, long-time colleague and friend. We were sharing our take and experience on Gojko Adzic’s latest work, Impact Mapping.

Last October, Gojko gave us a preview of his book (available on Amazon) during a training workshop last October. Agile 2013 falls during his annual family holiday and he was gracious to let us share his material.

Inger used his material with a charity in Brazil, Corpos Percusivos. Her experience formed the basis of our examples. Combined with a cheat sheet and a few instructions, the participants broke into groups and practiced what they heard. We got some really good reviews and the Net Promoter Score for our talk was 80%.

Here are the slides from our pre-activity presentation:

super duper fast domain modelling

Don’t blame me for the extra “l” in “modelling,” Chris Matts came up with the title and he’s from the UK. They claim to know the “mother tongue” better than we do in the states, but they sure do get a bunch of things wrong!

Okay, enough jesting. Chris and I presented Super duper fast domain modelling at Agile 2013. It was a verbal walk-through and workshop based on the article by Chris and Kent McDonald, The Seven Information Smells of Domain Modelling.

The presentation went well. It went even better considering we only met 2 days previous. Well, we met online and talked over the phone, but we met face-to-face  only at the conference.

Please leave your comment on our slides or the talk below.

Skills for Success: Professional Development Day @ IIBA Minn / St. Paul

I will be giving a new version of my talk about Behavior Based Requirements at this year’s Professional Development Day in Minneapolis / St. Paul. I am excited because I have reworked the entire presentation to both show my passion and give attendees a chance to practice using the Given-When-Then requirements format.

The conference title is Skills for Success: Evolving as a Business Analyst and my presentation is “How to Use Behavior Based Requirements to Build Understanding & Save Your Project.”

The event is on Monday, April 15 at the Earle Brown Heritage Center outside of Minneapolis (registration link). This is one of the premiere PDD events in North America and I am honored to be speaking. If you are in the area, please come, engage, and learn from the outstanding speaker line-up and local BA community.

 

Post conference update: Here is the published version of my slides: