Why Prototype and Test?

I know that posts about motorcycles were promised. Unfortunately, my personal backlog has not had blog articles ranked near the top. Things have gotten a little easier so here is the first article on custom motorcycles.

My brother, Greg, and I have been working on a little Kawasaki bobber for some time now and it is coming along pretty well. In looking for a feature that would set it apart from the bikes of other builders we came upon the idea of creating a tank that would hold all of the electrical components including the voltage regulator, rectifier, battery, and all of the associated wiring. Greg had access to a bunch of old fire extinguishers so we picked one and got started.

The idea was to cut the extinguisher to the right length, build a bracket that would hold all three components and their wiring  then mount the bracket in the tank and then in the rigid frame. All wiring would feed out the top.

We formed the bracket up; made sure the battery fit and made mounts for the voltage regulator and rectifier. Once we could mount all of the components we went about making it perfect. Corners were rounded, welds finished and ground, the outside of the bracket sanded down in preparation for paint. We finally mounted all of the parts together and went to figure out how to mount the finished assemble and the tank and the problem became obvious. We hadn’t accounted for the tank getting smaller at the top, it wouldn’t work. No amount of bending, grinding, cutting or drilling was going to fix the thing. It was time to start over.

The second go round went quickly and we came out with a highly-functional part that met all of our acceptance criteria but it wasn’t ready for paint.

The sequence of photos shows the finished bracket and how it fits inside the tank:

Here is the finished product. You can see the first failed attempt in the background.

As a post script to this little tale we learned one even tougher lesson. It turns out the battery we worked so hard to hide isn’t actually big enough to run the bike. Maybe we should have tested that out first. Now we are looking for a battery that size with enough juice to do the job.

How are you helping the team?

Recently I noticed a disturbing trend on one of my Scrum teams. The senior developer, Bart, who is by design the technical leader and mentor, had begun giving updates that sounded about like this; “yesterday, no scrum related work, today, no scrum related work, no blocking.”

Unfortunately, the team was listening and was in the process of responding with progressively less meaningful updates from day-to-day.

We have all heard the relentless “no blocking” statement but these updates are particularly troubling. Here’s why:

• It’s incredibly vague
• The only thing it really says is that he is doing something the team didn't agree to
• Because of Bart’s position on the team it is a dangerous and potentially damaging to overall team communication and productivity, this becomes the model behavior if allowed to continue
• There are customers in the room with very poor poker faces, it’s obvious they are confused and worried that the team lead isn’t working on Sprint commitments

After four consecutive days of this it was clear that it had to be addressed and as Scrum Master this falls right to me for immediate action. 

I’m a believer in the concept of “criticize in private, praise in public” so I grabbed Bart for a quiet hallway chat ten minutes prior to stand-up to make sure that there won’t be anymore of this type of “update.” I made no bones about the negative impact and made it clear that he must provide an example for all to mimic. The non-update update is not acceptable. In our discussion I made the above points and really didn’t get any pushback at all.

What I did get was an explanation of a change in his responsibilities that I wasn’t aware of. His boss has directed him to serve in more of a leadership role and technical mentor role and commit to significantly less coding each sprint. Ok, great. How does this impact his responsibilities to the team?

Obviously, he will have fewer stories and tasks that will require updates during stand-up. However, the team, of which he is a part, still has to make its commitments.

After some discussion we arrived at the following conclusion; rather than providing updates on tasks etc. he will provide specifics on what he did and will be doing to help the team meet every commitment. 

Enough time remained for him to spend some time thinking from this perspective prior to stand-up. Bart went first. Response to his retooled update was immediate. The quality and value of every update went back to where it was before the change.

Lessons Learned

• Don’t wait to address a performance issue, end it as soon as you identify it 
• Communication is key, we could have addressed the subtle role change proactively had it been communicated
• Everyone on the team is responsible for the team meeting or not meeting its goals
• People in leadership positions lead, good or bad, whether they intend to or not

Adopting Product Mangement

I found this question on one of the Ask a Good Product Manager blog. If you are interested in Product Mangement this is a good one to keep up on.

I thought it would be a good fit here since the adoption can be a challenge. I am only posting the question and my response to it but the thread is definitely worth the read.

Question: How do I start a product management role within a company that has never had one?
I’ve been hired by a software company to be their first Product Manager. There is no product manager today, and each part of the job is done either by engineers, sales, marketing, QA, etc.

What would be the first steps to establish the product manager role within the company and bring value while learning products and context?

My Response:
There are many excellent suggestions. I think Derek and Nishant are particularly on target.

Since this is your company’s first effort at formal Product Management you might also choose to take a slightly different perspective for a while as you drive the cultural change that must come with Product Management.

Try this:

You, the product manager and the services you provide are the product.

Just like you would for any product find out what your customers need and move to fill that need. Act as the proxy for your customers. Derek lists a number of roles that will have expectations/assumptions of what you are or should be doing. I would meet with each and identify in explicit terms what those expectations and assumptions are. Uncover what it is that they think about your position. Your master discovery skills will come in handy.

Make sure you identify who in the company drove the PM decision and engage him or her as an ally. It is likely that this person is very senior and very capable of helping to drive the needed changes. They are likely to have substantial political capital invested as well and need you to succeed, leverage this.

Once you have done your market research you can pull it together, vet it against something like the Pragmatic Framework. Put together a vision and a specific task set that makes sense for the company, your stakeholders and to you as a Product Manager. Do make sure you lean heavily on the strategic end of the spectrum; the tactical will come to you.

Doing this leg work will give you tremendous credibility and you will have a level of buy-in that makes it easy for your co-workers to understand and accept.

Just like the products you manage be prepared to make changes to the Product Management Product as you learn and your company begins to adopt.

What This is About

I am an experieinced software Product Manager and very involved in the Agile/Scrum software world. I have a number of certifications from the Scrum Alliance and am always looking for ways to get better at coaching teams I work with to be more productive and build better software.

Here's the scoop on what I am going to be writing about; my brother and I build custom motorcycles in our spare time (what there is of it) and I am going to compare that process to that of building software. I think this is a valid comparision as the two processes have many commonalities. Building a bikes(scooters) and software both:

• Vision is key and drives the process
• There are many unknowns at each step of a process
• The people that build them rely on learning to get better each time they do it
• There are multiple ways to do pretty much everything
• Projects are never the same

Every so often something will happen at work that I will write about it as well, it may even have to do with software development.

My perspective on software development is very end-user/product focused which will surely show through.

Feel free to send along any questions you might have, I am happy to try and answer them or at least try to point you in the right direction.