Categories
Rapid JAD Software Development

How to Take the Stress Out of Large Software Projects

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Momma singing me to sleep

I remember those ol’ days when I was stressed out about software projects. Not at all like momma singing me to sleep.

220 requirements, 14 design sessions, and 7 months into the project and my mind is jumbling bits and pieces together. The project manager asks me a question. I know some of the topic. I know this was discussed. Others made decisions.

Then I am thinking, why is anyone wondering about this? What is in scope or out of scope? Ah, we have a new project manager and this was a project manager number one discussion topic.

Thankfully I work on a team that implements the Rapid JAD principles:

  • Capture Now: If this was used, then we captured the topic and important decisions
  • Document Once: If this was used, then we have accurate notes stored in our document repository
  • Visible to All: If this was used, then everyone can find the information
  • Revise Quickly: If this was used, then the information is current

Finding that tidbit of information is a document repository search away…found. Ah, now I see an issue was created and logged in TFS…there it is.

Rapid JAD principles take the stress out of large software development project. They are as comforting as momma singing me to sleep.

Yes, I remember those ol’ days when I was stressed out.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Rapid JAD Requirements Uncategorized

Fllng n Th Blnks

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Fill In the Blank

By Erik Jul

If you read the title, you probably already have a sense of the topic: Filling In The Blanks.

How did you know that? In response to visual stimuli (the title), your brain did you a favor by filling in the missing letters (the vowels, in this case) in order to make sense of what you were seeing.

Take a minute to thank your brain…

…for making it easy to read an incomplete string of letters, form words, and make meaning. And for the billions of other times just today that your brain has taken much more complex and equally incomplete sensory data and rendered for you a version of the world that makes sense. Mostly.

At least, to it.

Neuro- and cognitive scientists refer to a principle of closure:

“The mind’s tendency to see complete figures or forms even if a picture is incomplete, partially hidden by other objects, or if part of the information needed to make a complete picture in our minds is missing”

Take another minute to thank your brain. It’s doing the best it can, and it certainly hopes that you appreciate it.

You see, the brain practically lives just to make sense of things, and it loves doing so in the most efficient way possible. Which often means using limited data to predict the reality that the data represent. In fact, as soon as the brain has a “good fit,” having matched sensory input against a memory bank of possibilities, it serves up it’s best offering.

Now, better take another minute to be concerned about what your brain is telling you.

And, if you are a business or requirements analyst, take a long minute to ponder the thousands of times you and others, in perfectly well-managed joint application development sessions, have thought that you understood the customer’s need based on your acceptance of the meaning that your brain provided based on limited information.

And if you are now taking a minute to wonder, “How can we decrease the chance that we are accepting in our requirements workshops as “true and complete” what our brain is providing based on incomplete information? I would completely understand.

And I would recommend practicing the Rapid JAD principles.

Now, scientifically approved.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Requirements Software Development

The End Goal – Removing Ambiguity in Requirements

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Clarity

When you are done reading this post the importance of knowing the end goal will have been communicated:

• Definition of Done
• Acceptance Criteria
• What does success look like?
• What happens?
• What gets completed?
• What is the result?
• The end goal

These bullets all represent one concept. As a systems developer, I want to know up front what is expected of the system when I am done developing what was requested. What am I to deliver?

I can read what a requirement states, but do I understand what is to be accomplished by the requirement? What is the purpose? The goal? The reason this requirement lives?

This is a critical piece that is often missed when requirements for system development are captured. Without this piece it is difficult to measure success. Let’s look at an example.

User Story
As a Customer I want to follow “issues” of interest as a priority so that I can focus on important issues as a priority.

This User Story is clearly written. I can read it. I understand all of the words. Yet, this is still vague. How should this be developed? What is result? What happens? It would be nice to have an answer to these questions from the person who wrote this User Story. Something such as the Acceptance Criteria, which when met, the person who wrote the User Story could say, “Hey it is working. It did what I was wanting.”

Something such as the following takes only a minute to capture, but adds a wealth of clarity to the User Story

Acceptance Criteria
I can hit a “button” and that issue automatically goes to the top of my view queue.

Without the clarity of the end goal, the Acceptance Criteria, development could go in any number of directions. By adding Acceptance Criteria, to User Stories or Requirements, the desire of the person who wrote the user story is clarified and it provides a measurement for the completeness or success of the delivered product.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Uncategorized

Aha!

Facebooktwittergoogle_plusredditpinterestlinkedinmail

gamma-brain-waves-300x208[1]

by Erik Jul

Is there room for a “Business Insight” in the profession of Business Analysis?

We are trained and practiced in the skill and art of analysis: Ishikawa diagrams, process flow diagrams, value-chain mapping, and a host of other techniques.

Used effectively, the tools and trade of a Business Analyst help to uncover problems and potential solutions, often methodically and with considerable, well, analysis.

Complementary approaches invoke imagination. Role-playing games, personas, brainstorming, mind mapping, and other creative activities can cultivate clarity and novelty.

And then there’s the “Aha!” moment, Newton’s apple or the displaced water in Archimede’s bath. Eureka!

Modern neuroscience, using electroencephalography (EEG), functional magnetic resonance imaging (fMRI), and well-structured experimentation can now document brain occurrences associated with insight including gamma wave bursts of 40 Hz.

Researchers and authors John Kounios, Ph.D., of Drexel University, and Mark Beeman, Ph.D., of Northwestern University, outline their findings in The Eureka Factor, Aha Moments, Creative Insight, and the Brain (New York: Random House, 2015), calling the gamma wave burst “the spark of insight” (p. 71). The gamma wave burst is associated with the linking of mental maps–the creation of new neuronal pathways–and seems to provide the energy necessary to both bind these new pathways and bring the associated insight to consciousness.

The implications, which I will explore in a future blog, are exciting. Can we encourage insight, and if so, how? Do analysis and insight affect each other? What’s a Business Analyst to do?

Meanwhile, think back on those times when, in a flash, an idea seemed clear, a solution suddenly appeared, and brilliance was yours if even for a moment.

These are your Aha! moments, and they might be the fastest way to revise quickly!

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Content Management

Increase Traffic to Your Website and Love the Results (7 principles you need to know)

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Search Rank Increasing

Do you want more visitors to your website? You can spend a lot time and money writing and creating content, but:

  • What good is a website which nobody sees?
  • What good is a website visited by school children when the people you want to attract are busy mothers?
  • What good is a website which does not enhance company objectives?

Writing with purpose is the trick to increasing organic search engine rankings.

High search rankings. More people visiting your website. These are things that will make you love writing.

Below are the seven basics you need to have down as you write content for your web page.

  1. Page Content

As content is written and created these three things should be kept in mind:

  • Target Audience
  • Purpose of the Content
  • Key Messages

If your company has not yet identified these three items, make this a high priority. Print these out and have them available as your write the content for your page.

  1. Search Strings

Identify two likely search strings that someone from your Target Audience will enter into a search engine when they are looking for the content on you are writing. This needs to be answered prior to writing/creating the final page copy. The answer to this section directs content for the rest of the page.

  1. Titles

Brainstorm by writing down your ideas, then mark the one you want to go with. This will allow you to look back a later time and see the ideas you had. The first part of the page Title displays in the browser tab. This helps a user who has multiple tabs open to identify the one they want.  Additionally, the title should contain words from the Search Strings you identified if not the entire string itself.

We recommend using a Headline Analyzer such as the one at CoSchedule,  http://coschedule.com/headline-analyzer

  1. Descriptions

Descriptions are often used as part of the search results page from a search engine. Description tells the user what is on the page and why they want to follow this search result link. Text in the description should contain words from the Search Strings you identified if not the entire string itself.

Description is placed in a meta tag on your page. You can see this on most web pages by looking at the page source and searching on “description.”

  1. Content

In addition to communicating to the Target Audience the Purpose of the Content and Key Messages, the content should also use words from the Search Strings as appropriate. Do not sacrifice good content by repeating words from the Search Strings, but where appropriate make use of those words rather than other synonyms. And of course you want content that is useful to your Target Audience. Content they want. Content they want to come back again to see. Content they want to Bookmark or add to their Favorites.

  1. Content Headings

As you write content for the page, content headings should contain words from the Search Strings if not the entire string itself. In Microsoft Word headings are available as a selection: Heading 1, Heading2, etc….

Typically, the main heading is the first thing you see in the page content area.  Sub-headings are topics related to the heading, breaking the heading into parts. Below is an example for protective dogs.

Protective Dogs for Your Family (Heading 1)

Doberman Pinscher (Heading 2)

The Doberman Pinscher, or Dobermann, or Doberman, is a medium-large breed of domestic dog of the mixed-breed category originally developed around 1890 by Karl Friedrich Louis Dobermann, a tax collector from Germany. Wikipedia

German Shephard (Heading 2)

The German Shepherd is a breed of medium to large-sized working dog that originated in Germany. The breed’s officially recognized name is German Shepherd Dog in the English language, sometimes abbreviated … Wikipedia

  1. Picture Alt Text

For each picture on your page describe in a sentence or two what the picture is about. Descriptive words that tie the picture to the page Content are needed and if you also make use of words in the Search String, that is a bonus.

Summary

Following these seven principles will increase your page ranking. If you are improving an old page, then be sure to capture the current search ranking. Then, 60 days after you have modified your page using the 7 principles above see how the ranking has changed. As more visitors are able to find your page you are sure to love the results.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Requirements

I Don’t Like to Write

Facebooktwittergoogle_plusredditpinterestlinkedinmail

DoNotWrite[1]

By Erik Jul

A colleague of mine once said, “I don’t like to write, but I love having written.”

And so, with a deft change of tense, the author had leaped over the pain of writing to the future perfect satisfaction of having written.

Some business leaders or software developers are like my friend and do not like to write functional requirements.

Do not like to write may mean:

  • Do not want to take the time
  • Do to want to spend the money
  • Do not think it is necessary
  • Do not know how to write a good functional requirement

Rarely would a business sponsor approve a project without requiring requirements. All too often, however, even with good intentions, the requirements produced look as though the author(s) did not like to write.

The requirements lack fundamental qualities of correctness, completeness, clarity, concision, and consensus (among others).

I don’t like to write, either, if poor requirements result.

My safeguard against poorly written requirements includes using the fundamental Rapid JAD principles:

When practiced routinely, these methods greatly assist my writing process and I produce better requirements. By capturing findings during Rapid JAD sessions, I am more likely to snare the essence of a discussion.  By documenting once, I create a single source of truth accessible to others, and by making these processes visible to all, I rapidly gain and confirm consensus.  Finally, by revising quickly, I am able to refine requirement statements as needed to ensure that they are in good order.

I might not like to write, too, if I did not use Rapid JAD techniques.

But as it is, with Rapid JAD, I love writing (requirements) and I love having written!

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Software Development

Tee Up! How Building Software is Like Playing Golf

Facebooktwittergoogle_plusredditpinterestlinkedinmail

Golf Course

The Course Layout

We have a course laid out and we are moving along the course. Not all courses are the same, but they have the same basic structure and flow as we play:

  • Tee off on hole 1
  • Move along the fairway
  • Hit onto the green
  • Sink the putt
  • Move on to the next hole and repeat

The golf course structure aids us by its layout and keeps us moving along in the proper direction doing things sequentially. Similarly software development methodologies have a structure which keeps development moving in the proper direction with a repeating sequence.

Playing the Par 4 Hole

For a par 4 hole, the plan prior to tee off is to drive onto the fairway. Put the second shot on the green. One putt for birdie.

However, things do not always go according to plan. We may hook or slice a shot, hit the rough, a sand trap, land in the water, and even a hit out of bounds is possible.

This is when the golf course structure pays off in that you can be moving along the fairway toward the green even though you are not necessarily in the fairway. There are rules to follow, you have the direction to head, and you know the goal.

Similarly as a golf course is broken into 18 holes, software development is broken into pieces, often referred to as an iteration. And while you have a plan at the start of each iteration things do not always go according to plan. However, with the structure of your chosen software  development methodology in place you know the direction to head, have rules to follow, and you know the goal of the iteration.

Summary

For many finishing with a 72 after 18 holes is the goal, but one which is not often reached. Still, you have a goal before the game starts and from experience you realize that many things can come up as you play.

Software development is similar, in that you can plan out everything you want to do for the entire 18 holes before you step up to tee off on hole one, but there are many things that happen along the way to finishing.

Understand that golf is like software development. It is likely not going to go as planned prior to tee off. Do not get shaken when you hit a sand trap or other obstacle. Pull the right club and play on.

With a good software development methodology in place you will recover when things do not go as planned. Expect things can happen up front and smile big when things go as planned!

Scramble anyone?

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Rapid JAD Requirements Uncategorized

Bundling

Facebooktwittergoogle_plusredditpinterestlinkedinmail

By Erik Jul

Bundling is a tidy idea.  Consider the humble bundle of sticks.

Bundle of Sticks

Useful.

Or the Roman fasces, shown here on the reverse of a U.S. Mercury dime, or Winged Liberty Head, dime.

Fasces

Powerful.

What makes each bundle desirable?

  • Utility
  • Fitness for a purpose
  • Ease of use
  • Similarity or complementarity of components, or
  • Some other bundle-making attribute that ties the individual pieces together

When selecting from a backlog of functional requirements, product owners and developers must select and form a bundle for the next development sprint.

This may seem like–or it may be–and easy job.  More often than not, however, it is fraught with decisions, trade-offs, and compromises.

What makes a good bundle?  Something must tie them together.

  • They implement a coherent feature.
  • They trace to user stories or epics.
  • They build upon a prior bundle.
  • They are required for a subsequent bundle.
  • They match the velocity of the development team.
  • They can be implemented in the current environment.
  • The account for any technical debt from previous bundles.

Of course, any bundle is only as good as its constituent requirements, which must be clear, correct, complete, consistent, unambiguous, verifiable, traceable, and testable.  Rapid JAD techniques greatly assist these objectives.

Creating the right requirement bundle is the basis for a successful development sprint, and a good bundle starts with a strategically stocked product backlog selected from a bank of user stories or epics.

Executing these challenging business analysis and project management tasks can prevent a bundle from becoming a bungle.

What’s in your bundle?

 

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Requirements

TV Dinner Requirements

Facebooktwittergoogle_plusredditpinterestlinkedinmail

TV Dinner Requirements

TV Dinner Requirement have the following characteristics

  • Conveniently pre-packaged
  • Tasty like cardboard
  • Surprising when there is something good inside

Already Packaged

TV Dinner Requirements come to you already packaged and ready to go. A business has hired an analyst to define their requirements and package them up in a document. The company then puts their TV Dinner Requirements out for other companies to bid for the work, sometimes called a Request For Proposal (RFP)

If you find yourself working with TV Dinner Requirements, then you are beyond the defining of requirements typical of Classic JAD and are on to the next phase:

  • Validation of requirements
  • High Level Design

Remove the Plastic and Heat

Pull off the plastic wrap and validate the requirements. They may have become stale sitting around in a frozen package as time goes past.  How old are these requirements? Have they become stale like cardboard? Are there any good requirements in the package? Can someone in the business tell you why the requirement is in the package? Often the reason something is in the package is unknown! For these reasons a good business analyst will validate the requirements in the package.

Things should heat up as you share the TV Dinner Requirements with business leaders and developers and put together high level designs as a proof of concept. Everyone will like talking about the good stuff they find inside as well as the bad stuff.

Keep in mind that TV Dinner Requirements can be fast and easy, not necessarily good.

Facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories
Document Management Rapid JAD

Getting It Right

Facebooktwittergoogle_plusredditpinterestlinkedinmail

by Erik Jul

When specifying requirements for a new system, large or small, how much do we have to get right?

Isn’t “All of it” the right answer?

Not always, and maybe never.

Concepts such as “minimally viable product” (which carries the moniker MVP as if it were some sort of champion), “iterative solution scoping,” and “progressive elaboration” decry the notion of completeness and possibly even that of correctness.

Of course, no one wants to deliver, or attempt to use, a system that does not work or is ill-suited to the task. So “getting it right” must matter to some degree: the system must work as specified.

But how much of what the user needs or wants has been identified and correctly specified in functional and other requirements? And of that, how much was correctly implemented?

Relying upon a Six Sigma approach (a methodology driving toward six standard deviations between the mean and the nearest specification limit) may reduce defects, but may still fall short of identifying a customer’s true problem and its best solution.

Lean, Lean Six Sigma, Agile, and the Three Amigos Scrum Alliance. These, plus approaches already forgotten or yet to be proposed, try to help us “get it right.”

In successive waves of innovation and reinvention, practitioners attempt to narrow the gap between what’s needed, what’s specified, what’s delivered, and what solves the customer’s problem.

Along that path, from problem to solution (scope, time, and cost notwithstanding), the professional solutions team—sponsor, business owner, project manager, business analyst, QA /tester, solution architect, developer, trainer, change management lead—all focus on “getting it right.”

Common software development and project management practices such as change requests, expectation management, phased releases, bug fixes, cumulative updates, and new versions testify that “getting it right” remains a noble goal seldom reached and maybe never reasonably expected.  For now, these are our best tools for getting it right, eventually.

To increase the likelihood of getting more right now rather than eventually, try these Rapid JAD principles: Capture Now, Document Once, Visible to All, and Revise Quickly.

Simple. Proven. Effective.

How much do you want to get right?

 

Facebooktwittergoogle_plusredditpinterestlinkedinmail