The best thing I read this weekend was a 1 page article in BusinessWeek. It is titled “The Best Leadership is Good Management (click here). Can you lead and manage at the same time? This reminded me of MBWA (Management By Walking Around). It is a great technique for talking to folks, developing trust, mentoring and guiding, and of course, managing!

What are your thoughts?

Here is some of the research I did to review their backgrounds. While I realize I cannot encompass the full breadth of their experiences, you get the idea…

• Mike Beedle – Technical Background – PhD in Physics and he has published in several areas including object technology, patterns, components, frameworks, software development, programming languages, reusability, workflow, BPR, and Physics.
• Arie van Bennekum – Technical Background – Started his career as a developer and he has a IT education.
• Alistair Cockburn – Technical Background – B.S. and M.S. in Computer Science with a PhD. He has been a hardware designer and research staff member.
• Ward Cunningham – Technical Background – He has also served as Director of R&D at Wyatt Software and as Principle Engineer in the Tektronix Computer Research Laboratory before that.
• Martin Fowler – Technical Background – He started working with software in the early 80′s and in the mid 80′s I started getting interested in the then new world of object-oriented development. I started to specialize in bringing objects to business information systems, first with a couple of companies and then as an independent consultant. In the early days this was using Smalltalk and C++, now it’s Java, C# and Ruby.
• Jim Highsmith – Technical Background – He has held technical and management positions with software, computer hardware, banking and energy companies. He has a B.S. in Electrical Engineering and an M.S. in Management
• Andrew Hunt – Technical Background – Andy has been writing software professionally since the early 80′s across diverse industries such as telecommunications, banking, financial services, utilities, medical imaging, graphic arts, and Internet services.
• Ron Jeffries – Technical Background – Ron has been a systems developer for more years than most of you have been alive, and his teams have built operating systems, compilers, relational database systems, and a wide range of applications.
• Jon Kern – Technical Background – Degree in engineering. Held positions such as Director of QA, Software Architect, etc.
• Brian Marick – Technical Background – B.S. Math and M.S. in Computer Science. Lots of experience as a programmer and tester.
• There are more, but you get the idea…

• Over the last several years managers, directors, and executives have asked me to present empirical evidence that Agile will cost them less money and take less time

This is a great question. I’m interested in data from the community?

• A recent paper (here) published by Microsoft and IBM, showed that practicing TDD versus general unit testing reduced bug density by 40-90%. Reading this paper gave me one data point; bugs are one of the three things listed above that customers hate the most. The question is can bugs be equated to time and money?

This is really insightful and would suggest a renewed focus on eliminating bugs to reduce cost. But the author fails to include which is listed in the white paper is the associated cost of TDD. Here are the costs as noted by the paper “Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD.” Despite the increase in additional development time, TDD is worth it as the costs of fixing issues post-customer launch is very high.

Overall the author of the blog has the right idea, that TDD is the way to go! However, he seems to conflate agile and Test Driven Development. They are two distinct things. One can practice agile and not TDD and vice versa. Now we can debate whether or not you should write unit tests for “private” methods

1. Customer’s change their minds and that is ok – The burden on trying to know every single detail of the customer/market requirements is greatly reduced. I have never worked in an organization where there were enough product managers to do everything that product managers are supposed to do. Having to write complicated and detailed technical requirements up front before development begins was always a huge burden. I hate being on the critical path. With Agile, I don’t have to know every detail up front, I can accept the fact that the customer can see the product and change their mind.
2. Estimating work is much better in Agile – I love the concept of story points and velocity. It let’s the team achieve a natural capacity and work speed rather than trying to work overtime to achieve an unrealistic deadline because the product manager took too long writing the requirements.
3. Team work is really emphasized – This is the real strength of Agile. Teams work together, teams communicate daily, teams communicate verbally. It just works well rather than just trying to throw “artifacts” over the fence to the development team.

I used to work for a fellow by the name of Alex Bloom (now CEO of Handango) and he told me one time that “Results matter”. I know this seem quite obvious, but often times folks jump into a situation without thinking of they can truly deliver results. It has to be tangible and deliver business value. So think about this before you accept your next project. No one jumps into a pool before checking to see if there is any water.

Another piece of advice I’d like to share with folks is “Always be prepared”. Everytime I walk into a meeting I want to know my audience and be the most knowledgable person in the room. Everytime I ask a question, I want to have a good handle on the answer before I ask it. Everytime I prepare a presentation I want to know my audience and anticipate their questions. I always get a warm fuzzy feeling when a person in the audience asks a question during a presentation and I respond with “Great Question, I’ve answered it on the next slide”.

But one step into reality has taught me that theory and practice are not quite one and the same. In reality, I’ve worked at companies where HR focused strictly on dealing with compensation and was nothing more than a blunt tool to be used when costs needed to be cut. I’ve also worked at one place where HR reported into the CFO. I thought to myself what message does that send to folks?

So I got to thinking, why is there such a disparity between what is taught in the classroom and the reality that I see. Then the answer hit me! The professors that teach these courses are rarely industry HR veterans, rather they are PhDs who get “real world” experience when they get hired as consultants to fix companies problems. So essentially I’m getting a consultant’s perspective. How many of us have ever had a great experience with a consultant?

The purpose of these ads is not to answer the three questions she noted:

1. Where is the home?
2. Is the home big enough for my family?
   
3. What’s the asking price?

What if the ad had all those things, but didn’t have a picture. I’m willing to bet that fewer people would call than if there was picture, but the ad didn’t answer all 3 of those questions. Buying a home is an emotional decision. People like to see the home and ask themselves “Can I see myself living there?”. If the answer is “Yes” then the person will likely pick up the phone and call.

So at the end of the day, I disagree…the purpose of the ad is to get you to talk to the real estate agent. The ad serves its purpose and is designed to elicit an emotional response. It reminds me that the purpose of a resume to not to get you the job, but rather to get you the interview.

Any thoughts?

This is probably the reason that Product Management location in company org chart varies widely from company to company. In technology dominated company (i.e. where the technology team dominates mindshare), the Product Management team falls under the VP of Engineering or the CTO, etc. In this type of org, they are primarily focused on supporting the needs of engineering such as requirements, etc.

In other companies, Product Management falls under the VP of marketing where they take a more market centric view. This involves product marketing assistance, market research, and competitive analysis. In this org, you see more market requirements than product requirements.

Pragmatic Marketing has a whole eBook on Product Management here.

The challenges:

• Setting Expectations – With agile your roadmap is very detailed during the current sprint and then becomes less so as you start to prioritize your product backlog. As for putting when items will be delivered, I would recommend only putting a timef rame down for the current sprint stories and then just putting the rest down in a priority. If executives don’t like the fact that there is no time frame for that feature they want by the end of the year, work to educate them that scrum is the not the right process to guarantee delivery of a feature many sprints from now. Careful positioning of the roadmap is critical in the context of SCRUM.
• Crafting – A roadmap is an excellent communication tool for the vision of product management. Priorities, product themes, and overall initiatives can be communicated along with their value to the market. It must be updated often, preferably at the end of the every sprint as you learn more and have begun planning for the next sprint. An updated roadmap presentation including goals for the current sprint and how that fits into the remaining work for that particular feature or product. How many times have you had to scurry to update your presentation when you get an email from an exec who wants an update? If you updated it at the end of every sprint, it would be an easy request to meet.
• Time – Many times we are so busy being product owners and getting our heads around all of the incoming stories that we can’t even begin to think about the market. Take time to get this done. Step away from the tactical a little bit…your team will appreciate it in the long run.

What are your thoughts?

• Social Media is Interaction, Engagement, Conversation, Relationships, not about Tools!
• Recommenders and Purchasers are consumers with expectations
• Social media allows an instantaneous response to serious brand issues. You have to live with the bad parts of social media, but you can choose to live with the good.
• Private twitter accounts? I didn’t know that existed! Yammer is similar.