FruITion is a special, easy to read, Business IT book in the form of a novel. Like other books in this category, the characters used are not very realistic nor are the described situations. However, that is not very important since the aim of the book is not winning the Pulitzer Prize. In this case the author wants to challenge the way we think about IT.
The book describes the struggle of a CIO in defining an IT strategy. It starts with the CIO having a tough time defending his ‘old style’ IT strategy and thereafter being challenged by the CEO to come up with a new IT strategy. All this has to be done in just eight days. In those days the CIO interviews and discusses with business strategists, people from his own team.
Gradually it becomes clear that nobody within the company is responsible for the business case and the investments made realizing the business case. It also becomes clear that the business needs to think different about the value of its IT people and the work that they do. Many of the established views about the strategy and management of ICT are challenged. This results in some surprising insights in the scope and contribution of the CIO’s role.
Overall the book is pleasant to read, surprising and inspiring.
This book gives great insights on the product management role within Scrum and shows in detail the role of the product owner. It is not an overview on scrum. People looking more for an overview should read antoher book like for instance Kent Schwabers book Agile Project Management with Scrum.
I think this book is unique because it focusses on the product Owner role which is in my experience one of the most important and hardest roles within scrum. The book focusses on topics like:
- the product vision
- the product backlog
- the release planning
- collaborating in sprint meetings
- transitioning into the product owner role
- developing product owners
What I missed is ‘story mapping’ which I think is a powerful tool in creating a product backlog and release planning.
Still Ithink this book is a MUST read for everyone in the product owner role. The book is also very interesting for stakeholders like management to get a feeling of how the product management role changes if the organization wants to implement scrum effectively.
It’s been a while since Jim Collins wrote Good to Great, but it is still one of my favourite business books. Jim Collins started writing this book after being challenged that, ‘Built To Last’ (written with Jerry Porras) gave very little insight on how a company could go from being good to great.
The book is structured around a five year long study that identified companies that sustained excellent results for at least fifteen years. These companies were compared to a control group that failed to either make the leap or sustain it. Collins found that the chracteristiscs that differentiate the good-to-great companies and create a flywheel effect, are the the following:
- Level 5 Leadership - these leaders are not charismatic, media types. They are quite the opposite, humble and self-effacing. More concerned about the prosperity of the company than individual success.
- First Who…Then What – using a bus analogy, Collins claims that great companies first get great people on the bus, then decide where to drive it. The right people are your most important asset.
- Confront the Brutal Facts (Yet Never Lose Faith) – good-to-great companies maintain unwavering faith in their strategy regardless of the difficulties they have, and have the discipline to confront the brutal facts of current reality.
- The Hedgehog Concept (Simplicity within the Three Circles) - good-to-great companies do what they can do best, what they are deeply passionate about, and they focus on what drives their economic engine.
- A Culture of Discipline - this is a combination of a culture of personal discipline in the company with an ethic of entrepreneurship. In this culture there is no need for hierarchy, bureaucracy, or excessive control.
- Technology - good-to-great companies don’t see technology as the primary means of achieving transformation.
The book is well written and easy to read. It gives a clear answer to the question why some companies become good-to-great and others don’t. The lessons learned are summarized in a model, that can help you build a good-to-great company. In my opinion it is a MUST read for everybody in Product Development / Management.
Yesterday I was asked what the most important activities of a product owner were, a simple and interesting question. Below is a summary of what I feel are the most important activities. Please feel free to comment…
1. Creating the product vision
Every successful product development activity starts with a product vision which is clear and inspiring for every team member.
2. Grooming the product backlog
Constant prioritizing and grooming is a prerequisite for developing successful products. This also includes talking to consumers, the people who buy and pay for your product. Only this way you know if the product being build will be successful or not. It is a rough estimate, but a product owner should dedicate 15-20% of her time to this task.
3. Making the release planning
Deciding what to release and when, is an important activity. It needs frequent adjustments since the release planning is built on assumptions about:
- completeness of the backlog, we assume everything we need is known when we make the release planning,
- complexity of the product backlog, up front we make initial estimates which, might need to be adjusted when new information is available
- team velocity, especially with new or highly adjusted teams, team velocity is hard to predict. After about 5-8 sprints velocity can be estimated with a 90% accuracy.
4. Collaborating with other product owners
Scrum teams seldom operate in an environment where they are completely on their own. Most of the time they are part of a bigger system in which multiple scrum teams need to collaborate to get a project done. Therefore continuous coordination among product owners is needed. How much time a product owner should spend on this task depends on the complexity and interconnectedness of the situation. Spending about 15-30 minutes a day (2,5-5% of total time) should be enough.
5. Managing stakeholders
One of the hardest parts of the transition into lean/agile product development is explaining to stakeholders that there are no more rigid planning’s and ‘hard deadlines’. However, in the end you will get a better and more successful product. This sounds counter intuitive from a stakeholder’s point of view, since they have less influence and fewer possibilities to steer the product development process. Therefore managing stakeholders is a complex but important task. This will take about 10% of a product owner’s time. This sounds a lot but If not done correctly stakeholder support will diminish.
6. ‘Just being there’
Perhaps most important is that a product owner should ‘just be there’ for the team. Not just during official meetings, like the sprint planning, daily stand-up and demo but all of the time. Answering questions, explaining backlog items, testing and discussing items being built and taking away impediments is just as important as attending official meetings. It is therefore that I advocate a setup in which the product owner sits in the same room as the rest of the team and the scrum master.
I wasn’t sure what to expect from this book, but I hoped a lot of ideas and practical information on how to startup a business in a weekend. The book manages to help a little but I feel it reads a bit too much like an infomercial for the event (Startup Weekend) instead. In fact, the first 20 pages are about the story of how Startup Weekend, ehh, started up. It is interesting but I think it would have been better as an appendix or at the end of the book.
Overall the book is a nice introduction to the ideas behind the event and what one can expect at the event, but I missed the real meat I was hoping for. Ideas presented are not really explored in-depth. Ideas like action-based networking, the 60-second pitch and idea validation are interesting subjects. However, they are just explained from a Startup Weekend point of view. Other topics like the minimum viable product, lean and agile development are also only scratched at the surface.
Is it completely worthless then? No, there are some quotes worth remembering and it might hint you on reading other books. Furthermore if you are interested in joining a Startup Weekend event i think you should read this book. I must admit that reading the book makes me very enthusiastic about the event. It is definitely something I want to attend. However, there are better books available if you are looking for a book to read about setting up a business.
Further reading:
This book is giving some extraordinary insights in how you can develop products that people love. I can’t think of a single company that wouldn’t benefit from the concepts of a minimum viable product and feedback loop. By applying these concept companies will waste less money, making stuff people don’t want.
However, reading chapter after chapter I found myself thinking ‘Great introduction, but where’s the real meat’. Unfortunately that feeling stayed until the end of the book. Nevertheless it is an interesting MUST read for everybody in Product Development / Management.
