What Does an ‘Agile’ Environment Really Mean?

Trond Frantzen, Managing Partner & Chief Business Requirements Expert | The PowerStart Group

A lot has been written about what an ‘agile’ project is and what it isn’t. It seems like you can put five people in a room, and you’ll get eight opinions.

One thing I’m sure of is that an ‘agile’ project or ‘agile’ environment is really a frame of mind, rather than a process. It’s a paradigm or mental model of how we can approach our work. It’s certainly not a methodology, although that is the common perception.

An agile business environment means … delivering business value as quickly as possible to the client, and then to foster continual improvement of that business value. “Delivering business value as quickly as possible” doesn’t just mean getting a project done; it means to deliver value in how we interact with our business partners, our customers, clients and suppliers … and how we are seen to do so. ‘Agile’ also means empowering teams to adapt working practices according to the needs of their individual business areas, and to eliminate any unnecessary bureaucracy from years gone by. 

This also means not doing anything you don’t have to do (but to make this decision you need to know why it was needed in the first place), and encouraging the team to think outside the box to minimize doing things in a certain way just because they have always been done that way.

To accomplish this, we have to recognize (a) that we are doing something that we may not need to do; and (b) what we’re doing is only being done that way because it has always been done that way. In other words, we have to be aware of the conflict, which is easier said than done. It’s an interesting conundrum. If we are not experts in the conventional approach, then how would we know if a different approach is better? What’s our benchmark? What do we compare to?

‘Agile’ doesn’t mean doing something differently just because we can do it differently. ‘Agile’ doesn’t mean doing less of the work, just to beat the clock. ‘Agile’ means knowing which best practices really are best rather than not. Remember also that there are lots and lots of so-called best practices heralded by maintainers of the status quo. Bear in mind that “best practices” have usually been around a long time for them to be declared as best practices by the community. And many of these “best practices” have long passed their best before dates.

Coaching on a ProjectAlso, ‘agile’ does not mean chaos in the business. It means finding the straightest road to the planned destination (i.e., the value the client is looking for), and then taking that road even when others think you should take a more conventional and safe route … often circuitous and full of old-school bureaucracy, which will always take a lot of time.

‘Agile’ also means learning new approaches, methods, and a new way of thinking; not just blindly sticking with methods that haven’t changed in years, without any indication things are getting better (doing the same thing over and over again, while expecting different results). It also means to not avoid doing what’s required (some of the administrative things) just because it seems faster that way. Times change. Methods change. But chaos is never welcome in the boardroom.

Granted, some individuals and organizations take this too literally (which is always a danger when we hear someone say, “the team is empowered to respond to change over following a plan”), which can lead to a challenged and chaotic environments because of lack of professional discipline. There’s more to a business than fast work; just like there’s more to a business than just revenue. If your team delivers value, then it’s a success.

Above all, if we want to foster an agile business environment, we must involve our team, our clients, and our suppliers; and involve them a lot.

Always recognize, as the first principle, that we serve our clients – whether clients are part of an internal group or are customers outside our organization.

Recognize also that our business environment is rapidly changing around us, whether we like it or not. How we work with our business partners (our staff, clients and suppliers) will change as our business partners come to understand their own needs even better. The issue for us is how to deal with those changes, since history tells us that change is good. This is what improvement is all about; so when a client (or a team member, or a supplier) wants to change how they interact with us or anyone else, it’s actually a move in the right direction.

In my opinion, ‘agile’ means being fast and responsive, focused on delivering value, but without chaos and risk.

Thomas Kuhn, in his book “The Structure of Scientific Revolutions” used the term “paradigm shift”. He argued that rival paradigms are incommensurable; that is, it is not possible to understand one paradigm through the conceptual framework and terminology of another rival paradigm. I certainly agree with that. Therefore, any ‘agile’ approach to work cannot be measured using the metrics applied to conventional approaches.

At the end of the day, our ability to respond to the needs of our business and workplace is far more important than mindlessly following the rigors of a book of rules and regulations, printed neatly and all fixed in a point in time. I’m not at all suggesting that old-school methodologies and approaches to work are not important. They are. But flexibility, responsiveness, value delivery, and direct interaction are the key to success.

The quality of the work we do is always directly related to our education, professional development, experience, and the quality of the methods we use and the thinking applied. And our willingness to go where others have not dared.

So, go forth and be agile. Use modern methods. Eschew old-school “best practices” that have passed their best before date. Be strong.

Trond Frantzen

Tagged with: , , , , ,

Awesome Discovery Sessions – It’s Not Magic

Trond FrantzenTrond Frantzen, Managing Partner & Chief Business Analyst | The PowerStart Group

I’ve been studying and teaching Business System Analysis for many years. I’ve delivered courses and seminars to over 35,000 professionals. I hope others have enjoyed them as much as I have.

At the end of the day, the only way you can “do” Business System Analysis is to actually get together with clients, users, subject-matter experts and ask them what it is they need for their system. Sounds straight-forward. But we all know it isn’t. If it was, everyone would be doing it, without it being a big deal, and our business system requirements would be a breeze. But it just ain’t so.

In my courses and seminars I spend a lot of time addressing how to go about doing the business requirements analysis. I demonstrate. We discuss. We deal with the theories and practices. We do more demonstration.

But the reality is, a classroom course or a seminar is not the real world. And we can never spend enough time on the foundations and principles … the “how do I do this” … of sitting down with clients, users and subject-matter experts.

Discovery_Sessions_cover_(Kindle)My best-selling book, “How to Run Awesome Discovery Sessions” is about the “how do I do this” of sitting down with clients, users and subject-matter experts, to figure out what they really want and need for their system.

If you haven’t read this book yet … It will put into context the nature of your questions, the environment you need, how long it takes, who should be involved, and the tools you need.

You’ll also learn how to do it quickly, without missing a thing.

You’ll really find out what “real agile” means – with the results, the specifications, the documentation; but without the chaos.

Join the others who made this my best-selling book. It’s available on Kindle, so it’s an easy digital read.

Trond FrantzenTrond Frantzen is Managing Partner & Chief Business Analyst with the PowerStart Group. He specializes in rapid business requirements analysis, team development, and “bail-in” on challenged projects. His best-selling book, “How to Run Awesome Discovery Sessions” should be standard reading for all business system analysts.

Tagged with: , , , , , , ,

The First Principle of Business Analysis

Trond FrantzenTrond Frantzen, Managing Partner & Chief Business Analyst | The PowerStart Group

PowerStart Precision ConsultingSeveral years ago, Gerald M. (Jerry) Weinberg coined what he called The Lump Law, which stated: “In order to understand anything, we shouldn’t try to understand everything all at once.” In other words, if we want to understand anything at all, we should learn about it in tiny, understandable chunks, and synthesize it chunk by chunk. It’s frustrating and self-defeating to try to understand everything all at once – to try to get the big picture right away – especially if the subject is complex or new. It only leads to information overload.

This same principle applies to all aspects of business analysis. That is, if we try to understand everything about the target business all at once (i.e., linking all the stuff that’s to be integrated in a business), we’ll suffer from serious brain sprain. And we certainly won’t get the full set of business requirements right the first time, because it will simply be too complex. This is usually what happens when we try to figure out the solution first and then try to extract the business requirements to fit that solution.

Accordingly, I have restructured Weinberg’s Lump Law into The First Principle of Analysis, because it is so fundamental to any type of business analysis:

“Partition the effort to minimize complexity.”

Here’s another way of thinking about this:

Break down the work required to produce the requirements of the business into small, non-redundant, manageable and understandable pieces.

When doing business analysis of any kind, you will need to apply this principle often. Partition the effort to minimize complexity.

Trond Frantzen photoTrond Frantzen is Managing Partner & Chief Business Analyst with the PowerStart Group. He specializes in rapid business requirements analysis, team development, and “bail-in” on challenged projects.. His best-selling book, “Requirements Analysis for Non-Technical Business Analysts: Business Requirements Elicitation” can be found on Amazon.

Tagged with: , , , , , ,

Customer Failure 101 – Or, How to Kill Your Business without Even Knowing It

Trond Frantzen, Managing Partner & Chief Business Analyst | The PowerStart Group

A fine lunch indeedA few days ago I made reservations for four of us to have a working lunch. It was a nice restaurant in a beautiful brand new building. I had been there before with Linda, and had liked it quite a bit.

When I arrived, I was seated immediately and a server (who was there faster than you could say “nice day”) immediately had a menu, asked if I would like a drink to start (all the while knowing there would be 3 others arriving) and, when I said “no, thank you” she asked the obligatory up-sell question of whether I’d like some “still water”. Since I had been there before (and enjoyed it) I knew where this would go. If you say “yes”, a lovely large bottle of water imported from Italy arrives, and an additional unannounced $5 shows up on your bill. Since I knew this, I declined this fine offer.

I fully expected to enjoy a wonderful, tasty lunch with my colleagues once they arrived. My anticipation heightened as I patiently waited.

A server came to my table and asked if there was anything she could get for me. I said, “no thanks, my colleagues should be here any minute”. I then told her that we would like to have separate bills.

She looked at me awkwardly, apparently not certain what to say, then finally announced, “We can’t do that. It makes our computer crash.”

For a moment I didn’t quite know what to think or say. Mmm … “We can’t do that. It makes our computer crash.” Finally, I said, “I think you’ve misunderstood your billing capabilities. Certainly you can do that.” She insisted it was impossible, and said she would find the manager.

A manager arrived promptly. She reiterated that multiple bills would be impossible. Once again, she told the tale of “it will crash our computers”. She insisted they’ve had their tech support team look at it many times, and a new system would cost $20,000 so it wasn’t in the works. I felt she was making their problem (which I really didn’t believe) into my problem. As a customer, I really didn’t want their problem, whatever it was.

This isn’t 1966. It’s 2016. We put humans on the moon decades ago. We put rovers on Mars. We’ve had a successful human genome project. There are 1.5 million apps available for smartphones. We’ve invented 3D printers; including those that have been used on the International Space Station to “print out” new tools emailed from Earth. And the “crash our computers” thing is simply nonsense. Do they really think most people today know so little about systems that they would buy that story? Really?

Obviously, this is just an old-school, antiquated system, or they bought one with functionality that was based on faulty requirements analysis. So, let’s look at this logically.

Many old-school POS systems are based on a “Table”, regardless of how many people sit at it. Most newer systems understand that you could have several (separate) orders at a table. They isolate bills by food/drink order, and attach that to a location (i.e., a “table”). Most pubs do this. That pretty well solves everything.

When you look around a restaurant, they have no trouble with separate bills for small or single parties. But that’s only true, for those technology laggards, for individual “Tables”. The problem here is how the payment question has been addressed (I’ll get to that in a moment); and the unusual finger-pointing exercise that goes on when something is missed while testing a system. In this case, I have to put the blame on the analysts and designers of the system. They dramatically failed in two areas.

The question, at business requirements analysis time, has to be: “For a single, specific TABLE [this is an Object], how many PAYMENTs might we receive?” This question is followed by “Might we receive no PAYMENT; a single PAYMENT; or many PAYMENTs?”  Each part of this question must be answered by the client in response to the business analyst. Each answer creates a scenario (“Under what circumstances would this be true?” is the follow-on question after each answer.) Any client who stipulates that only one payment is acceptable (such as the restaurant I visited), has signed off on their own business failure.

For the POS software this restaurant purchased, that question was certainly not asked properly; therefore, it limits the restaurant and probably costs them customers.

The other side of this coin arose when the POS software was first tested. The multiple-payments scenarios wasn’t found, so that tells me the functionality found during business requirements analysis was faulty at best. When the flaw is discovered (possible after several tech support visits), this can only lead to a client-IT faceoff where the software design team says, “You didn’t tell me you needed that …” and the client says, “You didn’t ask me.”

In other words, this restaurant got some crappy old-school software (which miraculously might still be selling well) that was based on the debilitating old concept of TABLEs rather than ORDERs with LOCATIONs.

Will I go back there? When I’m dealing with just one bill, I certainly will. The food is good. The restaurant is nice. But, for those business meetings when we need separate bills … absolutely not.

Tagged with: , , , , , , , ,