Accepting Failure

Catching up on some reading tonight during a pomodoro session. Yes, I built in reading e-mail, reading blogs, and writing blog posts into my backlog tonight. Ha. 

So, I just read When to give up by Stef Lewandowski (@stef) over at Makeshift. I suggest you read it yourself, but I thought I would use this as an opportunity to ramble about failure myself for a few moments.

My favorite points from the post were Listen to Yourself – The idea of paying attention to how you feel about something, how you sound when you talk about it, or how you react to it when someone brings you up. I can’t help but completely agree. We spend way too much time at work as a standard employee to be disgruntled with our work. And if you happen to be an entrepreneur, then the amount of devotion and effort put into running the business far exceeds that of a standard employee at a company. Don’t let yourself be unhappy or always stressed about your work. At the end of the day it just isn’t worth it and if it is meant to be – it will be. Don’t kill yourself over something that is simply not intended to happen.

The second of the points was Zombie Fails – I had never thought of it this way before. Stef references a point made by Makeshift co-founder Nick Marsh, “It’s not the mega-fails that you need to watch out for. It’s the zombie-fails. It’s the things that you do, that aren’t quite working, but are always showing a bit of potential. The things that always require of you to just do one bit more because that’s the thing that will make it go big. Except you do it, and it maybe improves a bit, but there’s another just one bit right around the corner.”

I liked this one, not as much from the entrepreneurship angle – although that is very important –  it really hit home for me when it came to projects we undertake at Davisbase (@davisbase) and projects my clients undertake. So think of them like the Zombie Projects – the ones you know you should really abandon and quit, but for whatever reason you just can’t seem to let go of because it just might turn out to be great, or it just might get back on track. They cause headache and swirl and make you have that awful stressed feeling all the time. If everyone in your office gets “that tone” in their voice when talking about a certain endeavor, then maying its not the right initiative to be working on.

And lastly, I complete agree with the idea of building failure into your plan. I have a tough time of convincing new agile teams to do it, or program managers to allow for it during portfolio planning – but you have to acknowledge (just as change in inevitable) failures will happen. So just roll with the punches and cut your losses when you need to. Not everything is a great idea, and maybe you need to get some cojones in order to man-up to say enough is enough.

May the power of failure be with you!

Continue Reading

“Breaking Analysts” at #SGLAS

If you didn’t make it to ScrumGathering Las Vegas (#SGLAS) by the Scrum Alliance last week, and as a result missed my “Breaking Analysts” presentation – never fear! I will be presenting a variation of it at Agile Alliance‘s Agile 2013 conference in Nashville, TN May 5-9, 2013. What, you aren’t going there either? Well… I guess a PDF of the slides will have to do you. Here is a brief description of the talk I gave:

Leslie J. Morse presenting "Breaking Analysts"

Breaking Analysts: A Real-World Tale of Converting a Traditional Business Analyst into a Lover of Scrum
Team members that can perform proper Business Analysis are key to Scrum teams building valuable products that truly meet customer needs. “Breaking Analysts” will lead you throughwhat your BAs are thinking when they first learn about Scrum and equip you with tactics & strategies for getting the light-bulb to come on and ultimately build a team of analysts that are willing and ready to go all-in.

And as always, a HUGE thank you and shout-out to Davisbase Consulting (@davisbase) for allowing me to have a career that provides for these sort of great opportunities!

Continue Reading

Business Analysis Glory

More than just “Business Analysts” do Business Analysis. To help illustrate that point I developed a presentation for the Charlotte User Experience group titled, “Business Analysis in All Its Glory: An Overview of Business Analysis & Tips for Transferrable BA Skills Everyone Could Apply to Their Projects” // Download PDF of ‘Business Analysis in All Its Glory’

It was presented at the July 23, 2012 MeetUp for the group. Apparently there were 56 people there. Before kicking off the group was nearly in 100% agreement that they did business analysis activities in some way, shape, or form during their day-to-day job. I thought, well…there goes my punchline. 🙂

Nevertheless I proceeded, even getting a few laughs. Four main areas were covered during the discussion:

  • What is Business Analysis?
  • The Traditional BA Role
  • 7 Things You Should Consider
  • Where to Learn More

The main take-aways came from within the “7 Things You Should Consider” section where I highlighted:

  1. Acceptance & Evaluation Criteria
  2. The ‘Kano’ Conversation
  3. Business Rules Analysis
  4. NonFunctional Requirements Analysis
  5. Functional Decomposition
  6. User Stories
  7. Use Cases

Of course it was hard for my “agile” hat not to be on, and on several occasions the conversation drifted towards the topic of Waterfall vs Agile – something the group is clearly interested in. Afterwards there were several conversations about applying Agile Practices & Principles to creative and user experience driven projects; a topic I am increasingly interested in due to my lack of hands on experience doing it well and my need to be able to convey the best practices to the Davisbase clientele on a daily basis. The good news, it sounds like sometime this fall, or perhaps early in 2013 I will return to give a talk on Agile, possibly even running it as a slimmed down version of the Introduction to Agile curriculum we offer the Davisbase clients.

For now, there is only the PDF version of the slides available. I have the best intentions of recording audio to support them, but I will be honest with you – that’s not very high on my backlog right now.

Have a good one!

Continue Reading

Push vs Pull Requirements

Today I read, “How digital will impact the next generation of in-store shopping.” It’s articles like this that make me miss working in #eCommerce and #Retail. Although I truly enjoy the #agile and #businessanalysis coaching & training I’m doing.

The blog referenced the change of marketing from “push” to “pull” tactics and it made me wonder…

Are BA’s conditioned to be in a “Push Requirements” mode or a “Pull Requirements” mode?

Push vs. Pull

Sadly, I tend to think that many BAs just do the job they are told, take requirements at face value and operate in a “Push” mentality where stakeholders spout out directives for the solutions they want. Even worse, the BAs just write it down and “push” it along to the development team before turning their back and moving onto the next project.

“Pulling” requirements is a lot harder. You have to push for the ‘Why’ and understand the true need of the business. What problem are they trying to solve? Even more importantly, what problem can you solve that they don’t even realize they have?!? Figure out that, and you’re a super-star! The “pulling” can’t stop there though. Requirements are not one-sided. The IT stakeholders are equally as important.

So, here are three tips for operating in a “Pull Requirements” mode.

  • Force Divergent Thinking: Pushing stakeholders, both business and IT, to look at the requirements from different angles and discuss options and variations then opens the door for a convergent conversation. While narrowing to a set of selected requirements and preferred solution you’ll uncover hidden priorities and objectives the stakeholders have and end with a more accurate set of requirements that meet the true business needs.
  • Write Requirements from the Customer’s PoV: The system shall this, the system shall that doesn’t really mean much. Whether you’re in a waterfall or agile project methodology, try out User Stories. They convey the requirements from the customers point of view and force you to identify the benefit for developing the feature the customer is requesting.
  • Create Requirements Visuals: Stakeholders rarely read lengthy requirements and you never want to create a situation where the way requirements are presented shut stakeholders down. When possible create visuals that represent the requirements. Its an ideal way to facilitate the conversation and collaboration needed in order to get to input and verification.

Happy “pulling.”

Continue Reading

Acknowledging the “Don’t Know”

TechRepublic posted an article today titled, “How to find out what you don’t know.” I’m a huge fan of not only looking inward to find out, but also during requirements analysis trying to categorize information in 1 of 4 ways…

  1. I Know I Know
  2. I Don’t Know I Know
  3. I Know I Don’t Know
  4. I Don’t Know I Don’t Know

I find lots of parallels between #leadership and #businessanalysis and think BAs should purposely set aside time to study leadership principles in order to better lead from within a project team as well as leverage leadership techniques to influence organizational change.

The Ever Looming: Don't Know

It can be a challenge to identify what we don’t know though. It takes time, and often time is not a luxury we have. Our personality is typical confident and we’re able to present information and facts clearly in a way our stakeholders understand, but I feel it – so I am sure you feel it to…that looming fear of what you don’t know. What is the area of the scope that I didn’t even know I should explore?

Three of the main points Patrick Gray (@patgrayjr) makes in the article are perfect for Business Analysis interpretation.

Look around
Take the time to get complete stakeholder coverage. Don’t take the easy way out by working with the stakeholders at hand. Get direct input from end users if you can and try to work with individuals from different roles at different levels at the organization independently. I mentioned that as BAs we often have dominate personalities, but some of our stakeholder can take over the room and you run the risk of ending up with “groupthink“. Put yourself in the project’s shoes…if you were doing an 360° evaluation of yourself who would you talk to? This complete representation will help identify things you didn’t know and hadn’t even begun to think about.

Know the business, buy the tech knowledge
Ok, “buy” might not be the best word but…Trust your architecture and development counterparts to know the technology, your a business analysis professional. Know the business first, know the technology second. In fact, know the business first, and know your technology stakeholders even better. Those personal relationships, contacts, and connections will be invaluable. When you walk in cadence with your customer and have open and honest relationships with your IT counterparts then they will trust you to represent them fairly and the business accurately. Don’t feel like you have to be able to answer all the technical questions. Determine what is “just enough” technical knowledge and kill-it with your business acumen.

Get outside insight
At periodic intervals get someone from outside the core project team to review the work. Just like when we try to edit our own papers we read in to the text words that aren’t really present, or skim over words that are technically spelled correctly but are the wring one for the sentence. 😉 The second set of eyes will assist in identifying gaps, inconsistencies, and clarity issues. That feedback is invaluable!

To conclude I guess I will say its OK to know there are things you don’t know. Its a fact of life, it will always happen. We’re incapable of knowing everything. So hopefully a few of these ideas interpreted from Patrick Gray via TechRepublic will open your eyes and take away any fear you have of the ever looming “Don’t Know.”

Continue Reading

#BAOT: 5 Things to Stop in 2012

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” (12/15/11) #BAOT translation to come.” So, here is the #BAOT version as promised.

Five Things to Avoid in 2012In 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!


Continue Reading

Elevator Pitch : Requirements Benefit

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: by @carminegallo

Elevator Pitch is to Business BenefitI’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!

Continue Reading

The Fortune Series

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. Fortune Poster

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.

Continue Reading

CLT BA August Event

What Would Google Do? by Jeff JarvisThe 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!


Continue Reading

Two Good Take-aways

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.

Continue Reading