You won’t see warehouse managers programming or traffic controllers making user interface mockups. But in today’s world of software, thanks so the “agile” philosophy, the silos are being broken down. With agile development there is less need for lengthy requirements documents, because the barrier between business users and development is reduced. We are looking into ways we can create a more direct line of communication with our development team. Companies who adopt agile practices, by educating their business users on software development and bringing developers into the business process, save time in drafting documents and having development hit the target. They won’t need to be as detailed to have the same effect. The agile business analyst goes beyond software now and has more time to identify business process improvements.
TQS stands for Total Quality Systems. It’s more than just a name for us. It represents the processes of our business. Ideally encompassing every facet.
Agile falls in line with total quality management, which looks for problems with the business process. What is the agile philosophy? The Business Analyst’s Body of Knowledge puts it this way: “Agile is about having a flexible mindset, embodied in a set of values and principles and exhibited by a variety of complementary practices. Agile initiatives involve constant change.”
Those in software development are probably familiar with the agile perspective and those in management may be more familiar with a similar practice by the term lean. If your business is seeing deadlines consistently missed, why not adopt an approach that focuses on higher priority features and integrates the development team closer to the users. This allows the development team to understand the business process so well that they are actually able to anticipate changes and influence the business in more efficient directions. Business users will receive better support because the silos are broken down.
IT organizations and product developers co-create products and services with the business, rather than simply collecting feature specifications and throwing them back over the wall, as would happen under the waterfall development model.
This is why Agile development came into existence. That perfect requirements document is a pie in the sky. By beginning execution we can refine the business process to match the systems process. Do you remember when you first got a Facebook account? You probably went down a black hole of photos, messages, and emoji’s. But now every time Facebook introduces a feature you spend a couple minutes investigating and move on.
Every huge “waterfall" development project requires a lot of programming and testing, but also more staff training.
Four principals to adopt co-development of products (by agile standards) via McKinsey&Company:
- Adopt a product oriented organizational structure
- Improve interactions between the business and IT
- Redefine managerial roles and responsibilities
- Reconsider budgeting and planning models
For us, it’s more than just requesting development on our software. It is about the communication with our supply chain clients, being involved in their day-to-day problems, and then making our experienced recommendations. That’s quality. But total quality takes it even further. Total quality will then poke holes in these recommendations, it will challenge the requirements, and challenge our clients.
Not only does the objective allow for strong development, that makes sure requested features do what they are supposed to, but it pushes development to constantly be performing! Requirements seem like an ongoing list. Sometimes we simply refer to them as a "wish list.” We should really save these for our Amazon accounts.
It takes time to implement the system and even more time to train the users! Agile development keeps things manageable.