LeslieJ.net

A few weeks ago I read a Harvard Business Review Blog Network article and tweeted: “@lesliejdotnet: Just read @HarvardBiz @dorieclark‘s “Five Things You Should Stop Doing in 2012″ http://t.co/O7PWthPu (12/15/11) #BAOT translation to come.” So, here is the #BAOT version as promised.

In the post Dorie elaborates on 5 key points in a general way, here I have borrowed her 5 key headlines for things to avoid in 2012, and elaborated in relation to the Business Analyst role.

“1. Responding Like a Trained Monkey” The take-away from the original article is about focusing on work and avoiding the triggers within society that force us to multitask (i.e. e-mail, instant messages, text messages, Twitter mentions, Facebook notifications, Words With Friends reminders, etc.). In order to do true requirements analysis (and many other key BA activities) its important to have truly focused time and attention on the task at hand. Taking time to tune-out of icons, buzzes, and chimes that plead and beg for our attention will allow us to complete higher quality work in shorter periods of time.

“2. Mindless Traditions” Regardless of the SDLC methodology your organization follows I feel confident that there are tasks you complete, documents you produce, or meetings you attend that truly add zero value. In fact, they may have a negative impact on productivity and morale. So, be a thought leader and a proactive advocate for optimizing the effectiveness not only of your BA processes and procedures, but of the overall SOPs for your organization. (Side note: I think the reference to sending Holiday Cards is a good one. This was the first year I had sent them out in MANY years and it was sort of stressful – and likely did not make much impact on the recipients of the cards.)

“3. Reading Annoying Things” My BA twist on this is really related to focusing on reading the right things. If you’re going to take the time to improve yourself, this year focus on increasing your BA Toolkit and expanding your knowledge of the many techniques a BA can use and the right situations when you should employ the techniques. This will immensely increase your effectiveness as an analyst and your street-value on the job market.

“4. Work That’s Not Worth It” Produce just enough requirements documentation that has the right level of detail at the right time and with the highest quality you can. The most important aspect of this is focusing on the true business value and benefit case of the requirements. Don’t let your project team waste time implementing requirements that are not really needed by the business and are more the wants, desires, and requests of the moments. Leverage the Enterprise Analysis skills from the BABOK® and make your IT team one that is a strategic partner for the business that only does the work that is “worth it.”

“5. Making Things More Complicated Than They Should Be” Stop the hallway conversations, skip the politics, be a transparent and candid BA that escalates risks, identifies impacts and dependencies and produces requirements that are concise, readable, testable, and unambiguous. This will avoid unnecessary complication on your projects and make everyone more productive.

Towards the end of the piece when elaborating on #5 above, Dorie references Eric Ries new book The Lean Startup and states, “developing the best code or building the best product in the world is meaningless if your customers don’t end up wanting it. Instead, test early and often to ensure you’re not wasting your time. What ideas should you test before you’ve gone too far?” I think this is important because it ties into the notion of Agile Development practices and honestly relates to more than #5 on the list of things to stop doing.

• Prototyping early and producing working software that your stakeholders can review in an iterative fashion leveraging Agile Principles helps you…
  • Avoid Work That’s Not Worth It
  • Stop Producing Annoying Things (aka Requirements) that other people have to Read
  • Escape Mindless Traditions of deliverables and documentation that do not add value to the SDLC
  • Cease Responding Like a Trained Monkey and working on all the features the business requests and starts forcing collaboration and partnership to add value to your organization

May 2012 bring you a great year of increased productivity and focus in your role!

The Elevator Pitch is to the Requirements Benefit is inspired for you by the following tweet: ”@EntMagazine How to pitch your business in 60 seconds or Less: entm.ag/t52rAO by @carminegallo”

I’m out on my own now. I left the giant Fortune® 50 company I worked for. I’m talking to small companies about potentially joining them full time and I am loving the freedom. Beyond that I am immensely optimistic about the opportunities. So for many reasons you are seeing updates to the site, and for many reasons this post from Entrepreneur Magazine was engaging and relevant for me.

Relevant in what ways you ask?

• I have to be able to clearly articulate why I left a very intriguing and growing Fortune® 50 eCommerce team.
• I have to be able to articulate what I am doing now to add value to new clients (i.e. people that can give me money so I can pay my bills).
• I can always improve the way I approach business analysis (have you noticed I derive inspiration and ideas from many verticals and disciplines?).

After reading this article, I modified Carmine’s list of four questions into what a BA (whether Agile or Waterfall) should be asking of their stakeholders.

1. What do you do? –> What should it do?
2. What problem do you solve? –> What problem does it solve?
3. How is your product or service different? –> How is it different from what is done today?
4. Why should I care? –> What business value does it add?

Please note, I did make “stakeholders” generic above. I did this intentionally. I originally wrote “business stakeholders” but I realized in fact, that the IT stakeholders are almost more important because of questions #2, #3, & #4. As a BA we know all too well that our IT stakeholders are phenomenal at telling us “how it should do it” – but are historically horrid at telling us the answers to those remaining questions (why it should do it, the problem solved by doing it that way, how we can differentiate by doing it like that). Getting the true problem statement, differentiator, and value proposition out of the IT constituents will help us as BAs convey the importance and value of more technical requirements.

The Gist of the Article
Essentially the article, “How to Tell Your Business Story in 60 Seconds or Less,” conveys the importance of entrepreneurs having the ability to clearly summarize the value proposition of their new venture to investors in under 60 seconds. It really is important. I’ve had a start-up of my own and you have to have the canned statement ready when people ask you what you do and why they should believe in/trust you. (I can assure you it was not my dashing good looks that got me contracts when I was a geeky college student with a web development company.)  You almost have to have the story embedded into your DNA, its like having a tape recorder as a part of your voice-box and when someone asks you, you just hit rewind and then play again – spitting out the same paragraph over and over again. Carmine does a good job of emphasizing the importance of this, and offers a good suggestion for summarization (as noted in the list of 4 questions above).

The General BA Tie-In
I can’t tell you how many times I have spaced out listening to a stakeholder. And less attractive for me to admit, I don’t even want to imagine how many times people have spaced out listening to me talk about a requirement. (Notice there is no “s” on that – I truly mean a single requirement.)

If you, as a BA, cannot articulate the intent and benefit of a requirement in less than 60 seconds then you’re not doing the best job you can do.

• You won’t be able to effectively communicate with your executive sponsors or executive management if they ask about it. (Communicating at ALL levels of the organization is a paramount skill to possess.)
• Your developers will tune you out when you start talking. (They want direct, concise, to-the-point explanations of what they need to do/why they need to do it.)
• Your business stakeholders will likely perceive you as overly verbose. (They need the confirmation that you “get” what they are saying, what they need, and that you can articulate it for them. Not to mention, if you don’t elicit all of this information from your business stakeholders you are not doing your job,)

The Agile Tie-In
Requirements in agile are most often depicted by User Stories. They are a STORY – using the guidelines from this article allow you to frame up the majority of the information you need to convey within a user story, help you partner with the  product owner in order to understand true business value, and tell a story about the feature/capability of the system.

User Stories are also meant to foster the conversation. Remember, agile is about “conversation” not “documentation” – so internalizing these key benefits from an elevator pitch along with the primary aspect of a user story (actor, action, benefit) you can nail the communication during daily scrum sessions when team members have questions and you can succinctly summarize for team members during story review and story grooming sessions. The quickness of the conversation is also important. Iterations/Sprints are meant to be short, and very moment is valuable as you want as many minutes available for producing working software as you can get. The more concisely the requirements can be articulated, the more efficient the team, the higher the velocity, and the more business value gained.

Lastly, the User Stories should (if at all possible) be articulated from the end-user point of view. Asking these questions will get you to that level of detail and allow you to spin something around to showcase business value and benefit.

More context to come on my recent professional transition, for now I leave you with a note wishing you Happy Holidays!

Last night there was boxing on Showtime. My husband likes watching it. I, on the other hand, am pretty good at sleeping through it. My slumber last night must not have been too deep though because I have a vague memory of talking to him during the match and this morning he certainly assured me that I did.

The conversation I am about to recap for you is a likely sign I am thinking a little too much about work.

Some History
The IT team I work with converted from Waterfall to Agile in January of this year. We are in the process of wrapping up operational enhancements that we call “Agile v2″ in the hope that we can address some of the gaps in the processes we rolled out at the beginning of the year. This has meant countless working sessions, process flows, and debates on the good - bad – and ugly of the way the teams have been doing theirwork. It has also meant receiving Agile-Purist advice from our Agile Coaches as well in order to help us keep true to the methodology we are committing to.

Last Night’s Conversation
As my husband tells me, in the middle of the match I started trying to explain to him that boxing was like agile software development. It probably went something like this…

Me: (picking my head off of pillow) “Hey, ya know, agile is sort of like boxing.”
Him: “What?”
Me: (sleeping)
Him: “Honey, did you say something?”
Me: “Huh? Yeah…Agile. It’s sort of like boxing.”
Him: “What are you talking about? Just go back to sleep.”
Me: (somewhat incoherently) “No, it’s true. Agile is like boxing because…[something nonsensical]”
Him: “Sweetie, you’re half asleep. You’re not making any sense.”
Me:(somewhat belligerently) “I am not sleeping, they really are similar because… [something nonsensical]“

There were probably some pretty significant pauses between my rebuttals and it probably continued on for several more rounds. This morning we got a good laugh about it, and he was convinced I was completely out of my mind. But of course I couldn’t stop thinking about it, and once I drew a parallel in my head I had to try and convince him that Agile and boxing really are similar. My rationale was that like agile…

• Boxing has rounds (similar to sprints)
• During the breaks between each round they talk about how it went (a retrospective)
• Before starting the next round they talk about what they should do (sprint planning)

Very simplistic, but at least amusing – and very likely I’m in need of a break from the office.

Back in the days of Justinsane Design, my Web Development start-up from college, I started collecting fortunes from fortune cookies. They were originally taped to the frame of my iMac monitor, and once I switched computers they moved to a hot-pink sheet of construction paper. Over the years the fortunes started hanging off the edge and they were accumulating in a folder so I decided to get a little crafty and preserve them for display.

Maybe I’m lucky, or maybe its simply a coincidence, but I tend to get good fortunes. Not only good ones, but relevant ones. For example, one reads: “You will do well in the field of computer technology.” Yeah, go figure.

Recently I was adding some more fortunes to the frame and as I was scanning through everything on the board I realized lots of them can be applied to the work I do, so tomorrow I will kick off “The Fortune Series” – a set of posts inspired by the fortunes on my wall.

The August Book Club for CLT Business Analysis has been posted.

We decided to go a bit off-topic for the late-summer gathering. Why read another BA book when we could read something about one of the most fascinating companies around these days? So, here it is:  “What Would Google Do?” by Jeff Jarvis. I will be taking a participants view for this discussion and turning over the reins to Reid Parker, one of the CLT BA members. I look forward to his facilitation of the discussion. (Get the book on Amazon now.) The discussion will be on Thursday, August 11, 6:00PM. Light Dinner & Beverages will be served. Thanks again to ettain group and Macquarium – our gracious sponsors!

REGISTER NOW!

Going through e-mail, checking LinkedIn discussion groups, and surfing twitter this humid Saturday evening.  I just finished reading “How to Stop the Dreaded ‘Decision Drift’” from Blogging Innovation – that I was directed to from the Innovation Excellence group on LinkedIn.

I thought there were two really strong take-aways for the business analyst.

Make Your Thinking Process Visible
When in requirements elicitation or analysis sessions its extremely important to ensure all stakeholders are on the same page (and even more important when it is a sensitive subject or something people are passionate about – as the article references). The last thing a BA needs is for people to walk away with their own version of understanding in a situation.

In order to eliminate any confusion try out:

• A process flow that outlines your personal decision making / analytical thought process
  • Include the key decision points in the flow to show that you covered a variety of possibilities and angles on the situation
  • Tag possible outcomes with an ID
• A clear list of the inputs that influenced your decision making
• Grid out the affected stakeholders with a column for each possible outcome to clearly illustrate how each is impacted by the options

Use Past-Tense Questioning
As the article references, this can get stakeholders to change their perspective and analyze a situation as if they have already completed the work. This can also be an effective way of evaluating already identified action items during the session in order to ensure the list of to-dos are complete and accurate. This is a technique I’ve never tried before, but am looking forward to giving it a go.

Today I had the great fortune of talking to many people passionate about the BA role. It was a mentally satisfying sort of day in that regard, and for that I am appreciative.

In one of the conversations someone referenced my blog, and thanked me for the writing I had been doing. It was at that moment I shrieked inside thinking, “Oh goodness, I don’t write as much as I should.” After politely acknolwleding their praise I was asked, “How are you inspired to write what you do?” It was an easy answer, “Nearly everything.” So, perhaps that brief moment within a lovely day was enough to get me back on the wagon. I have probably 20 posts fleshed out with bullet points within the drafts of my content management system, and pink flags throughout my trusty notebook marking where I jotted down blog post ideas. It just might be the time to start writing again.

So here I am at the moment, sitting in a Starbucks in Mooresville, NC watching the rain pour (litterally) and listening to the thunder roar (very nasty). After logging on to the free Wifi I was directed to the Starbucks Digital Network and was quickly attracted towards a call-to-action for an article from The Economist titled “Back to the Coffee House” and it was within the second paragrah I found the most random inspiration…

…The news industry is returning to something closer to the coffee house. The internet is making news more participatory, social, diverse and partisan, reviving the discursive ethos of the era before mass media. That will have profound effects on society and politics.

I’m not entirely sure why my brain took that and contorted into a business analysis related concept, but it did – and here it goes.

Technology projects started somewhere, right? Like back in the early days of IBM (wow, 100 yrs ago!) when companies started exploring technology projects and how they could change their enterprise…  As The Economist article stated, “THREE hundred years ago news travelled by word of mouth or letter, and circulated in taverns and coffee houses in the form of pamphlets, newsletters and broadsides. ‘The Coffee houses particularly are very commodious for a free Conversation.’” You have to think that back then it was much more ad-hoc, almost like a coffee house. Project needs travelled by word of mouth, there were no guiding tenants for project management (PMI), IEEE standards for operational exellence or SixSigma signs of efficiency and quality. There certainly were not professional authorities driving requirements analysis (IIBA).

Perhaps the advents of these governing bodies, massive PMOs, and never ending cumbersom processes some of us face within our IT organizations are a little bit like what mass media has done to the spreading of news. And this brings me to ask, what are you doing as a BA to keep your work personal and relative to your stakeholders and your organization?

Are you allowing your analysis activities to become bogged down with the feeling that you just have to put a check in a box? Or are you creating a coffee house of conversation that encourages differing opinions and offers the opportunity for the ah-ha moment of true innovation and inspiration where bright minds come together to solve the world’s (or your organization’s) problems?

Please don’t take this to mean that I am not in favor of the process that allow us to have consistency and standardization. Those qualities are very important. I simply challenge you to allow yourself to be free when doing requirements analysis. Take the time to develop quality relationships with your stakeholders (both business and IT (as “The Business Analyst’s ‘Other Customer’” on PracticalAnalyst.com so well stated)), and avoid being quick to judge. Proper solutions analysis will set the stage for solution optioning with divergent thoughts before you determine the best way to proceed and in the end you will add true value “That will have profound effects on (your organization).”

So here’s to you BAs – embrace your role, keep and open mind, be results oriented, and enjoy a cup of joe. Who know’s what inspiration you’ll find along the way.

I’ve been attending the IBM Impact conference this week at The Venetian / The Palazzo. One of the best sessions I attended was one on multi-channel retailing led by a gentleman from Infosys. The journey into a true multi-channel strategy is something I have been fortunate enough to work on in my current eCommerce role, but I hadn’t really taken any time to step back and think about it from the holistic enterprise perspective. Three things have come to since I have been here at Impact.

1. Organizations must embrace multi-channel strategies because consumers are forcing us to embrace that nature (it is projected that in 2 years mobile Internet queries will exceed that of desktop ones). As consumers become more sophisticated they will not tolerate inconsistent user experiences across the different channels (in-store, on the phone, from a mobile devise, and on a traditional desktop)

2. IT Leadership needs to start approaching the technology portfolio with an object-oriented mindset. We are leaving the age of legacy siloed applications where functionality is redundant and inconsistent across the enterprise. We must force the architects to create systems that are service enabled and leveraged across all aspects of the organization. Just as developers build object-oriented code with reusable components and DBAs build relational databases, we must craft reusable component driven systems that create operational efficiencies within an organization.

3. For organizations to succeed in this multi-channel world, leaders must invest in the business analysis competency and cultivate a culture that leverages the notion of Enterprise BAs that consult business and technology leaders on the company’s long term strategy and assist individual project teams with system integration and solution validation.

More to come? Most certainly…but for now, farewell!

This has been a year of learning. I’ve gone through several significant professional changes:

• Conversion to Agile: In January my entire department (all 200+ of us) decided to jump head-first into the Agile from the rather messy semi-interative/hybrid world we were in trying to managing nearly a dozen waterfall projects with moving parts and dependencies.
   
• Promotion to Manager: Now I’m officially leading a team a 20+ BAs
   
• Onboarding of New Leadership: Not only is there a new CIO of my company (from the business side of the company), but the Director of my department is brand new to the organization. Lots of cultural change.

The first of those has probably been the most interesting though. I’m passionate about Business Analysis, and I conceptual understood that documentation would be lean in Agile, but I never expected the phases of acceptance we have had to work through as the BA team for our department.

It’s Agile: We don’t Need BAs
As teams went through the training, a fantastic bootcamp with curriculum provided by DavisBase Consulting, many left with the impression BAs were an unnecessary part of the team structure. As a manager this immediately had me fighting fires. The majority of my team is made up of contractors and they all thought they were going to lose their jobs. I also knew the reactions of these individuals were wrong, so it was time to help our Agile Coaches and provide more context in order to get BAs back in the loop.

Less Than Adequate Involvement
After relatively short order we found that the BAs were being leveraged, but not for requirements elicitation, analysis, or validation – but as administrative assistants. Many were simply just writing note cards, rearranging the task boards, formatting excel documents. At least the Scrum Master’s were getting them engaged, but not in the right way. No matter how much the stronger BAs were fighting to do the right thing and I was trying to coach and mentor, we just wern’t getting any traction.

The Light Bulb Came On
It took a little longer than it probably would have, because much of the product backlogs for the teams were derived from existing requirements documentation written for Waterfall projects, but once the teams starting relying soley on the new user stories being produced by teams they had an ah-ha moment.

The teams were committing to complete stories, but once they got into the middle of the sprint and heavy into the coding they found all sorts of unanswered questions. As a result, the teams were failing to be “complete” on stories, velocity went down, and the everyone was getting frustrated. I wonder what was missing?

The BAs were getting engaged in the process, but they were trying to do all the requirements defined during the sprint where they were coding the functionality and they stories were simply not granular enough to fit within the 2-week periods. We were definitely making progress.

Getting Ahead
We aren’t there, nor am I overly confident any time in the next few sprints we will be, but the team is moving forward. The BAs are feeling engaged and the teams understand their value. We are just trying to adjust velocity and expectations in order to let the BAs get 1 – 2 sprints ahead and the team ensuring the backlogs are fully groomed and stories are ready for the team to develop against them.

The key strategy I am suggesting:

• Make Two Commitment Lists at the Beginning of a Sprint: The stories the team will code against, as well as the list of stories the team will complete “grooming” on.
  • Spread available velocity across both lists accordingly.
    • BA & UX team members will have most of their velocity allocated to the “grooming” tasks
    • Development & Testing team members will have most of their velocity allocated to the “coding” tasks
    • Both groups must reserve some of their velocity to ensure that all tasks are successfully complete, and at the end of the day, the “coding” tasks are more important because the completing stories for the demo is how you measure success. (This is why it is great for the BA to be at least 2 sprints ahead because of the “grooming” commitment isn’t kept – then the team isn’t left at a disadvantage in the next sprint because the majority of that analysis should already be done.)

As you can tell, there have clearly been some bumps in the road, but no matter how annoying those bumps may be I know that the adoption of agile is a step in the right direction and I’m thrilled to be getting this hands on experience leading a large complex organization through this conversion.

On Thursday, April 7, 2011. The CLT Business Analysis meetup group will be having it’s second book club Meetup event. Starting at 6:30 PM the group will enjoy light appetizers and networking before beginning a discussion on Dan Roam’s book “The Back of the Napkin.”

Thanks again to Roger from Sherpa LLC for providing copies of this book as door prizes for the Feb 10 event. Be sure to attend this event in order to be eligible to return home with copies of books for the next event.

Go to the Meetup site now to RSVP!