Posted on

Agile versus Waterfall, Business Analysis and Project Management …?

Our clients regularly ask us about Agile versus Waterfall, Agile versus Business Analysis, or Agile versus Project Management.  Our answers come from our perspective that system development and the management of it have a different life cycle, each with several variations, that are combined into a specific approach, e.g., for a particular project.

Agile versus Waterfall

Our view is that whenever systems are developed, or parts of systems, the System Development Life Cycle (SDLC) is relevant.  Basically, the SDLC lays out the various activities that result in a system, e.g., Analysis, Design, Code, Test.  Agile delivers (small) pieces of a system frequently (say, once every two weeks), and thus traverses various SDLC activities repeatedly, i.e., in each Sprint.  Waterfall delivers the system in one go (“big bang”), and traverses SDLC activities one time through, one after the other. 

Our version of the SDLC is depicted below:

In our perspective, we don’t see Agile versus Waterfall.  Agile and Waterfall are similar in that they traverse the same SDLC activities.  In our view, Agile and Waterfall differ in their frequency of delivery, and thus how often they traverse the SDLC.  In certain situations, Waterfall may be more relevant; in others, Agile.

Agile versus Business Analysis

In Agile, say Scrum, the attention is focused on the Sprint.  The functionality that is to be delivered is typically brought into the Sprint as stories by way of Sprint Planning or Backlog Grooming.  Sprint Planning and Backlog Grooming start with stories that are (almost) ready to be worked on by the development team.  Stories are, in effect, specifications for the functionality that is to be developed.  The specifications should be based on Requirements.  Requirements and specifications should be developed using Business Analysis.

In our perspective, we don’t see Agile versus Business Analysis.  Agile is one approach to system development, which requires Business Analysis to take into account Requirements and to come up with good specifications for the functionality to be developed.  However, Business Analysis takes place before the Sprint.  Consequently, Business Analysis is generally not part of the Sprint, and Business Analysts are generally not part of the Sprint team.  But, they are needed.  So, in our perspective, it is Agile and Business Analysis.

Agile versus Project Management

With Agile, it is often not clear at the outset which exact functionalities will be delivered eventually, because requirements may shift over time, as users get more experience with the system.  Therefore, it is not clear how long such functionalities would take to deliver.  Consequently, it is argued that Project Management, with its focus on Scope, Schedule and Budget, is not relevant for Agile, i.e., Agile versus Project Management.

But, system development, when done with Agile or otherwise, still needs to be managed.  Decisions about what kinds of functionalities should be delivered, and when, must be made, along with how many people to have on the team(s), how much money to allocate, and what risks should (not) be taken.  Our view is depicted below:

In Agile environments, such decisions are made by the development team and the Product Manager (in Sprint Planning and Backlog Grooming). Scrum is often the approach that is used to manage each Sprint.  Sprint Planning and Backlog Grooming generally implements decisions, types of systems needed or business strategy, that are made by executives above the development team and Product Manager. So, in our perspective, it is Agile and Project Management.

Posted on

The Case for Vulnerability in Scrum Retrospectives


“Vulnerability is not weakness.”

— Brené Brown

Choose A Brave Willingness to Be ‘All In’

For a scrum team to be successful, it is important to learn of and solve problems as they occur. As we work together, we express how we’re doing, what’s in our way, and our concerns so they can be addressed. It’s an ongoing process of improvement from sprint to sprint. A retrospective session is most effective when everyone on the team is forthcoming about what went well, and also what didn’t. At this meeting, each team member should take time to quietly reflect and answer those two questions as it pertains to him or her. There are as many team dynamics as there are teams, so sometimes getting started is awkward if people feel uncomfortable opening up. Sustained success demands a brave willingness to be ‘All-In.’

To be ‘All In’ during a sprint retrospective, often we must dare greatly. I believe Brené Brown’s book, Daring Greatly,  has meaningful implications for Scrum culture in the workplace. Brown writes about interviews she conducted on how people experience shame in their lives. These were the subjects’ answers that, as a Scrum Coach, I found alarming: “Revealing any weakness is shaming…Showing fear is shameful…You can’t be afraid—no matter what.” This is bad news for those of us who seek success through an agile approach to getting work done. If the team culture views weakness as shaming, then that means team members may tend to cover up weaknesses. If during a retrospective we perceive that we can’t talk about the things that trouble us, because of the fear of being viewed as weak or not having the “right stuff,” then how in the world are we going to achieve substantial and sustained business performance improvements, improvements that deliver greater value? 

Brené Brown is a popular author, public speaker, and research professor at the University of Houston. She has written four number-one New York Times bestsellers. Her Ted Talk “The Power of Vulnerability” has received nearly 36 million views to date. The core of her research is this: People who live happy, wholehearted lives are those who have the courage to let their most authentic selves be seen. They are not paralyzed by a fear of failure. Rather, they have the courage to be vulnerable. For most folks, however, vulnerability is something we avoid at all costs because of the fear that if we allow ourselves to be truly seen, we will experience loss of respect, loss of connection, and shame. According to Brown, “Shame–the intensely painful feeling or experience of believing that we are flawed and therefore unworthy of love and belonging–breeds fear.”

Brown’s work would suggest why we’re sometimes reluctant to reveal to the team important ground truths about what happened in the sprint, because we don’t want anyone to know we’re weak in that area—and also a little fearful of being embarrassed by our weakness or appearing foolish before others. But unless we embrace the need for discussing it, without any guarantee of comfort, then the team productivity isn’t likely to systematically improve. I’m not talking about some coerced Kumbaya retrospective moment. I’m just encouraging a little healthy introspection,  to look back on the sprint and sift through our memories in order to more clearly see the business consequences of our relationships, challenges, frustrations, and feelings that we are experiencing. That might also occasionally lead to grabbing a Scrum Coach as an objective third party for guidance.

Choose Excruciating Vulnerability

That’s not to say that everyone participating in a Scrum team is afraid of vulnerability. As a coach, I’ve observed great progress in improved productivity when even one team member chooses excruciating vulnerability and with courage openly talks with their team about their own mishaps as well as near misses in hopes of making it a learning experience for all. This behavior tends to happen when that team member acts with a courage born of a sense of their own worthiness, and a sense of professionalism. And once one opens up with courage, others if not all are more likely to follow by speaking up. The absence of shame is the key to reporting the ground truth.

We could make our work more joyful if we’re only willing to do two things. First, we have to stop playing Monday morning quarterback when we hear about the sticky situations into which other team members have gotten themselves. Yes, there is a place for objective mishap/near-miss analysis, but criticism merely for the sake of making ourselves feel better than the other guy benefits no one. The second thing we can do is share our stories, and be candid and forthcoming about our weaknesses and fears. Transparency will go a long way toward everyone’s goal of higher business performance. In the words of Brown, “Vulnerability—the willingness to be ‘all in’ even when you know it can mean failing and hurting—is brave…Courage is contagious. Every time we choose courage, we make everyone around us a little better.”