Part of the Process

I've had this book on preview as each chapter came out and I've finally had a chance to read the full release version. So before it gets officially launch at MTPCon on June 13th here is my round-up... Formats : Paperback, DAISY, ePub, Mobi, PDF Where can I get it?  From  O'Reilly , Amazon or .... any good bookshop, although I think there are currently only 500 physical copies left world wide!     Who is it for?  Anyone involved in a software product development team or a startup founder thinking about which roles to hire next.  What's it about?  Product management, product leadership, not just the overlap but also the differences. How to grow your career as you grow into product leadership and how to hire the role for senior management. What's the book like?  The book is divided into three sections: The Product Leader The Right Leader for the Right Time Working with Customers, Agencies, Partners, and External Stakeholders The ...

BOOK REVIEW: Fifty quick ideas to improve your user stories by Gojko Adzic and David Evans It has taken a while since my last book review to get the time to do much reading with moving. But here is my round up of "Fifty quick ideas to improve your user stories" by Gojko Adzic and David Evans Formats : Paperback, ePub, Mobi, PDF Where can I get it? From Leanpub , Amazon or any good bookshop.   Who is it for? Anyone involved in a software development project working in an iterative manner. As long as they understand some of the basics around user stories, e.g. they know what INVEST stands for. What's it about? As the title suggests "how to improve user stories", but it is a bit more than that. It covers the whole process including planning and iterative delivery activities. What's the book like? Each double page spread follows a similar style starting with an introduction to a new tip. Often illustrated with an anecdote fro...

The wrong kind of roadmap... This post was inspired by a chance conversation from a developer, from another Brighton based software product firm. This occurred during The Lean Event . The conversation started during an audience participation section of Jared Spool's talk . I told him about trying to organise around themes and in exchange He told me about a lack of connection without that. This pleased me as it meant I was on the right track, but also reminded me not everyone has it sorted ( even if you think they do from the outside ). Unknown to me at the time I was sat at the table with Roman Pilcher! (more on him later) In the past three years there have been three big influences on the way that I look at roadmaps. Well that and software development, they are (in chronological order): Gojko Adzic introduced me to Impact Mapping at one of the first Product Owner Survival Camps.  First we learned about the importance of goals. Then being able to measure the impac...

Stories & Storytelling_1956 by Sterling College (flickr) In a lot of software projects the tools - such as prioritisation, backlog grooming, MVP - and artefacts that they produce - such as  job stories, roadmaps, personas -  are useful but ultimately I believe that they are about allowing a community of people to tell a story.  When "going up" to people at budget sign off level they are generally short of time, so the stories need to be the point and tightly foccused on giving a sense of what has happened and what will happened, including topics such as: What are you doing?  Which business goal does this achieve?  What is the value? (e.g. either cost saving/revenue protection or increase in revenue) In my experience  when going into detail level with implementers  they like to hear the answers to these questions:  Why is it needed?  How does this fit into bigger picture? and What will we be doing next? I have tried exp...

If I told you that I had worked on a successful product over the past 10 years - going from development and implementation of features to now being responsible for specifying on how parts of the product should function -  then it should not be surprising that during that time period I have revisited features to either renew the interface or back end processing. Here are a couple of areas where I have found that you need to be extra vigilant. Be in the present  Although you have knowledge about the original use case, be careful to remember not to fight the battles of the past - take note of current context or to solve the problems of the past - the world is (probably) a different place now You ain't gonna need it yet (YAGNIY) - solve the problem you have now One thing I really like in this area are Job Stories and the way in which they lead you to start with context and look forward to outcomes . Keep it focused  This feature works and is being still...

I hadn't intended on writing on this subject this week, it was going to be about a personal consumer travel site bugbear and my prediction for the future, but I'm going to look at empathy again. I've written about empathy and solutions with an eye on the development process and buying behaviours and usability looking at how the development and user needs might be different. So, what triggered this post? I like to use the Timehop app, which displays your history on the same day in the past across social media, and I like their mini-features like snow animations at Christmas. This Valentine's day opening up the app presented me with two options, would I like my real life on this day in social media and phone photos? Or would I prefer not to see it? Out of interest I chose "NOPE" and was presented with a fake timeline of kittens and puppies, with the option to go see my real Timehop at the end. There are a couple of things I liked about this. The first was ...

Recently I've been thinking about e mpathy in product development and how often in commercial software development that you are not the user. One area that I see a lot of people focus on is separating the problem from a potential solution in requirements.  Empathy Map by Oliver Quinlan User stories especially attempt to do this, unfortunately I don't think that the "As a ..." format as practiced is helpful, from my experience it's too easy to make it a justification exercise for a solution, it doesn't really help promote empathy or show that the user has really been taken into account. (Your mileage may vary and I'd be interested to hear from anyone who thinks that the "As A ..." user story format is the best available) In Innovation is not magic   Aly and Fernanda make the point "Innovators can get excited about things they can do and can become dazzled by the splendor of  their own creation. When someone has an idea,...

The Amadeus blog recently posted an interesting take on the fad "less is more" in a post entitled  Why the ‘less is more’ concept in software design often falls short of its intentions . At first I agreed wholeheartedly as the title and intro had lead me into some nice confirmation bias ("grrr! gosh darn those gurus selling us different flavours of snake oil every year!"). Then I thought about it a bit more and the new feature being discussed was meeting a need; people wanted it and were pleased it was now present. That made me think that there was possibly some effective product management going on .. lo and behold the post was written by a product manager! This sentence was the most telling : "how we define the worth of adding more features. For me, it is worth it if you are doing something for the human being who will be using the feature." So a focus on user need is important, as if by magic later that day I read the brilliant post   How to Work...

I am currently lucky enough to be working on a project where the developers are looking into what they can learn from academic computer science and spiking various options to explore the solution space. This got me thinking to how relatively rarely you see this, in my experience programmers tend not to read industrial journals in the same way that say civil or electrical engineers might.  One thing that I would expect to see more in agile literature are Grice's conversational maxims (Grice 1975) Maxim of Quantity: Make your contribution as informative as is required for the current purposes of the exchange. Do not make your contribution more informative than is required. Maxim of Quality: Do not say what you believe to be false. Do not say that for which you lack adequate evidence. Maxim of Relation: Be relevant. Maxim of Manner: Avoid obscurity of expression. Avoid ambiguity. Be brief (avoid unnecessary prolixity). Be orderly. For me the...

Something a bit different, some thoughts on impact mapping and a workshop that I was recently lucky enough to attend. One of the first product owner survival camps run by Gojko Adzic with Dave Evans. The workshop description starts with ... So you're a product owner with an agile team? Congratulations, you are the winner of the world record for the worst named, worst understood and most confusing role in software delivery. Apart from the fact that the PO almost never actually owns the product, they are pushed into an unrewarding role that is mostly about managing "someone else's problem". That certainly rang true for me ;) how can you take a backlog of items that you are positive that you need right now and prioritise for small, sane iterations. Further, how do you avoid WaterScrumFall in this world? The answer presented here was around impact mapping and expressing things in terms of business goal and how much the "customer" was willing to invest in t...