Some systems are a joy to use. Others create extreme frustration and waste valuable time. Why? What’s the difference? Well, let’s think about the characteristics of good and evil systems:
The “angels” of systems are:
- intuitive, easy to use
- reliable, always up and running
- error free (mostly)
- frequently down
- glitches kick you out and force you to login multiple times
- lock-up and cause you to restart your computer
- can’t easily customize your user experience
- poor help features
- not intuitive, hard to use, hard to find what you need
- processing time is slow
- doesn’t work on mobile devices
It’s not that the devils lack key features. In fact, the devil systems have great features we want to use, but we can’t access them. These frustrating systems waste our time. Our complaints trace back to missed or incorrect non-functional requirements (aka: quality of service requirements or supplementary requirements).
The challenge I will put out to you, ask your stakeholders and users what they don’t like about the system . . . they will likely tell you all about the things they don’t like and these are likely missed non-functional requirements. Our stakeholders, users and even ourselves take for granted and assume the non-functional aspects of systems.
I am often asked how to best go about a particular business analysis scenario; how to do a particular technique. Usually the person is asking more than just best practices, but looking for a short-cut or one-size-fits-all process to go about doing business analysis. I hate to break it to you…there is no such thing.
What I often find in the question is that the person is getting hung up on the process or technique and has lost sight of the ultimate goal…which should always be to add business value. So in attempt to answer the question for all business analysis scenarios and professionals, I will give you my personal operating goals when conducting business.
Remember business analysis is not just the IT Business Analyst or Business Systems Analyst that works on IT projects to deliver software solutions to the business. Whether you are an IT Business Analyst, Enterprise Architect, Process Improvement Analyst, Data Analyst or one of the other business analysis roles, you have to interact with and build relationships with stakeholders and your ultimate goal should be to deliver business value to those stakeholders. So these operating goals relate to you.
There is no one-size-fits-all way of doing business analysis
Dual-track scrum, or dual-track agile, is an approach to software development growing in popularity that assumes there are two key tracks for agile product development: Discovery and Delivery, as shown in the diagram below:
This approach has a lot of merit and can eliminate a lot of frustration and costs in agile development. Often, agile teams have long and frustrating sprint planning meetings because backlog items are not well defined, understood, or validated. This often results in slow velocity and extra development iterations because a basic understanding and design details are worked out during the sprint using code. The amount of waste and rework is very high because backlog items have not been defined and validated properly.