Month: October 2019

Agile, Shmagile – What’s so Great About the Agile Manifesto?

Agile, Shmagile – What’s so Great About the Agile Manifesto?

According to legend, 17 people went to Snowbird Ski Resort in Utah in February 2001, desiring to codify a document uniting their various methodologies. What they came up with was the Agile Manifesto.

Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

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

That is, while there is value in the items on the right, we value the items on the left more.

Agile Alliance

Three sentences and four bullet points upon which countless volumes have been written. Why is it that something so simple has become so transformative?

Clarifies Priorities

Let’s answer that question from the inside out. The first thing is those “bullet points,” or four “comparisons” have turned upside down the value system of previous problem-solving philosophies.

Previous to the methodologies which make up Agile, the focus was process and tool-centric. The problem is, it made people adjust to tools instead of having tools serving people. Agile puts people ahead of tools.

Next the Manifesto talks about how it is more importing to have things that work instead of comprehensive documentation. That is not to say that documentation is unimportant. Instead, the implication is to avoid documentation that looks so far ahead that the finished product doesn’t match. In other words, it is better to document what works than what you think will work. Don’t document yourself into a corner.

The third “comparison” is my favorite because it talks about finding out what is needed instead of reading a legal document. The contract would not exist without the customer, and most likely, the customer is not the legal department (unless it’s a law firm). Customer needs are seldom adequately documented through a contract. So, when meeting the need, look at the customer instead of the contract.

The final comparison is also often confused. Change is the plan in Agile. It is a recognition that things change midstream. And if the plan is set in stone before the work begins, the product may be inadequate before it is implemented.

Broader Picture

The opening statement, “…uncovering better ways … by doing it and helping others to do it” brings up some broader perspectives. The first is the value of experimentation and empirical analysis. Some of the things brought out may be addressed multiple ways. The goal is to find the best of many ways to solve the problem.

Once we find the best way, be willing to share the knowledge so that other projects benefit from what is learned. In other words, let the feedback influence the decisions. A decision is not final until it is. Or stated a bit more academically, each item in the plan becomes a hypothesis to be proven, again and again, until that item is delivered.

Impact

If you’ve followed my blogs, you’ll know that I love to explore things that appear to be simple, but the impact is profound. That is one of the reasons Agile is appealing to me. No matter how much I understand, there are always new lessons to learn, and ways to overcome problems.

And it’s not just for software since Snowbird in 2001. Here is an article by Matt Hilbert published on Red Gate Software. The article traces Agile principles to the manufacturing of WWII fighter jets and the beginning of the Skunk Works.

Role of Agile Analysis

Planning

There are multiple ways you can look at planning, and each may apply to each Horizon. Here are a few that have been applied over the years. I’m sure there are others.

Types of Planning
Agile Extension to the BABOK®  Guide – pg. 3

First, there’s Iterative Planning. Any discussion about Agile has to mention Iterations as part of its structure. And in planning, it’s no different. On a recurring basis, the Agile Business Analyst reviews, refines, and prioritizes the work based on the latest insights.

Then there’s Adaptive Planning. The very word “Agile” implies change or flexibility. Priorities change. Needs change. So we have to Adapt. Agile will continuously be looking at what is going to deliver the highest value and striving to work on that next.

Then there’s the combination of Both. In this type, Iterative and Adaptive planning are combined. Priorities are repeatedly set, based on the latest available information.

Prioritization

So, How do we know what is the Priority? How do we know what to Adapt? The answer is, “Feedback.”

To get feedback, the Agile Business Analyst forms communication between a lot of different folks within or external to the organization.

Sources of Feedback
Agile Extension to the BABOK®  Guide – pg. 3

Identify the customer. Most often, of course, this is the primary individual or group who needs to be consulted. They may be internal – associated with some support process within the organization. Or External, classically represented in retail as the buyer of a product. It may be a group too broad to handle, especially for retail. This is often performed by a lead person or a group that serves as the voice of the customer.

The Analyst may observe or get information from sources, some of which might not be included in the organization chart, such as Competitors. These may be hostile witnesses, as they don’t want to give up a competitive advantage. But there are ways to know what a competitor is doing. In retail, all you have to do is walk into their store. Or maybe read their Advertisements. 

Partners are groups that, for one reason or another, are on your side. Because they deal with things that your organization may not directly see, they can be a great source of information that can inform some of your initiatives.

Investors are often self-appointed experts. They can be for you, or they can turn against you. Managing their expectations in specific environments can be the difference between the success and failure of the initiatives.

Subject Matter Experts are your internal sources. These should know the issues better than anyone. It is essential to see them embracing the changes, as often they are the customer. Other times, they are responsible for some of the technical requirements necessary for success.

Regulators, or the legal environment, is often the motivation for change. They may force an artificial priority. For example, if the IRS comes up with some new regulations concerning one of your company’s business practices, it becomes crucial to meet those demands. Your Board does not want the embarrassment of an IRS adverse finding.

Agile Analyst Activities

So, looking at a High level, how can you group the functions that an Agile Business Analyst performs?

Activities Enabled by Agile Business Analysis
Agile Extension to the BABOK®  Guide – pg. 4
  • Linking of Strategy to Initiatives to Resources
  • Elicitation – discovering, communicating (two-way), and interpreting the findings.
  • Clarifying – ensuring that the understanding of the Analyst is correct. Communicating who this is for, who this is by, and determining impact.
  • Helps Decide – priority of initiatives, features, and development work Items. Also, help decide approaches and providing information on trade-offs from one path to another.

This page may contain affiliate links. I may receive commissions for purchases made through links on this page.

What is Agile Analysis?

Agile Business Analysis begins with a basic concept of the simple feedback loop shown here. No matter what flavor of Agile you are using, everything you do in Agile can be boiled down to an application of this feedback loop.

Inspecting and Adapting

Feedback Loop
Agile Extension to the BABOK®  Guide – pg. 3

In Agile, you are either inspecting or adapting. Either you are gathering information based on data, interviews, research, or other sources, or you are taking the information and determining what to do about it. This simple feedback loop is applied to all levels of planning in the organization.

Planning Horizons

When we talk about levels of planning – that is what the Agile Extension® calls a Horizon. IIBA breaks it down into 3 Horizons

Three Planning Horizons
Agile Extension to the BABOK®  Guide – pg. 3
  • Strategy – Looking long-range to determine opportunities and risks and come up with potential needs or opportunities.
  • Initiative – Reviewing the opportunities and needs identified by Strategy, and determining a broad approach to meet that challenge
  • Delivery – Actually performing the work defined in the Initiative horizon.

Commonalities

Each Agile framework has certain things in common.

Commonalities of All Agile Frameworks

There is a heavy emphasis on incremental delivery.  In this case, I don’t just mean the final product from the Delivery Horizon, but incremental delivery of whatever outputs are appropriate for each of the horizons.  Whether that is potential initiatives at the Strategy Horizon, Product Plans for the Initiative Horizon, or Working Software at the Delivery Horizon, all of them are delivering something.  And they do this in recurring periods – at a cadence.

All Agile approaches prioritize effort based on value. They may disagree on who and how value is determined, but whatever the value proposition is, that is the basis for prioritized work. For example, a manufacturer might view value as Quality Control. Another might see it as Time to Delivery. A third might view it as Revenue. And there can be a debate on which of those is right. But whatever comes out must be meeting an agreed-upon priority.

All employ an iterative approach. So what is produced in each iteration?  The answer is just a little more than you had the previous iteration.  All flavors of Agile deal with Small Slices of the solution.  And they all have the idea that at the end of each iteration, that work is ready to go.

All agile frameworks promote rapid delivery. In Agile, there’s no more of this waiting until the entire thing is finished and testing it then, finding errors at the end, and having to rebuild large sections. You build a small chunk, check it, and roll it out. And it works when it is built.

It has been tested and approved, which allows rapid feedback.  If it isn’t accepted, you find out almost immediately, before building more on top of something that doesn’t work.

And again, adapting to change.  This goes back to iterative and adaptive planning.  All flavors of Agile have some form of this built into them.

Agile Analysis understands the value of feedback because of its effect on several important aspects of work.

  • Feedback guides the discussion of value. There are many ways that value can be determined. The first thing we need to know as an Agile Analyst is what determines value in the context of your work, company, and customers.
  • Feedback guides Prioritization.  I include this as a separate item because the value equation may change over time. The only way the Analyst will know is from feedback about the change.
  • Feedback informs about Opportunities. But even then, having the information is one thing. Knowing what to do with it is something else.
  • Change is revealed through feedback. It’s important to understand that the change might be because of data. Often when we think of feedback, we are meaning Human Interactions. But often, it’s not people that tell us of the need for change; it is data or other information.
  • Feedback minimizes Uncertainty and Waste.  If we build a means to monitor and tie results to possible responses into all of our business processes, including our development cycles, our time to perform corrections will be lessened.

This page may contain affiliate links. I may receive commissions for purchases made through links on this page.

Agile in Everyday Life

Agile in Everyday Life

December 2018 – Brooklyn Bridge – Chaos Personified

I am one of those people who seem to have a curiosity about everything. Frankly, it drives family members crazy since they perceive my need to know as a need to be always right. For the record, it is merely a need to know and is really an admission that I do not know, combined with a determination to find out. (And I would know better than anybody, right?)

One of the aspects of Business Analysis that I have always enjoyed is that it is the perfect outlet for people who have a great desire to know something about everything. Curiosity might have killed many cats, but it makes for great Business Analysis.

But being a curious person, I wonder what happens when the skills learned in practicing Business Analysis are applied to your everyday home life. It is one thing when dealing with professionals trained in various project methodologies and instructed to optimize output. Is it different with family members?

For example, what would happen if you institute some Scrum ceremonies? In a lessons-learned session for your family’s 3-week sprint, your wife mentioned how your daughter did not straighten her room. I can hear the screams – “Why are you bringing that up again from 2 weeks ago?” It might make for great entertainment if your family was on a sit-com, but not exactly the peaceful family we all wish to promote.

Another example, do we have a “Definition of done” for everyday chores? And for verification, do we have a period of User Acceptance Testing? How would you perform UAT for a task like the dishes? Does your spouse serve in a tester role to ensure dish cleaning problems are identified as early as possible and avoid that 10x cost to fix it later? Can you put the dishes away without going through UAT? If I were acting on my BA training, I would hope not because we must know they are cleaned before the plates go into production.

So is this really as efficient as we think it is?

As much as I love optimizations of project work, I think the brief list above would suggest (though obviously, I have not done an empirical study) that certain things in life are best handled without the constraints of any currently conceived project methodology. Certain things simply are not projects and treating them as if they were can be disastrous.

But that raises an interesting question. Regardless of which methodology, how do we know when some kind of project methodology should be applied? Ignoring the debates of Lean vs. Scrum vs. Waterfall vs. whatever, should project methodologies be used when we attempt to do X?

PMI has an answer for that. Their answer comes from the definition of a project. If it has a defined beginning (you know when it started), ending (you know what has to have happened before you stop), and a unique goal (the purpose you wish to achieve), then it is a project. They would categorize everything else as operations, meaning the rules of Project Management do not apply.

So, what does apply? I mean, many things fall outside of that definition. These may be ongoing processes, which do not fit so neatly as a project. It may not be so unique, such as laundry or dishes. That’s a shortcoming of this definition if you are using it to define what needs to be optimized. It leaves out a lot.

IIBA has a different view that includes pre-project and post-project activities. These may consist of some of the analysis performed that resulted in the initiative in the first place. They also include actions to monitor and control the ongoing operations of the delivered product.

Still, the examples listed above would make it seem that although IIBA would include “operational” activities in its analysis process, they do not really address the actual operations themselves – just the analysis of the operations.

So again, what applies?

I am sure other organizations weigh in on this in one way or another along a broad continuum. But none seem to really provide an answer. And frankly, I do not pretend to be that wise myself.

As I have been thinking of this question, “Is there a way to apply what we do professionally to at least some of our home lives? What does it look like if we do?” I have also toyed with subtly introducing some of the concepts at home. To see if there’s a way they could help.

Here’s a recent example of one interaction while exploring this.

Recently I was talking with my wife about all the schedule changes around her and the frustration that creates. While we were talking, I was reminded of all of the articles I have written about different SDLCs and how the ability to adapt to change is one of the factors that brought some of these methodologies into existence.

However, in my wife’s case, the problem was not that change was prohibited. The problem was that change was out of control. She needed to find a balance between working with schools, family, a sick child, a husband’s new job schedule, soccer coaches, and our church’s small group. Each item from that list was both demanding her time and expecting her to be flexible. Any of these changes created a cascade effect on her plans for the day, and sometimes her entire week. Also, much of this conflicted with her own personal vision for our family, which was getting squeezed out.

If we were in a Waterfall project, we would invoke the scope clause of a Project Charter. All these externals are out of scope. That was easy. Well, maybe not so easy in real life.

If we were using one of the flavors of Agile, we would talk about the team being able to self-govern. All these externals are the proverbial “Chickens” in that much overused (and lame) “Ham and Eggs” story. And since the Chickens are not totally committed to the project, their voice doesn’t matter. If you don’t know the story, I’ll spare you this time. Again, it’s not that easy because…

What happens when one of the team members, your daughter, is playing soccer (weather permitting) but also is recovering from an illness? What happens when the coach adds multiple practices with no advance notice. OK, sick kid, no warning, that gets canceled. But still, there is stress involved from both the child and the coach? What happens when your sister is in the area and you haven’t seen her in years? Or your mom is sick, so you have to reschedule that visit with both her and your sister? Or when your husband transitions to a better job providing for the family, but it has a longer commute? Or when the host for your church group is away and needs this week’s meeting to relocate? And your husband’s professional organization wants his time to develop some training when he is needed at home?

And then all of that is occurring at the same time?

What if the care that you have for all of these externals causes a multi-dimensional tug of war where you – not the project but you – are in the center, standing on the only dry spot and surrounded by a muddy pit? If you hold your ground, they all pull you apart. If you give in to one side, and you are drug through the mud while pulling you apart.

In that kind of environment, I think we need a new methodology. And I’ll call this methodology – Moms.

The problem with my promoting this new methodology is I don’t know how it works. But it does. And I have a lot to learn from it. I’m sure there’s an element of chaos theory involved.

Plus, it drives me nuts that I can’t figure it out. Because I have a curiosity about everything. And like I said, I don’t know it all.