Resources

For many, the idea of offloading work onto others, especially people we don’t really know, is a difficult idea. The thought of entrusting a stranger with any part of our business seems like a disaster waiting to happen. But even the biggest and best find ways to delegate their workload, often to employees who may not have the motivation to get the job done well.

Often we are bogged down under deadlines, huge reports, and marketing pushes to really take a look at the bigger picture. We get used to the idea of working under pressure, and it’s common knowledge that stress and poor time management can lead to sometimes costly mistakes. Escaping from this mindset enables us to take a long view at how we delegate our tasks, and that actually, outsourcing is a vital tool to freeing us to concentrate on the core business.

Control

The older you get and the longer you work, the more you start to see recurrences of major events from your corporate past.  Centralize/decentralize.  Outsource/insource.  Distribute/consolidate.  Specialize/generalize.  Scott Adams of Dilbert fame helped us all to realize that this happens in companies everywhere.  In the corporate context, a pendulum swing is a metaphor for the dramatic swing from one strategy extreme to the other.  Some days I feel like I am in an eternal time loop, cursed to spend my days seeing the same pendulum swinging decisions repeat themselves over and over.  This, however, is a great opportunity for business architects to demonstrate value.  Business architects are in a prime position to spot these as they materialize, call them out, and help the organization moderate the effects of oscillating positions to ensure consistent progress toward strategic goals.  Here are three examples. 

The Product Backlog is the heart of defining any Agile solution.  The requirements that are identified in the Product Backlog drive the priorities that the Agile development team works on, they establish the scope of the delivered solution, and they ultimately determine the business value that the organization will receive from their Agile investment.  The challenge is that most Product Backlogs are based on input from selected stakeholders, rarely representing the full scope of requirements - and constraints - that need to be considered before priorities and business value can be accurately identified.

This is the first of two articles that provide you with techniques for maximizing the value of the requirements in your Product Backlog.  This article focuses on ensuring that you have considered the full scope of potential sources for identifying what the solution needs to deliver - and equally what it should notbe delivering.