Running an Agile Software Development Project is an interesting book. On the surface it looks like it would be very academic, because the author, Mike Holcombe, was a University Professor at the time, and running an “agile software development factory” of students (albeit for a real commercial development shop). And yet what is described in the contents is very much the practical, real-world results of running agile projects with those same people for real IT software development work.
[...]
Overall, I found Running an Agile Software Development Project to be interesting and enjoyable. It still seems just a bit academic for my taste, and probably wouldn’t be the first book I would recommend on the subject unless it was for a classroom audience (in which case this book would be an excellent one to use).
It’s tougher than ever to get that great job. Companies are more demanding and your competition is smart, tech-savvy, and resourceful. You’ve got the right skills for the job—you also need the right skills for job hunting. You need to work deliberately on your new job hunting skills, and this book can help. Old fashioned cookie-cutter job hunting skills aren’t enough: Land the Tech Job You Love gives you the background and the hard-won wisdom to leapfrog those who play by the old rules.
Andy tells us, “Life is too short for a job you don’t love. You’re not stuck—other opportunities are available for you, if you know where to look and can work the hiring process to your advantage. This book will help you get that job you love.”
In this book, you’ll learn how to find the job you want that fits you and your employer. You’ll uncover the hidden jobs that never make it into the classifieds or Monster. You’ll start making and maintaining the connections that will drive your future career moves.
Andy started writing this book years before the recession (a.k.a. “econopocalypse”) hit. He looked at the conventional wisdom and the advice available in generic books on job hunting, and found the conventional wisdom just didn’t work for programmers, system administrators, testers, and other related development positions.
He looked at everything from whether you should look for work on online job boards to whether you should lead off your resume with your objectives. Although he has definite answers for these two, he found that the answer to most questions is “it depends.” His book leads you to taking an honest assessment of what you offer and what you want in a job so that you end up in a job that is a good fit for you and your employer.
This is an important book for you to read whether you currently have a job or not. The same tactics you take to make yourself more employable will also make it easier to get promoted in your current company.
The Economics of Iterative Software Development: Steering Toward Better Business Results is an important text for anyone trying to persuade management to "go iterative" as well as to anyone needing to measure & track the kinds of business results that management needs to see for a software development project.
I'll be perfectly honest: I was expecting this book to be an extremely dry and boring read, albeit full of lots of useful information densely packed in mathematical models and formulas, perhaps reminiscent of past college days reading a huge tome on socio-political economic theories. It wasn't as bad as I'd feared. Yes - it is a bit dry in places, but those are the exception rather than the rule. And there are lots of "war stories" sprinkled throughout that hold your interest and stop your eyes from glazing over.
...
All in all, The Economics of Iterative Software Development is a solid-book that is a relatively light/quick read with lots of good, practical advice on how to apply an economic model of thinking and measurement for managing and tracking business-results of an iterative project. If you need help doing that, or with communicating to your management about the need and benefits of an iterative approach, then you need to read this book!
Agility is all about harnessing the power of collaborative people and frequent delivery to:in a volatile global marketplace.
- learn & adapt to change,
- minimize risk & cycle-time, and ...
- maximize returns & customer-value
With last month's announcement of the Lean Software and Systems Consortium at the 2009 Lean & Kanban Conference, it seems fitting that this month's book is about Lean Software Development and how Agile development practices support Lean Thinking.
The Art of Lean Software Development: A Practical and Incremental Approach is an introduction to Agile software development practices through the lense of Lean thinking. The first thing you need to know about this book is who its target audience is [...] from the publisher's website for the book: "This book has a very specific purpose -- it is aimed squarely at the complete novice. The one who has been hearing all the Lean-Agile buzz, really knows nothing about it, and wants to learn more quickly to decide if they want to dig deeper (without having to read a 500 page tome)."
...
Now that we've finally gotten that out of the way ... The Art of Lean Software Development actually succeeds at its intended purpose. It is a very "lean" introduction to the subject of applying lean thinking to software development. (You can see for yourself by looking at the online excerpts of chapter 2 and chapter 4.)
...
I like just about everything that The Art of Lean Software Development has to say. It is a bit of a dry read but a very quick one. ... For those more interested in the abridged version or the line-manager's equivalent of a technical overview, The Art of Lean Software Development is a very quick and easy read that successfully introduces the history and essentials of Lean and Agile software development from a Lean thinking perspective.
The book is exactly what its title says, and should quickly become “the bible” for all would-be agile testers. Right from the start it is obvious that this book is not about theory, but is borne from profoundly deep insight and broad experience on real world projects. It doesn’t just cover testing types and techniques, or values and principles, but also real world challenges from organizational culture to team logistics; and from technological and geographical constraints to tooling, environments, and communication/collaboration.
...
If your organization has dedicated testers and test-teams and wants (or needs) to learn how to work effectively on agile projects, or even just in an agile fashion, I currently cannot envision a better or more practical “HowTo” guide then Lisa Crispin’s and Janet Gregory’s Agile Testing: A Practical Guide for Testers and Agile Teams. I expect it to appear at the top of any mandatory reading list about learning and setting-up a discipline of agile testing.
Implement Configuration Management Databases that Deliver Rapid ROI and Sustained Business Value. Implementing an enterprise-wide Configuration Management Database (CMDB) is one of the most influential actions an IT organization can take to improve service delivery and bridge the gap between technology and the business. With a well-designed CMDB in place, companies are better positioned to manage and optimize IT infrastructure, applications, and services; automate more IT management tasks; and restrain burgeoning costs. Now, there’s an objective, vendor-independent guide to making a CMDB work in your organization. The CMDB Imperative presents a start-to-finish implementation methodology that works and describes how the CMDB is shifting to the superior Configuration Management System (CMS).
Expert CMDB industry analyst Glenn O’Donnell and leading-edge architect and practitioner Carlos Casanova first review the drivers behind a CMDB and the technical, economic, cultural, and political obstacles to success. Drawing on the experiences of hundreds of organizations, they present indispensable guidance on architecting and customizing CMDB solutions to your specific environment. They’ll guide you through planning, implementation, transitioning into production, day-to-day operation and maintenance, and much more. Coverage includes:
- Defining the tasks and activities associated with configuration management
- Understanding the CMDB’s role in ITIL and the relationship between CMDBs and ITIL v3’s CMS
- Building software models that accurately represent each entity in your IT environment
- Ensuring information accuracy via change management and automated discovery
- Understanding the state of the CMDB market and selling the CMDB within your organization
- Creating federated CMDB architectures that successfully balance autonomy with centralized control
- Planning a deployment strategy that sets appropriate priorities and reflects a realistic view of your organization’s maturity
- Integrating systems and leveraging established and emerging standards
- Previewing the future of the CMDB/CMS and how it will be impacted by key trends such as virtualization, SOA, mobility, convergence, and “flexi-sourcing”
Drive breakthrough database application performance by optimizing middleware and connectivity. Performance and scalability are more critical than ever in today’s enterprise database applications, and traditional database tuning isn’t nearly enough to solve the performance problems you are likely to see in those applications. Nowadays, 75-95% of the time it takes to process a data request is typically spent in the database middleware. Today’s worst performance and scalability problems are generally caused by issues with networking, database drivers, the broader software/hardware environment, and inefficient coding of data requests. In The Data Access Handbook, two of the world’s leading experts on database access systematically address these issues, showing how to achieve remarkable improvements in performance of real-world database applications.
Drawing on their unsurpassed experience with every leading database system and database connectivity API, John Goodson and Rob Steward reveal the powerful ways middleware affects application performance and guide developers with designing and writing API code that will deliver superior performance in each leading environment. In addition to covering essential concepts and techniques that apply across database systems and APIs, they present many API examples for ODBC, JDBC, and ADO.NET as well as database system examples for DB2, Microsoft SQL Server, MySQL, Oracle, and Sybase. Coverage includes:
- Clearly understanding how each component of database middleware can impact performance and scalability
- Writing database applications to reduce network traffic, limit disk I/O, optimize application-to-driver interaction, and simplify queries—including examples for ODBC, JDBC, and ADO.NET
- Managing connections, transactions, and SQL statement execution more efficiently
- Making the most of connection and statement pooling
- Writing good benchmarks to predict your application’s performance
- Systematically resolving performance problems—including eight start-to-finish case-study examples
Francis Fukuyama is noted for writing "The End of History" and "The Great Disruption" as well as for "Trust: The Social Virtues and The Creation of Prosperity." As such, it is pretty easy to draw inferences about his political viewpoint(s). Many reviewers have made the assertion that his books are a product of his politics. I (personally) don't know enough to comment.
That exact argument -- questionable causality -- is one they make against some of the correlations that Fukuyama cites in Trust, but they seem to miss it when it applies to their own positions. So beware: the book may be written in deliberate support of his politics, or his politics may have evolved from the studies he has done. It's your call.
Fukuyama claims that trust is a form of "Social Capital." That is, trust is something that you can invest in, something that you can create or obtain more of, something that you can use to achieve an economic end, and something that has value.
He further claims that the presence or absence of trust in a society has a significant, measurable impact on the economic indicators for that society, and that it probably has other, less clear effects as well. All of this is generally in agreement with other writings on trust that Brad has cited here.
His argument, then, is that there should be a way to objectively test for the amount of trust in a society. His test criterion is the number of employees that work for medium-sized businesses, where business size is a function of the number of employees. (That sounds circular, but it isn't.)
For example, my neighborhood pizza shop is run by George, his wife Rosanne, and their son Steve. There are two other cooks, and two delivery drivers. So the business has 7 employees, which makes it a small business.
By contrast, GM just announced that they intend to close down the Pontiac car brand, and lay off 21,000 workers. Having 21,000 workers to lay off makes GM a really, really HUGE business.
Somewhere between the two extremes lies a medium sized business. I don't recall exactly what numbers Fukuyama used, but let's say it's 100 <= n <= 1000. So we have small is less than 100 employees, medium is up to 1000, and large is anything over that.
With those boundaries in mind, the question is simply how many employees in a particular country work for a business that can be classified as "small," or "medium," or "large." Well, if there are 200 small businesses, and their average size is 30 employees, then 6,000 employees work for small businesses. (That's how we figured the average size, I guess.)
What Fukuyama found was that some regions or countries exhibited a noticeable "saddle shape" in their graph of business size versus number of employees. There were lots of people working for small businesses, and there were lots of people working for large businesses, but few people working for medium sized businesses.
He argues that large businesses are a distraction, because governments can create large businesses by fiat. France, Mexico, and most of the OPEC countries have huge businesses that were created by the government (as opposed to being grown up from small businesses).
Small businesses, naturally, are the starting point for almost everything. Somebody has an idea, they start a business with their close friend from college or their brother or parents, and if they make money they start hiring.
The problem comes when all the family members are hired. If the entire family is hired -- all the brothers, uncles, cousins, etc. -- and they're all doing some kind of management thing, with "outsiders" brought in to do the simple labor, the business has reached a critical point.
At this point, the business may or may not be *capable* of bringing in a qualified stranger, and handing that stranger an appropriate amount of power. That transition, from family shop to "real company," is the dividing line that Fukuyama is really looking for with his arbitrary criterion of 100 employees.
And he argues that if you see a disproportionately low number of workers that have jobs at medium-sized companies, it's because there are a low number of medium-sized companies. And *that* is because there is not enough social trust. When grandpa and dad and uncle Cletus can't let go of the reins, the company can't get any bigger. And in fact, the company will likely fail shortly thereafter, resulting in a much smaller business after the smoke clears.
Using his metric, there are some genuine surprises. Germany is a high-trust country, but France is low-trust. Southern Italy is virtually a no-trust area. Japan and Korea appear low-trust, until you refactor your statistics to deal with the Zaibatsu. China and most of the Asian mainland are low-trust.
This is interesting, but not necessarily controversial. What *is* controversial is the correlation with "The Protestant Ethic and the Spirit of Capitalism" (Max Weber, 1905 !!). That offends a lot of people, for a lot of reasons. Weber's point, made back when people were giving serious credence to "racial studies" and other stuff, was that Protestant countries did better economically than Catholic ones. Fukuyama makes a similar point, but claims that the effect is corollary, not causal.
Fukuyama's point is that there are a lot of flavors of protestantism, and countries that are majority protestant don't always have social mechanisms for creating and maintaining trust networks. If you can't generate trust, it doesn't matter how Protestant you are.
Things like the Rotary Club, and the Moose Lodge, and the Veterans of Foreign Wars in the United States do that job for us. These little mini-networks enable people of similar creed to reach each other, so that there are many networks of high trust -- "I trust him because we go to the same meetings" -- working parallel to each other. This enables Catholics to network with Catholics, Baptists with Baptists, Scrum fans with other Scrum fans, etc.
The rest of the "trust equation" is pretty straightforward. Nearly all of the trust literature agrees on these things: high trust leads to efficiency. Fukuyama's point is illustrated in any American business transaction. If you make noises of intent to engage in such a transaction, the expectation is that both sides intend to do so fairly.
That simple fact -- that you can go into a sandwich shop, for example, and place an order, and they will start making your order before you pay for it -- is one that is hard to see if you aren't looking for it.
The reverse situation pertains low trust areas. If you try to do business in these places, nothing is done until the cash changes hands, or at least until it is displayed for all to see.
A similar thing occurs in my own line of work, where implementing change tracking lifecycles is surrounded by requests to create explicit status codes for each possible situation. ("You should have a 'completed by development, but QA will not start testing due to other commitments' status code!")
It's important to keep in mind that the business-size metric is an indicator, nothing more. And that Fukuyama uses that metric as a way to set expectations for research, not as a causative for other social ills. A small number of medium-sized businesses doesn't cause poor social trust. It is an indicator that social trust is likely poor. (Or, as in the cases of Japan and Korea, that the metrics need to be refined.)
One of the reasons for many of the negative reviews is Fukuyama's assertion that trust is not correlated with equality, or fairness. American society has historically been more unfair and inequal than otherwise. Every single minority has been discriminated against at some point, which has led most of them to creating their own separate "civil associations" -- networks of trust.
The obvious inference is that eroding the separate networks of trust will result in an overall low-trust society. This isn't particularly politically correct, and so you can probably imagine how it was received in academic and/or liberal circles
"Building trust begins with an honest understanding of trust, but it also requires everyday routines and practices. Without the practices, that understanding comes to nothing." [what happens if I replace "trust" with "agility" in this sentence]
"Trust is the essential precondition upon which all real success depends. The key to trust is action, and, in particular, commitment: commitments made and commitments honored."
"The problem of trust has clearly emerged as the problem in human relationships and organizations. What makes most companies falter-leaving aside market forces, bad products, and incompetent management-is the lack of trust."
"Trusting is something we make, we create, we build, we maintain, we sustain with our promise, our commitments, our emotions, and our sense of our own integrity. "
"Trust is not merely reliability, predictability, or what is sometimes understood as trustworthiness. It is always the relationship within which trust is based and which trust itself helps create."
"The freedom provided by trust is the freedom to to engage in projects that one could not or would not undertake on one's own. The freedom provided by trust is the freedom to approach and engage with strangers whom one may in fact never lay eyes on. The freedom provided by trust is the freedom to think for oneself and speak up with one's ideas. It includes as its consequence (not its cost) the freedom to be questioned and criticized -- and the right to be recognized and (if deserving) rewarded."
"Trust is a matter of making and keeping commitments, and the problem is the failure to cultivate commitment making.
"Trust involves sincerity, authenticity, integrity, virtue, and honor. It is a matter of conscientious integrity."
"Authentic trust is going into the unknown together."
"The worst enemies of trust are cynicism, selfishness, and a naïve conception of life in which one expects more than one is willing to give. Resentment, distrust, and inauthenticity are the result."
"Self-trust is the most basic and most often neglected from of trust. Distrust is often a projection of missing self-trust."
"Trust goes hand in hand with truth. Lying is always a breach of trust. What is wrong with lying, in turn, is that it breaches trust. ...telling the truth establishes trust and lying destroys it."
"Authentic trust can never be taken for granted, but must be continuously cultivated through commitments and truthfulness. True leadership, whatever else it may be, can be based on nothing less."
"cordial hypocrisy: the strong tendency of people in organizations, because of loyalty or fear, to pretend there is trust when there is none, being polite in the name of harmony when cynicism and distrust are active poisons, eating away at the very existence of organizations [or relationships]."
"How we think about trust ... makes trust possible, difficult, or even impossible. Trust (like love and freedom) involves any number of self-promoting and self-defeating prophecies."
"Trust(ing), not trustworthiness, is the issue. The existential question is how to trust, not just who can be trusted. (Trust is not only earned; it must be given.)
Trust is a matter of reciprocal relationships, not of predictions, risk and reliance.
Trust is transformative. It is not a matter of trusting or being trusted so much as it is a matter of changing each other and the relationship through trust."
"The German sociologist Niklas Luhmann stresses that trust is a way of dealing with complexity in an increasingly complex society. There is a deep truth to this. The paradigm of trust is not found in the simplicity of a familiar relationship. Rather, it exists in the new complexity of the world and the global economy. Trust not only lets us increase complexity in our lives (and thus simplify them at the same time); it also changes our lives in dramatic ways, allowing us to explore in new directions, to experiment and express ourselves in our relationships in ways that would otherwise be unthinkable. And it allows us to grow and change and mellow and deepen in all the ways that merely provincial trust and distrust distort and prohibit."
"Trust is not always a good thing. Trust can be foolish, naive, gullible, and blind. And trust ought never to be taken for granted. That is why we insist the issue is building trust -- that is, creating trust, maintaining trust, restoring trust once it has been lost or betrayed. We want to suggest that this requires a radical revision of our conception of trust. Our thesis, to put it simply, is that trusting is something that we individually do; it is something we make, we create, we build, we maintain, we sustain with our promises, our commitments, our emotions, and our sense of our own integrity.
Trust is not, contrary to what some authors have written, a medium, an atmosphere, a 'lubricant,' social 'glue,' a lucky break for one society or another, or some mysterious social 'stuff.' Trust is an option, a choice. It is an active part of our lives, not something that is there from the beginning, or that can be taken for granted. It involves skills and commitment, not just good luck or mutual understanding.
The focus of trust -- or what we will call authentic trust -- is not just the hoped for outcome of this or that event or transaction. Trust is not merely reliability, predictability, or what is sometimes understood as trustworthiness. It is always the relationship within which trust is based and which trust itself helps create. Authentic trust does not necessitate the exclusion of distrust. To the contrary, it embraces the possibilities of distrust and betrayal as an essential part of trust. To be somewhat grim in our initial characterization of trust, it entails the possibility of betrayal.
The loss of trust is not mere disappointment. That is why trust is often evident only in the event of a breakdown. Like love, trust often becomes most palpable in the breach. (“You don't miss your water till the well runs dry.”) Building trust means coming to terms with the possibility of breach and betrayal."
"Trust, like love, may seem to fail us, but truly, we fail at trust or love. But then we get more sophisticated. We learn that trust, like love, is an emotional skill. It requires judgment. It requires vigilant attention. It requires conscientious action. It involves all of the intricate reciprocities of a human relationship (even in cases in which it remains “unrequited”)."
"Trust. like love, is an emotional skill, an ongoing dynamic aspect of relationships. We don't just fall in love, we decide to love. So, too, we do not simply find ourselves trusting, after months or perhaps years of comfortable familiarity. We make decisions to trust. We make promises and tacit communication. We see them through. We come to have expectations of others, and we respond to the fulfillment or frustration of those expectations. Trust isn't something we 'have,' or a medium or an atmosphere withing which we operate. Trust is something we do, something we make. Our mutual choices of trust determine nothing less than the kinds of beings we are and the kinds of lives we will live together."
| MYTH | REALITY |
|---|---|
| Trust is soft. | Trust is hard, real, and quantifiable. It measurably affects both speed and cost. |
| Trust is slow. | Nothing is as fast as the speed of trust. |
| Trust is built solely on integrity. | Trust is a function of both character (which includes integrity) and competence. |
| You either have trust or you don’t. | Trust can be both created and destroyed. |
| Once lost, trust cannot be restored. | Though difficult, in most cases lost trust can be restored |
| You can’t teach trust. | Trust can be effectively taught and learned, and it can become a leverageable, strategic advantage. |
| Trusting people is too risky. | Not trusting people is a greater risk. |
| You establish trust one person at a time. | Establishing trust with the one establishes trust with the many. |
Robert ("Uncle Bob") Martin and the folks at ObjectMentor have written a new book that should be required reading for all programmers! When it comes to writing clear and maintainable code, cleanliness is indeed next to godliness, and we should all follow the Boy Scouts' Rule whenever we write or modify any piece of code: leave the place cleaner than when you found it!
Robert C. Martin is one of the giants of object-oriented design, and a founding father of the agile manifesto and of agile software development. More recently, he helped kickstart the software craftsmanship movement, which gained much attention from his keynote at Agile2008 and subsequent talks on craftsmanship and ethics.
...
If you are at all serious about programming, then as soon as you finish reading this review you should get your hands on Clean Code as fast as you can! Get it. Read it. Learn it. Then live it!
Kessler and Sweitzer's Outside-in Software Development should resonate deeply with all those who genuinely value the principle of customer collaboration in the Agile Manifesto, and with anyone who has played the role of Product Manager for a software project. This 2008 Jolt award Finalist is not a book about eliciting or prioritizing requirements (or "user stories") for an Agile project. This book goes beyond mere user-stories and their ranking or velocity to focus on uncovering the underlying needs and goals of your stakeholders and understanding what truly adds value for the customer and the business.
... I think Outside-in Software Development is a profoundly important book for anyone in the Agile or Lean "camps" because it addresses and embraces the often neglected pieces of the customer-relationship puzzle that emerge from the stakeholders' perspective, often after the software is released. It shows us how many of those same Lean and Agile values of collaboration, responsiveness, waste-elimination, and respect for people can be successfully applied to the users' experience with our software, and to the stakeholders' experience with ourselves in the service of realizing the very business value we strive to deliver.
