Johanna Rothman

Software projects are notoriously difficult to estimate a time-to-completion, especially in the earliest days of a proposal. Sometimes, simple projects can prove time- and resource-consuming, and seemingly hard projects can complete quickly. Because learning is involved in every project, even good project managers struggle with wildly varying possibilities at first. Author Johanna Rothman offers her advice about what to do with this situation.

A few pieces of her advice stand out. First, when show more estimating, always provide a window of confidence (e.g., 3-6 months) instead of a definitive date. Second, iterate your estimation as time goes on; your accuracy will improve dramatically each week. Third, always consult the people doing the work to get their best guesses. Fourth, remember each project's constraints and each project's unique goal to optimize (features, cost, or schedule).

Unfortunately, this book represents a compilation of 26 blog posts, which need to be edited together into a coherent thesis instead of lightly stitched together more like an anthology, as here. I don't mind reading short-form blogs, but a book needs to be developed as a long-form project with some central themes. Those primary principles are altogether lacking here, and the reader is left for them to emerge from the shorter blog posts. That's unfortunate because the offered advice has a solid foundation in experience and reflection. show less

Today’s world is increasingly dependent on technology to increase the efficiency and effectiveness of our businesses. Yet assessing which technical person to hire can be a tall task. Do you just hire the one that is most like you? Or do you hire the one with the most accolades? And how do you advertise? Johanna Rothman’s book empowers readers to figure out their own answers. Although the technology of hiring has changed significantly since its 2004 publication, the people side has not. show more This book will make readers much more savvy about how to attract, evaluate, and hire the best for their organization’s tasks.

The world of technology often falls into traps of constant infatuation with fads. Certain buzzwords and concepts can be trendy, but fundamental skills are often overlooked. I suppose the same is true with human resources. Thankfully, Rothman teaches us to see through the ephemeral fads. Her book shows how to think through the specific requirements of the job at hand and how to match individuals to that description. She also demonstrates how to corral an organization into making the new hire successful for the long term.

This book is written to hiring managers, but as someone who does not work in human resources, I still found her advice helpful. Anyone who evaluates talent – the most important managerial task for any organization – can benefit from her wisdom. I’m trying to improve my skills about gauging software developers’ skillsets and don’t want merely to hire someone because they’re most like me. She showed me how to observe their skill through a resume and an interview process. Her book also demystified the hiring process whenever I might have to reenter the job market. For those things, I am grateful. show less

From a technical point of view, Agile project management, and particular methodologies such as Scrum and Kanban are neither new, nor very complex. In fact, one can say fundamental definitions, rules, metrics, and workflows could be easily summarized in a few pages. In other words, no rocket science.

So, why bother with a book that's more than 250 pages? As with all things related to organizing humans, and setting up communication structures, persuading people to move to a different show more methodology, listening to an expert that has multi-decade experience helps. It especially helps when it is always possible to encounter traps and pitfalls, and when you need to to deal with ambiguity, as well as certainty arising from different aspects of work cultures in different companies.

Is this book perfect? No, not at all. If you want read a more concrete and focused case study [book:Lean from the Trenches|12693642] might be your cup of tea. Or if you want to go into the details of User Stories, then [book:User Stories Applied: For Agile Software Development|3856] might serve you better for that particular topic. Nevertheless, I still find Rothman's book valuable for its broad coverage, as well as its explanations on how simple concepts such as "velocity", "burn down charts", "delivering business value", "definition of done" can be misinterpreted and abused.

The chapter on applying an agile approach to workgroups, who are not teams, and who are not software-focused is also valuable, because it shows how the general principles can be applied to cases where it's not about a single team working on a single software product / project.

I also liked her explanations about various aspects of estimation: not everything she says will be easy / compatible with your environment or way of working, but those explanations will give you a good basis for thinking about, and later, managing your estimates.

Finally, as a minor criticism I have to add I wish the publisher / editor took more care to print graphs and charts in full color, instead of grayscale! Pragmatic Bookshelf should take such aspects of book quality more seriously. show less

I really wanted to like this book, and it did have some useful information. However, it had too many issues to be really enjoyable.

It was repetitive. It had a large amount of internal cross-referencing, which is good, but each reference was "Section X.Y, Full Section Name, on page N" which got annoying after awhile. There were a number of editing errors, and there were some sections where I doubted editing had been done at all. E.g., the chapter on measurement, which I was really looking show more forward to, had a bunch of graphs with some description, but no actual explanation of what where the values on the graph came from.

The biggest flaw, however, is that this book set itself up to be a book about project portfolio management for any project life cycle, but it felt like every other section had a "but that won't really work well if you're not using agile" caveat.

Overall, I don't regret having read this, but I cannot recommend it. show less