Delivering Agile Projects within Structured Project, Process and Quality Management Frameworks

The most important factor in successful Agile adoption (and expansion) is aligning it to the culture, standards and constraints of your organization.  Even the most effective Agile project work risks losing executive support if it cannot meet the overarching management, compliance, administrative and reporting structures established by the organization.  Unless you are in the unique position of being able to adjust your organizational structures to suit the flexibility of Agile approaches, you will need to find a way for your team’s Agile work to comply with these corporate standards.  Thankfully, this is an achievable goal, although it may take some creative thinking to make it work within your specific organizational constraints.

 The “Kid in a Candy Store” Product Owner and the “See Saw” Product Owner

This is the second of two articles that address the specific challenges you may be facing in your work with Product Owners. The first article focused on two very different types of Product Owners: The “Big Picture Thinker” and the “Aspiring Developer”. In this article, the focus is on two types of Product Owners that appear to be different on the surface but who create surprisingly similar challenges for the Agile team: The “Kid in a Candy Store” Product Owner and the “See Saw” Product Owner.

The “Big Picture Thinker” and the “Aspiring Developer”

Every Agile team has experienced the frustration of working with a Product Owner who is very well intentioned but unable to provide the clear requirements that the team needs to build the most valuable business solution.

This is the first of two articles that address the specific challenges that you may be facing (or will most likely face) in your work with Product Owners. In this article, the focus is on two of the most common types of challenging Product Owners: The “Big Picture Thinker” and the “Aspiring Developer.”

The “Big Picture Thinker” Product Owner is an epic thinker, able to give the Agile team a high level description of their requirements but unable to describe (or to decide on) specific system behavior. Their inability to provide the team with adequate detail could be due to several factors, including their limited depth of knowledge and their fear of being responsible for decisions.

Anyone who has worked on waterfall projects knows the challenges:  The lack of communication between the business users and the developers; the predetermined (and immovable) requirements; the quality issues that are not evident until you are too close to the release date to safely address them; and the frustration of having to wait months (and sometimes years) before your efforts result in a live working solution.

When you make the move from waterfall to Agile projects, you have two choices:  You can choose to either block out your waterfall experience altogether (like any traumatic event!) or you can choose to leverage your experience to make yourself an even more effective Agile team member.  Here are three ways that you can use your waterfall experience to your advantage: 

10 proven approaches for transitioning from a traditional business analyst role to an Agile business analyst role (Part 2 of 2) The first 5 steps to becoming an Agile Business analyst were outlined in part 1 of this article. Now, part 2 of this article provides you with five more tips for becoming a successful Agile Business Analyst.

Step 6: Be an Expert Communicator

Everything about the Agile business analyst role depends upon effective communication with business users, development team members, management, and executives to understand their needs and to act as a liaison across all parties. You should be equally comfortable speaking with stakeholders at both a big picture level and at a very detailed level, depending on what the situation requires.