I have scanned Crisp's blog (mostly Swedish) http://blog.crisp.se/page/1 and found it super interesting, it will be the next thing I read to get additional inspiration... :-)
The idea with the blog is to share experience about Agile in practice, I have been facilitating CoP (Community of Practice) with Scrum Masters, Product Owners, Team members etc. since 2010 with the purpose of sharing learnings from team to team...
“Learn from the mistakes of others-you can never live long enough to make them all yourself.” quote from John Luther
I have just read the articles at http://www.tuffledarskapstraning.se/bibliotek/ - all in Swedish - really good inspiration.
Makes me think of "When the best leader's work is done, the people say, 'We did it ourselves.'"
From http://blogs.hbr.org/goldsmith/2009/11/leadership_isnt_about_you.html I get the quote "Your team is more critical to the success of your project than you are." - which leads me back to Agile - "To succeed with Agile, Management's need for results must be greater than their need for control" quote from Israel Gat, formerly of BMC Software
And about engagement: http://www.youtube.com/watch?v=u6XAPnuFjJc&feature=player_detailpage
I was in a workshop with Tom Kealey yesterday - he is really fantastic at describing complicated things in a simple way!
His website have a lot of links (in the blog area) to his public presentations http://zerodegrees.nu/
I saw this link the other day: http://blog.crisp.se/2012/10/25/henrikkniberg/agile-product-ownership-in-a-nutshell
Another of Knibergs cool descriptions of the PO role and things that happens arround the PO.
A practical problem not described here, is that in some projects the customer and their wish is not know. If you have a customer who hired your company to do a specific thing, then the requirements will flow into the PO's backlog, but if you create something that you want to sell, i.e. a new program for some computer system (PC, mobile etc.) and you want to make this a fantastic product without telling the user about it first, then the requirements will not flow into the PO's backlog in the same way.
The PO need to have the vision about the product, but getting the flow and functionality right is difficult; there are probably several ways to get this right, but one logical way (when working with Agile) is the iterative way, discuss with the team and interaction designers and then do a test with potential customers to find out what works and what problems they see and repeat until you have something that you can launch.
What I often see is PO's who just hand out high level stories (sometimes called Epic stories) without driving the story description (including DoD) to a level where the team have enough information and do not secure that the customers are happy about the outcome.
https://dl.dropbox.com/u/1018963/Articles/SpotifyScaling.pdf If you want to get ideas, this is truely the document to read, I really enjoy reading documents like this, it gives me the energy to fight for what I believe in.
I really like the comments about Chapter and Guilds - it is creating CoP, and I really enjoy the description of how Sportify works with companies within companies etc. - I use to work in such a sub-company in Nokia where we was almost an isolated company within...
I can strongly recomend the book "Slack" by Tom Demarco, it is not about Agile, but it is a very good description of some of the practical problems that you as a manager have to deal with, I personally try to live and practice like he write, but it is not easy...
A couple of quotes from the book:
"People under time pressure don't think faster"
"Empowerment always implies transfer of control to the person empowered and out of the hands of the manager."
"Real quality has little to do with defects! Suggest that a real quality program should spend one-ninth or less of it's resources on the defect prevention and removal, and the rest on assuring product uniqueness, usefulness, market impact, change of customer work modes, etc."
"The efficiency-optimized organization recognizes quality as its enemy. That's why many corporate quality programs are really quality reduction programs in disguise..."
"..you can't grow if you can't change at all."
http://www.agilemodeling.com/ A really good place to get ideas, overview, book recomendation etc.
http://deanleffingwell.com/ I have worked with Dean at Nokia, he has some pretty good ideas about scaling Agile in big organisations
http://blog.crisp.se/author/henrikkniberg Henrik Kniberg have created a lot good documentation about Scrum, Kanban and how to get things working in practice, he is a legend in Sweden when talking about Scrum and Kanban.
https://dl.dropbox.com/u/1018963/Articles/HowSpotifyBuildsProducts.pdf a short (10p with pictures) description by Kniberg of how Sportify release, create pilot projects, A/B testing and tweaking products to they become even better.