PLAN FOR IMPROVISATION

A friend contacted me for advice on how to find and hire a good software developer. The problem is that he is a non-technical manager and only needs one person. I commented that he wasn't going to be able to mentor this person so he needs to find somebody he can trust and who can work without supervision. Here was my quick formula of how to find the right person. I thought it was worth sharing: They will need to have a current blog discussing what they is playing with technically at the time. At a minimum they will need a good LinkedIn profile. In their profile (and resume) it should focus on accomplishments - solving problems for customers, not just technology they know. Good, successful software developers are all about solving customer and business problems rather than just technical ones. They know that straightforward technical problems are solved in lower cost labor markets (i.e. India). Next, they will need a GitHub account and have some projects up there. This s...

photo credit: herval I got an advertisement for a workshop about how to develop SaaS products. The title was, "Silly Agility--The Myth of the SaaS Agile Product Manager". Here is some of the text of the advertisement: "XP was an attempt to replace waterfall development approaches with something new...[References a generic project]...objectively analyzed, [this project] was a failure; after five years the product wasn't completed and the development effort was terminated." My first though is that this is a sensational advertisement to get bodies in the door of a poorly conceived of workshop. My second thought is that this is damaging to the career of person advertising it. Factually speaking: When the Agile principals were defined, it wasn't an exercise in creating newness for its own sake. Another objection, is that a "Agile" project that drags on and on then finally fails isn't using Agile principals in the first place. If its goi...

Anybody who has been to our office knows I am an Android fan. My prediction is that the Android platform will end up with a much, much larger install base than iPhone OS. Originally, I felt this way because you can get a Android phone on every carrier for a lower cost than the iPhone - many of them are now free with a contract. This is good enough, but I have a new insight. The Android OS does a great job of directing your attention to highly important information. As such, its easier for new users to pick up and for busy people to use. How can this be? You should argue that the the Android OS so similar to the iPhone OS. You are right. However, it comes down to usability. The majority of people out there won't explore their device to find information. They just want the phone to do the work for them. If it doesn't smack them in the head it might as well not exist. Android has two crucial features that make it a helper more than just a smart phone. First, Android b...

In Making it Big in Software , Sam Lightstone has the ambitious task of giving you "all the information you need to jumpstart your software career: the best ways to get hired, move up, and blaze your way to the top!". It's an ambitious claim. I read the introduction that stated the book would give me the skills to get started and the skills to be a visionary and leader. Honestly, this seemed too broad a topic to cover in one book - even a 400+ page one. However, I decided to push on and evaluate if the book was a good read for our software apprentices. I ended up reading the whole book cover to cover. In my opinion the book succeeds in its mission. The book made me recall many of the mentoring discussions and off hand comments I have heard throughout my career from successful people. I enjoyed Lightstone's candor and his frank advice. Some ideas are big - if you want to be successful don't be a "cookie cutter" developer. Some are simple - e...

In Succeeding with Agile , Mike Cohn gives organizations a handbook for how to succeed using Agile practices and principals. If you are picking up this book, keep in mind that he assumes you have some experience with Agile before you begin. He starts the book by presenting some agile adoption patterns then discusses how and why those patterns are resisted by individuals within the organization. Next he spends a number of chapters explaining new roles and how existing ones change in an organization after agile practices are adopted. I particularly like when he describes a practice, or role, in detail; then steps back to discuss how it will affect each role in an organization and how to overcome resistance. The remainder of the book covers additional topics about agile adoption that aren't large enough to cover a chapter themselves. By the time you get to chapter 20 he is discussing "Human Resources, Facilities, and the PMO." I especially liked the end, "You're ...

photo credit: victoriapeckham We have reached the most critical point on a project I'm working on. After a few months we think we know enough about the domain and application to build a product road map that will take us to the first public release. The proof of concept is complete. The design team has created a remarkable, genera changing product. Additionally, the system is designed around real users we have been able to talk to and get feedback from. We have put together an unbelievably good development team and built a backlog of stories with estimates. We have been here before. Putting together a design and backlog of stories is something we have done countless times... The easy part is over. Now the hard part begins. Our research and user feedback tells us we have multiple potentialcustomer groups we can build the system for. On one hand this is great news. We have a number of potential markets to choose from. On the other, we don't have an infinite amount of ...

I often meet peers who ask what Agile practices Pathfinder utilizes. From the outside we pretty much use all of XP’s practices. However, if you take a deeper look we do some things a little differently (especially how to use and calculate velocity). For Agile purists, one might question if we are really doing Agile. They would claim changing practices is slippery slope. For example, a team will start altering Agile practices to create a “home grown” version only to find they are using only some practices and not seeing the benefits they hoped for. I feel questioning if we are really doing Agile based on exactly what practices one uses shows how familiar and mature one is with Agile principals. A better question would be to ask why we changed them. Agile is not meant to be a methodology, but a set of principals. In my opinion, using things like Velocity to estimate whether a team will finish a project within a certain time frame is a hack at best. This always was hard to expl...