Agile2011: Bob Martin—Clean Coders, Purity of Essence, and Ten Years of the Manifesto
Podcast
Bob Martin talks about his book and videocasts of his work getting the code in clean and right. He expands on his discussion of craftsmanship and the habits of coders that code clean. He also discusses the ten years of the manifesto and the growth of agile. |
||
Heard and Valued: Three Short and Useful Bits of Advice for Improving Your Leadership Skills Yogi Berra famously said, “You can observe a lot just by watching.” In this article, Payson shares some of what he’s learned about leadership just by listening. Learn how transparency and iterative improvement can maximize the results of great leadership. |
||
Dear Customer: The Truth about IT Projects In this personal and direct letter to customers, Allan Kelly pulls no punches and explains why IT projects don't always pan out for all of the parties involved. |
||
On Beauty, Quality, and Relativity The saying “beauty is in the eye of the beholder” rings true whether you’re staring at a centuries-old painting, listening to a busker’s music reflect off the tiles in a subway station, or testing software. It’s one thing to evaluate quality, but how do we evaluate how we evaluate quality? |
||
Paper versus Electronic Dashboards: Goals and Values It's almost a matter of dogma that, for agile teams, low tech project tracking tools and artifacts are superior to electronic ones. The usual reason you might hear for preferring a physical task board to an electronic issue system are are that a physical task board is more visible and encourages communication and collaboration. I appreciate this, and have seen it, but I've also seen teams do well with issue tracking systems. From time to time I see a discussion of this "physical versus electronic tracking" issue and I find myself frustrated by it, but not sure why. |
||
We're Not "Special" Often, when I comment on someone's blog post or respond to a tweet with a story about how my team succeeded with some practice, someone replies, "Yeah, but your team is special." I interpret this as meaning, "You're a presenter and book author. You must be an expert, so of course your team can do anything." This frustrates the heck out of me. |
||
Book Review: Kanban: Successful Evolutionary Change for Your Technology Business I've worked with Scrum for a while, having gotten my CSM certification in 2005, and I've spent time both before and after that trying to learn what I could about Scrum, agile, and Lean, both in the context of software and out side of it. After absorbing bits of information on Kanban informally, I decided that to was time to read a book on it. I read David Anderson's book Kanban: Successful Evolutionary Change for Your Technology Business. |
||
Management Myth #2: Only ‘The Expert’ Can Perform This Work How many times have you seen this in your projects: You need something specific done such as a new database, or a specific user interface designed, or you need a release engineer, or a user interface designer, or a part of the system tested and the normal person who does that work is not available? What happens on your project? Does it wait until The Expert is available? |
||
We Are Not Alone Do you know colleagues who box themselves into the corner regularly? Getting lost is not the problem; coping with having gotten lost is the problem. Markus Gärtner explains how to notice that you are stuck, how to ask for help, and who you should be asking. |
||
Integrating Games to Change Behaviors, Part 2 Training people and introducing new ideas requires more than just clear, factual explanations or theorems. Brian Bozzuto explores how games, simulations, and other exercises play an instrumental role in helping people be comfortable enough with new ideas that they choose to put them into practice. |
Pages
Upcoming Events
Apr 27 |
STAREAST Software Testing Conference in Orlando & Online |
Jun 08 |
AI Con USA An Intelligence-Driven Future |
Sep 21 |
STARWEST Software Testing Conference in Anaheim & Online |