Shop now Shop now Shop now See more Shop all Amazon Fashion Cloud Drive Photos Shop now Learn More Shop now DIYED Shop now Shop Fire Shop Kindle Shop now Shop now Shop now
Profile for Tom Gilb > Reviews

Personal Profile

Content by Tom Gilb
Top Reviewer Ranking: 924,678
Helpful Votes: 30

Learn more about Your Profile.

Reviews Written by
Tom Gilb "Tom Gilb" (Kolbotn, Norway & London UK)

Show:  
Page: 1
pixel
Artweger RuckZuck 60 Clothes Dryer and Mounting Set, Silver
Artweger RuckZuck 60 Clothes Dryer and Mounting Set, Silver
Price: £33.90

5.0 out of 5 stars Mm, 26 Mar. 2016
Verified Purchase(What is this?)
Bb


The Scrum Culture: Introducing Agile Methods in Organizations (Management for Professionals)
The Scrum Culture: Introducing Agile Methods in Organizations (Management for Professionals)
by Dominik Maximini
Edition: Hardcover
Price: £72.00

0 of 1 people found the following review helpful
5.0 out of 5 stars Deep insights into successful and failed Scrum Organisations, 3 Mar. 2015
Disclaimer: My review is based on my initial scan of the book, and depth reading of only certain sections. But I wanted to give an early review. The author is a professional friend of mine, and we seem to agree on most subjects.

This book is a really solid piece of research into the Scrum Culture. Solid in the sense of a very large number of observations about the Scrum culture, and the observations are as far as I can judge seriously based, well formulated, and potentially useful. The origins of the core of this book is a Business School study done by the author. It meets the best standards of such work.

I did not find any statements or parts of the book that I would characterize as trivial, speculative, untrue, or badly founded. I have respect for the contents, and the author’s serious approach to the project.

The book is not intended for the average Scrum practitioner. But it is great background and insight for any Scrum teacher, Scrum Coach, Chief Technical Officer considering major adoption of Scrum, research or writer on Scrum and agile methods.

If you really want a shortcut to increasing your expertise on Scrum and agile, beyond the traditional training, and without spending many years collecting your own experiences, this book will give you a useful immediate tool and reference.

The book is at one level overwhelming. The flow of distinct ideas is heavy: at least 10 per page (my kind of book, not boring). One idea alone could be a separate book or paper. I hope Dominik will appear at agile conferences and share some of these ideas in depth.

He does paint a rich picture of the Scrum culture. He does systematically bring up, and dissect myths and misunderstandings about Scrum. He does have really great checklists of potential problems with Scrum (as any innovative culture change will experience). He does give very many constructive suggestions as to good things to do or remember.

One particular section is dear to my heart. Based on Kotter about (very rough summary, 12.3 Things You should Remember) is about having very clear visions and strategies, jointly created, data driven, challenging (but achievable) goals, specific but generic enough. “The foundation for your change process”. I believe that the many problems of culture change are best solved within this framework of clear, shared, top-level objectives.

You should not ever do Scrum because it is said to be good or popular. You will fail. Scrum and related practices are a ‘management design’ to reach ‘management objectives’ (like productivity, efficiency, predictability, quality) with both the organization, and, at a different level, to reach the requirements for projects at hand.
All culture that increases the team rate of progress towards these clear (quantified, measurable) objectives is, by definition, good and useful culture. Any culture idea that slows the team’s rate of stakeholder value delivery, even if it works well in Silicon Valley, but does not work in India or Germany, is ‘bad’ culture.
So this ‘goal-directed culture change’, gives us a simple high-level guideline for what to do in practice. Scrum likes to keep basics simple!
Say there are perhaps 500 distinct possible ideas in the book. Try the few most promising ideas that you believe will work. One at a time. If your teams improve their rate of result and value delivery at each succeeding sprint, then keep the idea. It works. For now anyway. If not, dump it quickly. Don’t keep it ‘because it is in the book’. Keep it only if it works cost-effectively for you.

This is partly a book that can be read through, to become familiar with the very large number of concerns, to change a culture successfully using Scrum; any the many practical things you need to add to the Scrum framework (like my favorite addition, quantified top level objectives for qualities).

It is also a book that the people coaching and managing that change, should have on their personal bookshelves, so they can look up and find insights into problems that they are currently experiencing. The book is ‘expensive’, but it is a very cost-effective (5000 to 1 efficiency at least, I’d say) experienced expert at your side, to give emergency help to culture-change problems, that can get out of hand, and become very costly, if not diagnosed and corrected in time. If you are investing in Scrum, or indeed similar Agile practices, you can not afford to not have this body of knowledge in house now. A bargain of the best consultant advice.

Summary:
I think this book is a great contribution to the Scrum literature, indeed to organizational change literature. It makes the many complexities of organizational change very transparent. Using this as a guide we can expect the % of successful Scrum implementations to improve. Scrum is simple in principle, but even the simplest changes to culture can be complex to understand, and to make a success. You need this tool to help you. This is not a ‘programming’ issue. This is a management issue, even for self-managed teams.
Comment Comment | Permalink


Impact Mapping: Making a big impact with software products and projects
Impact Mapping: Making a big impact with software products and projects
Price: £7.42

18 of 20 people found the following review helpful
5.0 out of 5 stars Useful Practical Transformational, 18 Nov. 2012
First, a confession of self interest. Gojko is a new professional friend, who I have met at several IT Conferences. He cites and credits me, and my ideas, in his book. All of his ideas are highly resonate with my own. So, what is not to like?

On the other hand, I have a reputation, I hope, of being highly critical of most all the new IT development trends. Partly for the sport, partly because software as a trade is still so embarassingly primitive, and failure prone (a subject Gojko leads in with). So, if there is something wrong with the book, something that would waste the readers time - I am honor-bound to say so!

I have a method for reviewing books. If the point made in a sentence or paragraph is IMHO a good one, I write a `+' in the margin. If it is debatable, a `?' and you can guess what symbols I use for brash claims and bad logic. If it is generally bad for long stretches, I don't mark anything, put it aside and, politely, don't review it.

Hopefully the intelligent public won't be fooled either, by useless books. But the IT development community is famous for liking and adopting very `simple' development ideas, that don't work. Or, worse, the methods work a little better than even worse, previous methods. Our failure rate is still horrendous - a shame to the profession. I read this book in 3.5 hours straight, interspersed with other things (OK, family TV).

So how does this book rate? Every page has about 4 to 8 `+'s. There are no `-`s at all. There are a very few places where a `?' means it might be clearer for me. So that means I think Gojko has hundreds of well-formulated and useful insights (`+') that are worth sharing. Pretty good, since some books in our profession have none (IMHO).

But the overall picture is even more important than a stream of deep and useful insights.

1. He totally understands that IT and software development must primarily be about delivering real value for money to stakeholders (who he calls `actors').
2. He understands that software alone is not the solution to all problems and objectives, even in a software-dominated system or application. He understands that we have to include a notion, that others call `systems engineering': meaning `considering the totality of smartest ways to solve the problem, of delivering value for money to stakeholders'.
3. He gives us a simple co-operating set of potentially useful tools (`Impact Mapping') for helping us keep focused on the real stakeholder objectives - in spite of a complex and rapidly changing world.

He is very open to any ideas that might help us further the `value for money for stakeholders' objective, and draws on a rich, but reputable, variety of credited sources. He is enthusiastic about his toolset, yet clear about the fact that it is early days in his own personal use of the entire method, and that we need to get experience with it, and perhaps evolve it - as he already has done compared to his previous book. He does not yet offer detailed case studies, let alone scientific studies of the method. But he hopes the community will help collect this data, and specifically refers to a website to start a community of practice. If history is any guide, the case studies will arrive, and data will be collected. And `Impact Mapping' will hopefully turn out to be a useful wave of improvement.

I know, from my own experience, the power of much of what he recommends, for example the power of taking the step of quantifying the top level project drivers; to clarify the stakeholder values. This step is like day from the night of the pervasive management BS driving most all software projects.

He tries to describe pitfalls, so we can avoid them. I like such a balanced picture, and a realistic picture.

One central idea, if not THE central idea, is that there is a causal chain from the central `business' objectives of the development project, to the stakeholders, their values, and finally to the means (design) to deliver prioritized satisfaction of those values. I am totally in sympathy with that idea, and it has been totally missing from the current `agile' culture, as I have repeatedly pointed out.

IT systems are too important to society to be put in the hands of `coders' who cannot raise their sights to the interests and values of victims of their craft.

Gojko gives us a practical set of tools to work this value chain, and maintain its integrity during change.

Are their things I would improve upon? Of course; and so will Gojko, and hopefully maybe you, reading this. But we all are subject to the cultural maturity of our clients and students. We cannot impose `ideas of sophistication' on the many who are not yet motivated, experienced and ready for such `improvements'. Culture change takes decades, at least, and we have to be patient.

I, for one, would be delighted if Gojko helps us get more buy-in, for real, of the central practice of `recognizing that the central mission for IT developers is to consistently, early, frequently, and cumulatively deliver central, critical, high-level improvements to the stakeholders'.

Imagine if we `nerds' one day became famous for our ability to deliver amazing value quickly?

Tom Gilb
[...]
18 November 2012
Kolbotn, Norway


The Lean Startup: How Constant Innovation Creates Radically Successful Businesses
The Lean Startup: How Constant Innovation Creates Radically Successful Businesses
by Eric Ries
Edition: Paperback
Price: £10.49

2 of 3 people found the following review helpful
5.0 out of 5 stars Great Practical Groundbreaking System Development Ideas, 3 Dec. 2011
I loved this book! I am recommending it to all my adventurous and open minded professional friends. I enjoyed reading is as an ebook alternately on my iPad and iPhone. The length is nice and short. The practical examples still rich. The deep understanding of a high risk, high uncertainty learning process is impressive.

Eric believes in the same basic ideas of development that many of us have championed for years. Clear quantified ideas of real world progress, being tested rapidly and frequently in feedback cycles. The emphasis being 'learning what is real and true, asap'.

The difference is that Eric applies these ideas at an extreme that I personally have not dared to think or experience. He is operating at the 30 to 50 real changes a day being measured and learned from, from the real world. This is about gathering 'requirements' from the real world by continuously (every day) and frequently (dozens of measured hypothesis per day). This is about testing alternative designs just as early and continuously, and letting design and architecture emerge as whatever really works in satisfying the simultaneously emerging requirements.

This is revolutionary! But for the skeptic, Eric documents in detail how it works in real named busnesses. Eric is very clear about his sources of ideas, the classical gurus like Deming, Drucker, Toyota-Ohno, and many such more. He is equally clear that his method's role is primarily a framework to allow extremely rapid learning about what really works, and for whom it works.

He clearly positions 'Lean Startup' as a way of managing system-building processes such as agile methods like XP and Scrum. I and my professional friends, have long campaigned for much better multidimensional quantified quality requirements, for a rich variety of stakeholders (gilb.com).

But the majority of 'agile' developers don't want to know about such disciplined thinking. They would rather fail.

Eric speaks openly of his earlier failed projects (using conventioanl wisdom), and those of other businesses and clients. The conventional startup, and software development methods are inevitably highly failure-prone, and have been for decades.

That is because there is too little clarity of purpose (clear quantified quality requirements), and too little understanding of the variety of stakeholder values.

The Lean Startup ideas convincingly show how to avoid the embarassing pervasive development project waste. History shows that the developers themselves, while intelligent enough to use these disciplined Lean Startup methods, are not likely to jump in and adopt them on their own initiative. They (developers) clearly prefer to get well paid to code fast - using Agile methods alone, using relatively little engineering discipline (and Lean Startup is rigorous scientific method and engineering discipline). They seem to feel no real responsibility for successful outcomes. Failure still gets well paid, at their level.

So this brings up the question of who this book is for. And who will in fact make sure the ideas are implemented. This has to be the people laying the investment on the table, hoping to get a return for it. Directors, CEOs, CTOs, Angels (startup investors).

They need to demand, as a precondition for their investment, the kind of rapid learning, and rapid early 'pivoting' (major changes in architecture, stakeholders, markets, product design) that Lean Startup teaches. It is this level of power and responsibility that needs to understand the basics of Lean Startup, and to demand their use.

I think this executive level has to far too long, in the history of software development, totally abdicated their responsibility to ensure serious management of IT and software projects.

My extensive experience shows they rarely bother to even have clear quantified trackable requirements for massive (like $100 million) investments. Business schools have not been helpful in training managers to deal with multimensional critical project requirements. If history is any guide, we are not going to change our irresponsible software investment culture in the short term.

But Lean QA is a clear opportunity for the wiser top managers to make sure THEY will succeed, and hopefully in the longer term the amateur, non-scientific. non-engineering methods of the current software culture will die out.

Get the book, read it now, spread the word, and see Erics many good Googleable presentations and videos as a supplement.


Cult-Ure
Cult-Ure
by Rian Hughes
Edition: Imitation Leather
Price: £24.95

10 of 11 people found the following review helpful
5.0 out of 5 stars Deep Wisdom At Machine Gun Pace, 27 May 2011
This review is from: Cult-Ure (Imitation Leather)
One of the most fun and insightful books I have ever read!

I would recommend this to people who are interested in communication of ideas. And that is most of us! It is also a book for those who want an example of a totally new type of book!
My first idea was that I should underline all the significant statements, as I usually do. I immediately encountered several deep ideas. But then I discovered a problem. I would have to underline 99% of all the statements! The book is filled with one worthy observation after the other, many on each page. No fluff. This book does not waste your time. It gets right to the points. I love the stream of interesting insights.
Friends who have looked at my copy have the same reaction, Wow! I want to read this after you are done. Some of us are directly envious about the fun graphics quality, which is a dominant part of the book. We wish we could write a `management' book in this exciting style. The graphics are well designed, and make the absorption of the deep points an extra pleasure. I guess it has not been economic to make books a colourful as this earlier, so we built up habits of mainly-text books. Times are changing. This is a book for people who love their iPhone! Who love great and useful design. Books will never be the same, and other books look distinctly boring by comparison!


Page: 1