Skip to main content

Author: Deena Chadwick

Don’t Blame Agile for a Lack of Common Sense

I have heard many times that the Agile Manifesto was created because Waterfall processes were so intricate and complex that most projects failed. This is not true! While using Waterfall as a leading methodology projects were completed, software was launched, and teams were successful.

So why is Waterfall not the popular process today? I believe there are three reasons:

  1. Evolution of Information Sharing. The expansion of the information age allows for more collaboration and real-time sharing of information and updates.
  2. No Tolerance Attitude. Process was so predefined that no one was allowed to veer outside of the process. Roles were defined, requirements are unchangeable, and sign off was final.
  3. Lack of Good Old Fashioned Common Sense. Many developers were getting burned by the No Tolerance Attitude. They stopped using common sense to drive their actions and conversations. If a business rules document said that the name can only be four characters, then it was developed that way. When asked why the response was always “It was written in the requirements.”

So it was the development of Agile that introduced iterative development right? Wrong!  In the 1930s Walter Shewhart, a quality expert at Bell Labs, proposed a series of short “plan-do-study-act” (PDSA) cycles for quality improvement. The X-15 hypersonic jet in the 1950s was developed using Iterative and Incremental Development (IDD). Gerald M. Weinberg in an interview stated, “We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale, [at IBM’s Service Bureau Corporat].

So if IDD and PDSA were already known by leading experts in software and project development, then why was the Agile Manifesto written? Here is what happened, when 17 leading industry leaders gathered to discuss best practices they didn’t agree on much, but they all seemed to agree on four things. These four things were written up as a manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

These are not written as processes, steps, rules, or any other methodology. They are principles that should drive all projects no matter the methodology.

Related Article: Agile is a Team Sport

So why do so many people call Agile a process or methodology? After the manifesto had been circulated, it was very much agreed upon by many. It also seemed to align with several processes being employed in the 1980s and 1990s. A development process created in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka was a variant of the Japanese Sashimi methods. These methods focused on speed and flexibility. Later in the 1990 Ken Swaber and Jeff Sutherland employed similar methods and referred to them by the sport they mirrored. Rugby. Scrum is a rugby term that means restart a game after a problem. Unlike Agile, Scrum is a process. It is meant to allow teams to adapt quickly to problems, interruptions, and late breaking changes.

So if your team is using Agile Scrum, this means that:

  • You are thinking about common sense communication over processes.
  • You strive for working software rather than over documented requirements.
  • You value what your customer and users have to say rather than assume that you know more than they do
  • You flexibly change and adapt as needed

So how does someone meet scope and deadlines when not one of these principles seems to align with tracking and managing projects or people?

Here is where things start to get complicated. Projects need to deliver. Deadlines must be met. People are not perfect, so they need oversight and management. Stakeholders, investors, and managers sleep better at night when they know there is a plan; each person has a clear direction, and that things are being tracked and reported on regularly. So in 2001, Ken worked with Mike Beedle to bring decision-making authority, planning and managing project into Scrum. This was defined in the book Agile Software Development with Scrum.

So now we have come full circle more than ten years later Agile Scrum.

  1. Communication and Speed of Information Sharing. The expansion of the information age has provided us with amazing tools that allow instant information sharing, amazing wikis, and even collaborative documentation. However, information can only travel as fast as the person providing it. Information can only be ingested if someone is accessing it.
  2. No Tolerance Attitude. Process for Agile Scrum has become so predefined that no one is allowed to veer outside of the “agile” process. Examples: No sprint can be more or less than two weeks. Fibonacci Story Points only not estimates in hours. You can’t sit down at a Scrum meeting. Once velocity is determined a Sprint must have the exact number of story points for it to be deemed complete. The list goes on and on.
  3. Lack of Good Old Fashioned Common Sense.. Again common sense seems to sit in the background. Since there is a retrospective meeting, everyone waits to share their issues there instead sharing the issues when they come up. A developer could not possibly know how to develop a login screen from their vast experience and knowledge…they must wait for user stories. Don’t even think about working on something that is sitting in the backlog that has not been prioritized by a Product Owner…even if it will not affect your ability to deliver on time and not doing it will put your current tasks on hold.

At the end of the day, don’t blame your methodology for your project woes. Your team is not made up of children. They do not have to be told to open their mouths before they take a bite of food. The next retrospective where the methodology is blamed, go back to the task that failed and find out who was involved and why common sense was ignored. My team sometimes jokes about it but have a Sense of Personal Agency. A Sense of Personal Agency is the awareness that one is initiating, executing, and controlling one’s volitional actions and knowing how they affect others.  It is honestly the most important part of any Waterfall, Unified, Agile, Flexible, Adaptive, Lean, Scrum, IDD, TDD, Extreme Development or Task Oriented project. 

Business Analysts Need Multiple Personalities when Eliciting Requirements

Every experience business analyst knows that there is no substitute for well-defined requirements. Unfortunately they are not always given the support or license to perform a true assessment. Sometimes stakeholders and project managers treat requirements gathering synonymously with taking orders. Expecting the analyst to just passing them on in the form of documentation.

If you find yourself in this type of situation you need to channel two types of people:

1.  Inner 2 Year Old 

If you haven’t already guessed it the 2 year old is the one that pulls on your pant leg and asks the dreaded question…WHY? And then WHY? And then WHY? And then WHY? And then WHY again! Until you have said something that satisfies their curiosity or at the least something they finally understood. The BABOK defines this as a key technique: 5 whys of Root Cause Analysis.

2.  Inner Hunter-Gatherer

Hunter-gatherers were typically a society where almost all food is obtained from the wild. In order to truly obtain requirements, you will have to go get the information you need. The BABOK considers this one of their 5 knowledge areas: Elicitation. Elicitation is about interviews, prototypes, facilitated workshops, and even job shadowing. These techniques are meant to surface requirements that would not be provided if you simply gathered them. You also have to hunt for them.

The next time you are at the grocery store and you see someone picking through the fruits and vegetables looking for the just the right one or the little kid in the check out aisle asking why can’t he have a candy, don’t roll your eyes. Instead smile a secret smile, because you know exactly what they are going through!

Don’t forget to leave your comments below.

Lions and Tigers and Stakeholders…Oh My!

If you have ever joined a company or project as “The New BA,” then you know what it was like for Dorothy to follow the Yellow Brick Road.

Scene 1: Kansas
You have either changed companies or changed projects; either way, it usually starts with a maelstrom of new information and expectations (The Twister).

Scene 2: Munchkinland
When you first start on the project, you are usually surrounded by people (Muchkins) who keep telling you how glad they are that you came. Then there is the person you answer to (Glenda); she tells you that you are the person she has been waiting for, that you can fix all her problems. She happily introduces herself and then points you down the path (Yellow Brick Road).

Scene 3: Scarecrow’s Cornfield
As you are getting yourself acclimated with the new project and what is expected of you, you meet a Domain SME (Scarecrow), someone who has a lot of information, but does not have a lot of project or analysis expertise. He knows a lot, but doesn’t know what to do with it. This person can be your best friend, so keep him informed, ask questions, but remember he is not the brain behind the business analysis.

Scene 4: Tin Woodman’s Cottage
You start creating basic work products such as the approach and plan. You have your first few reviews with your stakeholders. At this point you meet someone who won’t budge on her ideas, who can’t seem to play nice with others, and has little or no ability to compromise (The Tin Man). This person can also be your best friend. Find out why she is being so rigid and unmoving, and then grease her wheels. Once you have her on board with your approach, you can use her axe to your advantage. Just remember, when it comes to negotiation and compromise, she usually doesn’t have a heart.

Scene 5: Cowardly Lion’s Wild Forest
You have finally gotten the majority of the stakeholders working toward the same goal and have a few work products that you want to show to the decision makers. At this point you will run into someone who jumps down your throat and tells you that your work is 100% ready for review, that your documents or work isn’t perfect, and that until it is you cannot possibly show it to anyone outside of the team (Cowardly Lion). If you can get past the growl, you will find out that this person is simply afraid that what is being presented will be rejected. Help him to find his backbone and to face his fears. This person probably holds the keys to the castle; remind him that he should be proud to be king.

Scene 6 & 7: Witch’s Castle & Wizard’s Chamber 
There is always a point in the project when you think everything is going as planned and you are moments away from achieving your goal. At this point, hidden risks and issues are finally revealed to you. Not because anyone wanted to admit them, but because you finally asked the right questions or pulled back the curtain (Wizard of Oz). This is not a time to get angry or discouraged. At this point the tables turn and those who you looked to for information and guidance now look to you for leadership. Make a plan and mitigate or eliminate the risks and issues (Wicked Witch of the West).

Scene 8: Balloon Ride Home
Now that the risks are all gone (ding-dong the witch is dead), the Cowardly Lion feels like a king, the Scarecrow feels like a genius, and the Tin Man has found his heart. It is time for you to click you heels together and move on to your next project.

Don’t forget to leave your comments below.