We’re pleased to announce that our latest book, Head First Agile, is finally here. We’re so pleased with how it turned out… and we’re not alone! Head First Agile has already gotten such a positive response from early reviewers.
In Head First Agile, we answer the question “What is agile?” and go in to give you a deep dive into Scrum, XP, and Lean/Kanban. We also include a complete guide to the PMI-ACP® (Agile Certified Practitioner) certification, so if you’re preparing for the PMI-ACP® exam, this is definitely the book for you!
You can buy the book from Amazon (and other retailers): https://www.amazon.com/Head-First-Agile/dp/1449314333/
It’s also included with your Safari subscription. If you’re not on Safari, you can start a free trial right now: http://shop.oreilly.com/product/0636920022374.do
So if you’re looking for a fun, easy-to-understand, brain-friendly guide to agile, we really think you’ll love this book.
It’s a pleasure (and relief!) to announce that after almost two years of work, the third edition of Head First C# is in print and available in bookstores. Head First C# is one of the most effective books on the market for learning programming with C#. Many thousands of readers, some new to programming and others with experience with other languages, have used the first and second editions. And now here’s the third edition, hot off the presses:
This was a major update of the book. The biggest challenge was finding an effective way to teach XAML. XAML is a fantastic tool for building robust user interfaces, but a lot of developers find that it has a pretty steep learning curve. The Head First C# approach has been to use Visual Studio as a learning, teaching, and exploration tool, and the improvements that the Microsoft IDE team made to the visual designer made it especially effective for teaching XAML. We decided to have the book dive straight into XAML design and exploration, and have the reader build a video game right in the first chapter:
The trick to really getting over that XAML learning curve turned out to be going back to WinForms development for a few chapters. WinForms is an older technology, but it’s much simpler to understand. This let us lay down a solid foundation of C#, .NET, and object oriented design concepts, which makes XAML a lot easier to learn. It also gives the reader the opportunity to build projects to solve the same problem in both WinForms and Windows Store (or WPF) using XAML. Seeing the same thing done in more than one way is one of the most effective methods for learning programming, and we’re able to take advantage of that many times throughout the book.
I hope you’re as excited about this as we are! If you’re looking to learn C#, whether you’re new to programming or experienced with another language, you should definitely have a look at Head First C#.
We’ve worked with O’Reilly to make the first three chapters available for free as a PDF.
In that second post, I spend a little time talking about some of the reasons that programmers resist great practices like test-driven development. Writing that post reminded me of something that Jenny and I wrote about change in Applied Software Project Management:
Many project managers—especially ones who have a technical background—tend to ignore the fact that their organizations are made up of people who need to be convinced of the importance of a change before they will adopt it. Some of these people will have an emotional or even irrational response to any attempt at change; it could take a sea change in the organization before they agree to it.
Irrational attitudes about software development usually boil down to two basic beliefs. First, people believe that most or all software projects are delivered late and delivered with many bugs, and that this is just a fact of life. Second, they believe that their organization is unique, and that the problems they are experiencing are particular to their organization and have never been seen before in any other organization.
(This second belief may seem odd, considering the many thousands of software organizations around the world that have all used similar tools and techniques to fix very similar problems and make real, lasting improvements. It’s possible that the belief in uniqueness comes from the fact that the software being built truly is unique, in that it has never been built before; it’s not a leap to assume—incorrectly—that the software project and all of itsproblems are therefore also unique to that particular organization.)
Many times, resistance is not irrational at all. Anyone who has been through a change previously—possibly a passing management fad—that didn’t fix the problem (or failed outright) may be resistant to another change. It may seem unfair, but if people in your organization have previously gone through poorly planned changes, it will be harder for you to make changes of your own.
When you are introducing new tools, techniques, or practices in your organization, you may encounter resistance for a number of reasons. By exploring the feelings, fears, and justifications for resisting change that project managers commonly encounter, these reactions can be unraveled and understood.