Welcome!

SOA & WOA Authors: Dana Gardner, Paige Leidig, Claus Rosendal, Adrian Bridgwater, Elizabeth White

Related Topics: SOA & WOA, Java, .NET, Linux, AJAX & REA, Web 2.0

SOA & WOA: Book Review

Book Review: Agile Product Owner Secrets

Valuable Proven Results for Agile Management Revealed

When the agile movement re-cast the roles of the SDLC they did so with small projects as the baseline of their experience. A typical minimal SDLC method includes subject matter experts (those who execute the current workflow activities), a Project Manager, a Business Analyst, a Software Architect, UX specialists, Developers, DBAs, and Testers. A Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. The typical SDLC method responsibilities for activities, and the skills needed to get them done, went from 8 roles down to 3. For small projects that is great, but as the industry is learning the hard way, for bigger projects it just doesn't cut it.

The product owner role received a lot of responsibilities. This means they also are expected to have a lot of skills. By no fault of their own, this is not usually the case. Along with the lack of skills, I also usually see them floundering for the authority needed to be effective. I do not understand why there are so many people that believe changing a person's job title will somehow magically give them the skills needed to do the job.

The activities needed to build software successfully didn't change when agile was explicitly introduced to software development. Agile has implicitly always been a goal of software development projects. The activities required to successfully build software were just moved around, redefined to give them a new context, renamed, and in some cases ignored. If the team adopting Scrum is dysfunctional, they remain as dysfunctional as they were before attempting to use Scrum. Their skills and experience didn't change by moving the team to a new method of managing the project.

The product owner was usually a project manager, subject matter expert, or business analyst in their previous non-agile life. This book does a great job of covering what a product owner is, what they are expected to know, and what they are supposed to accomplish. I have listed the chapters below to give you an idea of what is covered.

Breakthrough! Being Agile — The Product Owner as a Change Agent
Improved insight - The Point for Effective Communication
--Leading through conflict — the product owner as a mediator
--Leading Change and Winning Collaboration - A Mode!
Owning the business case
Unlocking usable user stores- solving business problems
--Interview
--Job Shadowing
--Brainstorming and Alternatives
Reliably working with the Team — Building Trust
Focusing on interfaces: development-Business
Understand the domain
Thinking Acceptance Criteria - When is the Project Over?
Scaling Agile — the product owner perspective
Scaling Agile — the bigger picture of life cycles
--Linear or Phased Approaches
----Waterfall
----V Model
--Incremental Development Approach
----Staged Delivery
--Iterative Approaches
----Spiral
----Rationale Unified Process
--Agile Approaches
----Rapid Application Development
----DSDM
----Extreme Programming
Perspective of the big picture- the basics of JIT, Lean Pull, Local Optimization in a MPRCS - Agile is not alone
Free Glimpse: Secrets of powerful teams - Revealing ideas of NLP and the use of words

I really like the way the author puts Scrum into perspective. He says 'Waterfall is a methodology, the principal approach of which is linear. Agile is an approach and Scrum is a method. Comparing agile and waterfall is like comparing apples and oranges in more than one aspect.

I have said before that there are way too many books, and way too much information available on agile these days. I'll be the first to admit, that every time I see an agile book coming out the first thing I think is how could they possibly still be milking agile. I also must admit, that many of the new books coming out on agile are now reflective of experience, and not based entirely on theory. That was what you used to find in the agile library, all theory and no experience.

Architecture, lifecycle phases, documentation, and specialized skill sets for certain roles throughout the process have made their way back into the agile world on projects that are larger than a 3 to 5 person team can handle. Thank goodness any good agile book you pick up today will either include these topics as absolutely essential, or you can throw it in the garbage.

I really liked seeing the author introduce Waterfall, V Model, Staged Delivery, Spiral, Rationale Unified Process, Rapid Application Development, DSDM, and Extreme Programming.

I found the advice in this book to be dead on for helping the product owner understand their role and then helping them succeed at filling it. The book is less than 125 pages, so it is a short read, full of practical and relevant advice, with absolutely no filler.

I highly recommend this book to all those moving towards an agile approach, but especially those moving towards an agile method that includes the product owner role.

Agile Product Owner Secrets: Valuable Proven Results for Agile Management Revealed

Agile Product Owner Secrets: Valuable Proven Results for Agile Management Revealed

More Stories By Tad Anderson

Tad Anderson has been doing Software Architecture for 18 years and Enterprise Architecture for the past few.