Tweet this: The Lean Startup by @EricRies : Book Review @PGopalan http://wp.me/pXBON-2Vg #lean #startup #innovation #prodmgmt

by Prabhakar Gopalan

The Lean Startup by Eric Ries hit the digital book stands a couple of weeks ago.  Eric Ries coined the term Lean Startup and is a recognized leader of the lean movement.  The book is an easy read and an excellent introduction to the concept of applying lean principles to startups.

The book illustrates with many examples, anecdotes and the author’s personal experience at IMVU, an internet company that makes and sells virtual goods (think avatars for IMs), on how lean startups work.  The book is organized into three parts – Vision, Steer and Accelerate.

The first part talks about how startups differ from established businesses and how to approach building a product through experiments.  The second part discusses how to measure and pivot or persevere and the third part discusses how to accelerate the processes in the three startup phases – Build – Measure and Learn.

The crux of the book is about startups experimenting and learning in an iterative fashion with the flexibility to change course based on the learning – the author calls validated learning.  To the author, the product is an experiment.  I couldn’t agree more on that very fundamental idea.  I think there is a lesson for most product managers right there.  To quote from the chapter Learn in the first section of the book:

In the Lean Startup model, we are rehabilitating learning with a concept I call validated learning. Validated learning is not after-the-fact rationalization or a good story designed to hide failure. It is a rigorous method for demonstrating progress when one is embedded in the soil of extreme uncertainty in which startups grow. Validated learning is the process of demonstrating empirically that a team has discovered valuable truths about a startup’s present and future business prospects. It is more concrete, more accurate, and faster than market forecasting or classical business planning. It is the principal antidote to the lethal problem of achieving failure: successfully executing a plan that leads nowhere.
Ries, Eric (2011-09-13). The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses (p. 38). Crown Business.

Some good content

The chapter on innovation accounting is highly instructive for the serious student in understanding lean and startup.   He clarifies the distinction between what he terms vanity metrics and actionable metrics.  Right after I had read the pages on vanity metrics, I was reviewing a presentation which among other things concluded that HTML5 jobs were more in number than any other information technology jobs based on the number of search results for HTML5 over other technologies (e.g. Java, .NET etc) at a leading job site.  It is shocking to see the innumeracy of managers and how data gets presented and interpreted incorrectly.  To those, Eric Ries’ offers a great lesson.

Another nice chapter in the book is on ‘pivot or persevere’.   Using the story of @2gov (now Votizen, a social media lobbying platform) he explains how pivoting is an important step in the startup journey.  This particular company had to pivot multiple times, each time in shorter duration than previous to learn and change course.  The story gives a sense of how flexible and real time learning has to be for a startup to finally get its business model right.

The chapter on batch size is yet another  good one.  Even for those unfamiliar with lean, this chapter would be an easy sell.  It starts with a simple example on processing envelopes, goes on to explain how Toyota out competed American manufacturers and his own story at IMVU.  If we stretch the concept behind this a little bit, we can start questioning the whole notion of economies of scale and their practical use and limitation.  This can turn many years of conventional Western thinking upside down.

But not everything is great

Some disappointments in the book: The book starts with a lot of promise about how lean can be applied to organizations of all kinds small and big, for profit and non-profit and software and non-software companies.  However, as you progress along, you get the impression that most of the stories discussed are about the author’s own experience at IMVU.  That by itself may be instructional, but not sufficient.  If you are at a big company, how do you apply lean startup principles (maybe a topic for the next book?).

In fact, in one section he spends a short paragraph on Organizational Superpowers – how one young employee gets the lean startup principles but is unable to convince the VPs and senior managers at his organization.  And abruptly shifts gears to another topic leaving you to wonder what you should do about it.

The author also has something against white boarding.  He criticizes “white board strategizing” as many as 10 times in the book (it’s a good thing you can count occurrences of words in your Kindle!)  For people that are visual, the white board is more than a strategy tool.  It is a way to express and exchange ideas, a blessing.

Lastly, the author, while espousing the case for scientific method and management throughout, is ambiguous on his position vis-a-vis Taylorism in the book’s epilogue section.   Taylorism is the anti-thesis of experimentation and learning.  It is revisionist history to explain how Taylor has been misunderstood over time.  Reality is, it was a reductionist time-motion study that has significantly contributed to how Western management has fallen trap to linear thinking models.  (For more on how Taylorism driven strategy is dangerous, please check out my presentation on the need for experimentation as strategy at ProductCamp Austin).

I’d recommend this book as a must on your bookshelf.  It is a primer for understanding the lean process in startup settings.

- Prabhakar

Tweet this: The Lean Startup by @EricRies : Book Review @PGopalan http://wp.me/pXBON-2Vg #lean #startup #innovation #prodmgmt

Related posts:

1. Book Review: The Product Manager’s Desk Reference
2. Book Review: Take Charge Product Management
3. Book Review: Expert Product Management
4. Not a Book Review: Software Product Management

Tweet this: It’s that Product Owner (er…Backlog Manager) debate again http://wp.me/pXBON-2U3 #prodmgmt #agile

By Saeed Khan

There was a vibrant discussion on the Twitter Product Management Talk yesterday. The topic, a common one for Product Management types – the roles of Product Manager and Product Owner.

The discussion was lead by John Peltier who writes on Agile Product Management. Geoff Anderson who also participated, wrote a post on his blog – Tralfaz - about an exchange he and I had.

Geoff wrote about some of the issues he’s seen when companies add the Product Owner role.

These issues can be summarized as:

• Putting very junior people in as Product Owners.  How junior? They “almost need to ask permission to use the bathroom”.
• Organizational problems with Product Owners being part of Engineering. i.e. Putting the fox in charge of the henhouse.
• The required frequency of communication needed between a Product Owner and Product Manager.

Here’s my take on these topics.

What is the right level of experience for Product Owners (or as I’ve advocated – Backlog Managers)

This one is easy. Put an inexperienced person in any role, and prepare to be underwhelmed. There is a trend to create junior “transition” titles — e.g. Associate Product Manager, Technical Product Manager — for people who are entering Product Management. Now there is nothing wrong with these types of titles, but the problems occur when there is a mismatch between the skills and the responsibilities for those roles.

Given the responsibilities of a Backlog Manager, such as ensuring the Eng teams stay focused on the right functionality, facilitating information flow, helping resolve problems as they are encountered, providing technical guidance when needed etc.  a junior person is the last person you’d want in this role.

The role needs a strong technical background, good judgement and decision making abilities, a persuasive attitude , and good communication skills. Doesn’t sound like a junior person to me. IMHO, the best person for this role, particularly in a company with a strong technical team, is an experienced ex-Engineer who wants to move into Product Management.

Where should the Backlog Manager reside

Without question, this role DOES NOT belong in Engineering. Plain and simple, it should be part of the Product Management organization, seated along with the corresponding Product Managers and Product Marketers who work on the same product.

Being part of the same team and sitting with them leads to the next point.

What is the right communication frequency

I’m always amazed at how much of a sticking point this can become in online discussions. What is the right frequency of communication between a Product Manager and a Backlog Manager? Well it’s quite simply the right frequency of communication. i.e. whatever is required.

Sometimes it could be several times in a day. Other times it could be a few times a week. Other times, it could be once per week or even less. The reality is that there is always ebb and flow with information demand. But the question is how mature is the Engineering team and what kinds of day-to-day decisions are they making? Immature teams need constant care and feeding. Mature teams with experienced development management can work without daily guidance.

I personally have worked with remote teams (e.g. team is in India with me in North America) and aside from a weekly synchup call, other communications were primarily handled via email or if needed, a mid week phone call. And guess what, those teams delivered great products and didn’t lose their way because of any lack of communication.

So in short, what can companies do to succeed when implementing a Backlog Manager (or Product Owner)?

Get the right people, with the right level of experience, in the right organizational model and communicating the right amount and everything will work out fine. Easy!

Saeed

Tweet this: It’s that Product Owner (er…Backlog Manager) debate again http://wp.me/pXBON-2U3 #prodmgmt #agile

Related posts:

1. Good Bye “Product Owner”, Hello “Backlog Manager”
2. The Scrum Title “Product Owner” must die!
3. A new (and better) definition for Product Owner
4. Why the “Backlog Manager” fits best for Scrum focused ISVs

by Saeed Khan

I’ve written a lot lately about the dissonance in the way Scrum defines the “Product Owner” role and responsibilities and the reality of what occurs in many companies, particularly Independent Software Vendors (ISVs).

These posts included:

• The Scrum Title “Product Owner” must die!
• A new (and better) definition of Product Owner
• Goodbye “Product Owner”, Hello “Backlog Manager”

John Peltier, at the Product Owner Vision blog, took note of these posts, and wrote one on topic as well. His post is entitled:

• Where “Product Owner” as “Backlog Manager” fits best

It’s a good post which you should read in it’s entirety. John discusses some differences between Scrum used custom software projects vs. ISVs.

The focus of all my writing on Scrum/Agile has always been on Scrum in ISVs and the organizational structures into which Scrum (a software development methodology) must play. Yes, Scrum is not an island unto itself. It must fit into an existing organization that DOESN’T view the Scrum team as the center of all activities.

John presents the following diagram showing where he sees the “Backlog Manager” as fitting best.

i.e. for custom projects – the use of “Product Owner” fits best, but in ISVs, the Backlog Manager fits best AFTER the first release (i.e. after release 1.0) of a product.

John’s reasons for this split in the ISV column are summarized (and paraphrased) below. Read his post for the full details:

1. For and ISV, if a PM also acts as a PO, the PO role can occupy him/her to the point that it takes away from outward, more forward looking market sensing and requirement gathering activities
2. Thus the role can be offloaded to someone else (e.g. a Technical PM), but only after the product’s initial release to market
3. This is because, for that initial release,  the PM will need to spend significant time up front understanding the market, market problems, defining a vision, requirements etc. and then spending many months working with development team to bring that initial release to fruition
4. Part of those months with development are spent performing backlog management, but the key for the PM is to have a clear vision of the product and ensure that first release is built correctly. i.e. the Scrum team needs first hand information from the PM vs. second hand information from an intermediary “backlog manager”.
5. After version 1.0 of a new product is released, with the vision, business case etc. established, the PM, “looking for additional market segments and business opportunities” etc. and thus a separation of “responsibility between a Product Manager and Product Owner makes sense.”

Why I disagree with John

Not to pick on John as I think he did a great job in his post in trying to reason through the roles and scenarios, but I do have to disagree with John’s conclusion that the best fit for the Backlog Manager ROLE in ISVs excludes the v1.0 release of products.

1. Research is not a solitary process

First let me say that John’s description of the basic process of researching, defining and building a new product is fundamentally correct.

It doesn’t matter whether the company uses Agile/Scrum/Waterfall or other methodology. A fair bit of up front research and market/customer/prospect validation is needed to identify a new product opportunity. But, in my experience over many new products, and I’d say as a best practice, this work is not, and should not, be done in isolation by a lone PM or even a small PM team. It must include key members of the Development (and ideally Product Marketing) organization.

A major goal of the initial research is developing a common understanding of the market opportunity, and this cannot be done by excluding key team members. Conveying the findings and getting full buy-in on the results of weeks (or months) of external research is very difficult.

By including members of the development team (even 1 or 2 people if your company is small), in a number of customer/prospect/partner meetings and discussions, not only can a joint vision of the problem space be developed early on, but that first hand exposure helps ensure Development buy-in when solutions are being proposed and defined.

2. The first release is not that different from other releases

John’s view of the first (v1.0) release, that it is significantly different from successive releases (e.g. 1.1, 2.0 etc.) and thus requires different focus from the PM (team) does not change the need or scope of “backlog management”.

If a clear vision of the product-to-be is understood by the team, the sprint planning, story definition and backlog prioritization are not different than in any other release. Perhaps there is more oversight needed to get early development efforts right, but that’s true regardless of whether the methodology is Agile or not.

i.e. The “Backlog Manager” is simply a formal definition of the interface role that is needed in a Scrum environment. The vision, business context etc. are still there — provided by Product Management — but the tactical activities specific to Scrum processes are defined in the Backlog Manager role.

3. The tactical vs. strategic balance is always an issue for (understaffed) Product Management teams

This problem that John describes is very real, but is not specific to Agile or Scrum. Understaffed PM teams are rampant across high-technology companies. Far too many companies view “the Product Manager” as the lone individual at the center of the storm.  No other team — whether marketing, sales, engineering, finance etc. — is viewed this way. If Product Management is so strategic, staff it for success.

If you believe that Scrum requires a dedicated role to work with the Scrum team to give them business context, then add that headcount to your plan. Don’t over burden a single individual with that responsibility. It’s a recipe for failure — or perhaps mediocrity at best.

In Summary

I agree with John that for custom software development, a “Product Owner” can be the right term to use given the 1:1 relationship between the (solitary) customer (in most cases) and the Scrum team.  But for ISVs, even in small startups, the reality is that a very different organizational model exists. They key need that the Scrum processes impose and that must be filled is that of backlog grooming, sprint/backlog management and the communication/facilitation required during the development cycle.

This new, tactical ROLE is not about “Product Ownership” but about facilitating product development over successive releases and ensuring appropriate business context is inserted into that process. It may be part of a larger job description or a dedicated role. But, in short, whether as a v1.0 release, or any subsequent release, that ROLE is “Backlog Manager”.

Saeed

Tweet this: Why the “Backlog Manager” fits best for Scrum focused ISVs http://wp.me/pXBON-2KZ #prodmgmt #agile #scrum

Related posts:

1. That Product Owner (er…Backlog Manager) debate again….
2. Good Bye “Product Owner”, Hello “Backlog Manager”
3. Agile/Scrum Software Development and Product Management
4. Agile/Scrum and Product Management (part 3a)

You’ve just introduced your latest product release, introduced a new product or capability or launched the product. Now What? What about a retrospective? While product management and product marketing professionals often see engineering and development using retrospectives, how can you use this method to look back at what happened, while positively influencing the future?

What is a Retrospective?
A retrospective thrives in organizations using SCRUM methods and is a meeting where the team discusses the Sprint that just concluded and determines what could change that might improve the next Sprint.

In SCRUM terminology, anything that affects how the team builds software is open for debate. This could include processes, practices, communication, collaboration, environment, artifacts and tools. I believe and have experienced that a retrospective for product management and product marketing will provide clarity to future activities. Why?

Why a Retrospective?
Retrospectives bring insight and clarity. While it originated to bring development teams together, product management and product marketing need similar insight and collaborative review. While we have many one-on-one conversations and numerous meetings with stakeholders, product management and product marketing benefit from looking back to improve what’s ahead. Using retrospectives, product professionals will have insight into:

• What’s happened and what’s currently happening?
• What current activities have made the most impact?
• What processes and best practices have worked and what needs improvement?
• How is communication and what can be better?

Product Management and Product Marketing contribute and bring clarity to:

• What’s changed or influencing our market?
• What stories can you tell us that will validate where we are going?
• What’s the competition doing and will it influence what’s planned?
• Has anything shifted or influenced our strategy?
• What’s the status of the product roadmap?
• How are customer using our products and what have they experienced?
• What’s been developed or delivered from the product marketing roadmap and how will it influence the channel?
• What’s the timing or status of the next product launch?
• How does our positioning resonate with customers and non-customers?
• What has product management learned since our last retrospective?
• What has product marketing experienced since we last met?

Implementing a Retrospective
At best, retrospectives are a great tool for infusing continuous improvement and collaboration, Depending on who you collaborate with most often, and the focus and role of your position, the following five areas should be considered when leading a retrospective.

• Goals – in advance of the meeting, let everyone know about the focus of the retrospective, what you like to achieve and ask for input, topics and invite other to bring their accomplishments and war stories.
• Set the Stage -let everyone know you’re hear to share, learn, listen and provide constructive feedback, as well as receive it. Look for ways to improve relationships.
• Gather Data – before you get together, prepare current information and data that would be relevant. Ask other to share 2-3 minutes worth of information.
• Generate Insight - with discussions flowing, start asking the why questions that will generate insight, support and consensus
• Decide What to Do – while this isn’t a planning meeting, capture the information, validation and feedback. If you have access to a coach or facilitor, ask them to lead the session, so you can really engage and not worry about meeting management.

To stage better product delivery and introduction, I believe you should try a retrospective. If you’ve tried a retrospective, please share your experience. If you haven’t experienced a product management or product marketing led retrospective, give it a try and let us all know how it goes.

If you like the post, please share it via LinkedIn and Twitter – New post and idea, “the Product Management Retrospective” http://wp.me/pXBON-2DO #prodmgmt #prodmktg #agile #leadership

Related posts:

1. Agile/Scrum Software Development and Product Management part 2
2. Gilbert and Sullivan present: The High-Tech Product Manager
3. Product Management: Beware of Flying Monkeys
4. Agile/Scrum Software Development and Product Management

by Saeed Khan

Last week’s post entitled “The Scrum Title ‘Product Owner’ must die!“  on changes to the Scrum “Product Owner” title and responsibilities drew a lot of comments and feedback. Some agreed, some disagreed, but clearly there is much room for improvement in how that role is defined and implemented.

And thus the genesis of this post. It’s time to provide a better, more applicable and less convoluted description of the “Product Owner” role so that companies who are implementing Scrum can do so with far less confusion and tumult in their organizations.

One reader, Rohan, left a great comment that is worth repeating and discussing.

Given that the role of Product Owner is a requirement in Scrum, and given that the name “Product Owner” is well established there, I think that “must die” is admirable but futile. I think we have a much better chance of success if we focus on educating people that Product Owner is a role, not a job title, to be filled by someone with a real job title like (in many/most cases) Technical Product Manager. Then the existence of the term “Product Owner” can be limited to members of the Scrum team, and the rest of the world can be spared. That is, I don’t think we can kill the term, but we can quarantine it.

Well said Rohan.  I must say that the “must die!” title of the previous post had a lot to do with having a provocative title to draw readers. I think it worked. And while it’s true that it would be difficult to displace the name “Product Owner”, it doesn’t hurt to get people thinking about it. But I have to agree that quarantining it is much more likely to happen. So, let’s get started.

The problems with the current definition

To review, I saw two problems with the “Product Owner” title and description. In short they were the title and the description.  But seriously…

1. The name “Product Owner” and particularly the word “Owner” causes confusion when Scrum in implemented. Does anyone actually “own” the product? And if so, is that person (most likely someone very senior) going to spend time with the Scrum team, in daily standups etc.? No.The name derives from the Engineering-out view of the company. i.e. Engineers want “one throat to choke” when it comes to business requirements and ensuring their work aligned with “the business” side of the house. i.e. from their perspective, that person is the owner of the product, regardless of whether that is the case in the company at large.
2. The responsibilities of the “Product Owner” (as defined by Scrum and it’s advocates) are a convolution of business and technical, strategic and tactical responsibilities, that in reality are never seen in a single individual role. There needs to be a distinction made between what the “Product Owner” actually does and what he/she represents.

BTW, in researching what others had written on this topic, I came across this series of posts by Luke Hohmann on why prioritizing backlog by ROI doesn’t make sense. Luke is no outsider when it comes to Agile and Scrum and this series of articles is worth reading.

Constraints for a new defintion

So, back to the topic at hand. Given the issues with the Product Owner definition, how can it be changed to be better and more clearly defined and applied within environments? Let’s look at some of the constraints that the definition must fit into.

1. It must cover both internal IT projects and commercial products, and also be relevant to applications built for specific customers by consultants.
2. It must focus on the need for ongoing business input into the development process
3. It doesn’t define a new role that duplicates existing roles.
4. It must adhere to the Scrum requirement of a “single throat to choke”
5. It must be a job that can actually be done by one person. No superheroes required

The new (and better) defintion

Given these criteria, here’s a proposed NEW and (IMHO) better definition of Product Owner. To compare and contrast, read the Jeff Sutherland definition in my previous article.

1. It’s a Role not a Title
The “Product Owner” is a role (and not a title) aimed at addressing a key problem that has historically plagued software development projects: that being the gap between business priorities and the work executed by software development teams. The result of this problem is a long history of projects and products that did not meet customer or market needs and that were either delayed or required extensive additional work to meet requirements.

2. Primary interface to the Scrum Team
The “Product Owner” is the primary interface of the business with the Scrum Team, and is responsible for ensuring a prioritized backlog is maintained so that each successive Sprint can be planned clearly and efficiently.

3. Actively addresses ambiguity and change
Given that requirements can be open to interpretation, and business priorities can change over the course of a project, it is imperative that a representative of the business be actively engaged — ideally on a daily basis — with the Scrum team to ensure development decisions stay aligned with business needs, and any issues that arise are addressed as quickly as possible.

4. Different titles can be “Product Owner”
For internal IT projects, the “Product Owner” may be represented by a Business or IT Analyst or even a direct End-User representative. For products targeted at wider markets, the “Product Owner” may be part of the Product Management team – e.g. a Product Manager or Technical Product Manager. And for consulting projects, it’s likely that the “Product Owner” is a direct representative of the end customer and not a proxy for them.

5. Is most likely NOT the sole business decision maker
It is understood that the “Product Owner” represents the business needs to the Scrum team but may not be the sole decision maker in the business priorities. i.e. While they interface with the Scrum team on one side, they will be interfacing with other parts of the business, or in fact directly with the end customer.

6. Must be technical enough to deal directly with the Scrum team
Given the technical nature of software development, the “Product Owner” should have a sufficient technical background to engage with the Scrum team when technical issues arise that impact delivery of business requirements. This does not mean the “Product Owner” has to be as technical as a Developer, but sufficiently knowledgeable to fulfill the bridging role between the business and technical sides of the project.

7. Not necessarily the ” single throat to choke” from a Scrum team viewpoint
While the Scrum team views the “Product Owner” as THE  representative of the “customer”  — singular or multiple — and their requirements, this cannot be universally true. While it *may* work for a given project for a particular (singular) customer, when it comes to software products targeted at market segments, the “Product Owner” may not have full authority for all decisions needed to be made and thus the Scrum team must be aware that some issues will need to be escalated up the chain to more senior people in the Product Management or Executive team.

So there you have it. While not as short as I would have liked, the above definition meets the constraints set out earlier in the post. It’s clear to me. What do you think? Does it address the “traditional” problems with the “Product Owner” role? Does it create any new ones?

Saeed

Tweet this: A new (and better) definition of Product Owner http://wp.me/pXBON-2y8 #scrum #agile #prodmgmt

Related posts:

1. The Scrum Title “Product Owner” must die!
2. Good Bye “Product Owner”, Hello “Backlog Manager”
3. That Product Owner (er…Backlog Manager) debate again….
4. Agile/Scrum and Product Management (part 3a)

NOTE: The following is a guest post from Wayne Mulligan. If you want to submit your own guest post, click here for more information.

——–

The company I founded almost 4 years ago, TickerHound.com, was acquired last year.

When we were still an independent company we relied on various agile frameworks and techniques to rapidly build and improve upon our products.

We never had a big enough team to do it completely right (e.g. pair programming, etc.) but we made use of a number of techniques that helped us create a great experience for our users.

Our New Home
Well, that all changed when we became part of the Production team (this encompassed design and development for our web products) at our new home: TycoonU, a financial education provider.

This was a much larger company than ours but lacked any explicit processes for planning, deploying and improving on its products.  The development schedule was typically determined ahead of time by the folks in the Marketing or Education departments.  The Tech & Design departments were not empowered to make product level decisions without getting approval first.

When I first came on board, conversations like this one were fairly common:

Jack: So, we’re thinking of rolling out a new course website on October 1st.

Me: Ok, great, but you do realize it’s September 2nd?

Jack: Yeah, and we need it to have….[fill in laundry list of product requirements].

Me: Ok, how would you prioritize each of those?

Jack: What do you mean?  We need them all.

Me: Ok, but given the tight timeline, it probably makes sense to work on the most important features now, add the rest to our “backlog” and roll them out after we launch.

Jack: Uhmmm…Backlog?  We need them all…bye.

I’m obviously exaggerating here (and names have been changed to protect the innocent) but you can imagine how the next month would look.

We’d go nuts for 30 days and after that ONE BIG PUSH was over, we’d sit twiddling our thumbs for a while.  And that wasn’t even the worst part.

The worst part was that the concept of rapid iteration and continuous deployment didn’t exist here.  Our products would sit stagnant until someone else gave us direction – and the direction would usually come from inside the building, not our customers that were on the outside and actually using our products.

What To Do?
The company really seemed like it could benefit from employing some basic Agile principles – user stories, rigorous prioritization, product backlog, sprints, etc.  However, as hard as we tried we were never able to institute a full agile (specifically, Scrum) process into the company.  Priorities were constantly shifting. Marketing and the Educators ran the show and the Technology & Design team had very little influence in changing any of that.

So instead of throwing up my arms and just rolling with it — or getting into a protracted battle with the other departments — I hunkered down with our team and asked this question:

What are the primary benefits of an Agile approach to software development and how can we modify some of the existing frameworks to fit this organization?

First Principles

To answer the first part of the question, we turned to the 4 elements of the Agile Manifesto:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

The Solution
We then looked at each of those principles individually and thought about how they could apply to our day-to-day.  Here’s what we came up with:

1.  Individuals and Interactions – Originally, when someone from Marketing or one of the Educators would come to us and ask for a new set of features, they’d typically talk about the specific functionality or implementation they wanted (e.g. “We need a forum on this website so our students can talk to one another”).  We’d spec the project out and execute as fast as possible.

However, that isn’t what agile is about.  Agile values the people the software is built FOR not who’s doing the building.

So we began to reframe the discussion around user goals.

Instead of asking about what functions they’d like in the forum, we’d ask questions like:

• Why do you think this would be valuable to your students?
• What do you hope they get out of the experience?
• What goals in the context of their financial education will this help accomplish?

That forced the person making the product/feature request to think about the issue a bit differently.  It forced them to focus on the user and how the user would interact with the product.  And best of all, it forced them to prioritize features and functions based on the value to the user!

We found that once we engaged people in other departments in this way, we could begin to propose solutions to the problem that were often simpler and more elegant than what they originally had in mind.  This allowed for rapid turnaround times, higher satisfaction amongst our user-base and would get everyone thinking about how to prioritize our efforts in the same way.

Once we had a prioritized list of features, we basically had the makings of a product backlog on which future sprints on which could be based.

2.  Working Software – One of the things my team prided themselves on, was even though we worked under tight, predetermined deadlines, we always had fairly polished deliverables.  The code, HTML/CSS mark-up and even the source image files were all well organized and clean.

On our next big product launch, the team took a different approach.  We began to relax a bit on the elegance of the code and the markup.  We didn’t include time for refactoring in the development timeline.  Instead, we focused on cranking out functional and usable software.

However, we kept a running list on what we wanted to improve upon later on.  This in turn was added to the backlog and would more often than not, become the sole focus of our next sprint.

3.  Customer Collaboration – This is perhaps what I think bothered me the most about our process.  We wouldn’t methodically gather data and insights from the people we were building our products for.

I mean, we’d put out a survey or two once in a blue moon, but first the marketing guys would go through it, then the Educators and then maybe we’d get access to some distilled version of that data.

So I was ecstatic when we got approval to include a “customer feedback” feature across all of our sites.  Now, we can get access to customer feedback in real time.

Not only that, but we found that people actually wanted to beta test our products for us before they came out.  By showing the Marketing team that people were proactively volunteering to help us test and build our websites, we were able to put together a dedicated Test Group of our customers.

In exchange for early (and sometimes discounted access) to our products and courses, we would get early feedback from our users.  Again, this was invaluable in not only prioritizing features, finding design and usability issues but also in constructing a meaningful product backlog to work off of after our launch was complete.

4.  Responding to change – It’s funny, but the very act of following a framework, like Scrum, too religiously violates one of the core principles of Agile.

So maybe in my desire to impose “our way” of doing things upon our new company, I was being somewhat hypocritical.

Instead of trying to stick too closely to a plan or a framework, I should’ve rolled with the punches from the beginning.

And that’s the biggest lesson I learned here – you can reap all of the benefits of an agile product development approach without following the rules to the letter.  It’s the spirit of the manifesto that counts and not the precise implementation.

The Results
Things have turned out better than I could’ve imagined!

We still operate on tight launch timelines, which tend to screw with our overall sprint cycles (e.g. you won’t see us on 3 week cycles throughout the year, we’ll break it into 5 weeks for a launch, back to 2 weeks for refactoring, then back to 3 week sprints until the next launch).  But our products have improved dramatically.

Our customer retention rate went up by 15% in the first year.

Our relationship with the other departments has dramatically improved.  We’re all speaking the same language now, which is the language of our customers.  Prioritizing products and features has become a breeze, especially now that we have real customers providing us with feedback all the time.

And best of all, the entire team is much happier and satisfied with their work.  We’re able to direct our own production efforts now and we’re also able to provide much more input into our user’s experience on our sites.

So my advice to anyone struggling with similar issues – don’t try to force something into your company that doesn’t quite fit.  Every organization is unique and has circumstances beyond your control.  Observe, adapt and most importantly, keep it about your customers and I believe that only good things will follow.

Wayne

—–

Wayne Mulligan founded TickerHound.com – a white label Q&A platform for investors that boasted NASDAQ as a client.  TickerHound was acquired last year by Tycoon Publishing, an online educator for independent investors.  At Tycoon, Wayne oversees a team of talented designers and developers who are trying to change how individuals manage their money. You can find more of Wayne’s thoughts on his blog: http://www.experienceblogger.com.

Related posts:

1. Guest Post: Improving Product Management the Agile Way
2. Guest Post: 3 Steps to a More Effective Voice of the Customer Program
3. Agile/Scrum – Reality Check
4. Guest Post: 9 Ways NOT to Present Your Company or Product Via Social Media

Related posts:

1. Guest Post: 4 ways that Agile methods brought sanity to my company
2. Guest Post: The need for Empathy in Product Management
3. Guest Post: Measuring Product Management (part 1)
4. Guest Post: Measuring Product Management (part 2)

NOTE: The following is a guest post by Tzvika Barenholz, a Product Manager living and working in Israel. If you feel inspired to write a guest post of your own, click here to find out how to submit it to us.

We all know the situation: you’ve collected a bunch of product requirements, put them into a nice excel sheet or clever table-like GUI front-end; you’re all psyched about making the big decisions, prioritizing and leading the product to the proverbial “next level”. You sit in front of the screen, crack your fingers, stretch a bit and place your hands in the typing position.

“First item, feature xyz” – yes, you say it out loud, you’re psyched remember? – “First column, Importance” (or priority, or appeal, or whatever is your favorite alias for customer value)

OK – now what *was* the priority of feature xyz?

Let’s see. A couple of big customers have asked about it in a recent expo, so probably high, right? Then again, it’s one of those things that make the product more complicated, so call it low. Having said that, it would really improve average sale price, which is aligned with the five year plan, so high it must be. But what about breadth? It really would only appeal to a fraction of our customers. Back to low again.

And on, and on.

Exasperated, you note that after 20 minutes you’re still on item #1 out of 37. It’s looking more and more like a long night of pizza and coke with the developers. The next thing you know, there’s a little voice inside your head that whispers: make it a medium!

Of course! How foolish you’ve been to overlook this possibility before. A medium is right in the middle between high and low. It’s the perfect answer for what seems to be neither here nor there, or both here and there. Your right index finger then makes it merry way to the m key.

But STOP – you’re just a moment away from falling into a trap as old as the hills. Why? Because there is absolutely positively no such thing as a medium, except maybe as a shirt size.

“Medium” is a shirt size, not a useful priority rating

Prioritizing something as medium is just a way chickening out of making a decision. If you don’t have enough information to make the call, go get the information, then make the call. If you’re piling up different qualities like “broad appeal”, “helps sales”, “improves margins” and “technologically strategic”, then by all means, add 4 columns, fill them out with highs and lows (or yes or no, for the more advanced practitioners who know how to make an even cleaner cut), and then rebuild the priority column as an index composed of them all.

But whatever you do, don’t just cop out. Don’t just type medium and move on to the next item, or you will end up building the wrong things for the wrong reasons.

Related posts:

1. Guest Post: The need for Empathy in Product Management
2. Guest Post: 4 ways that Agile methods brought sanity to my company
3. Guest Post: Triangle Offense and Scrum Mania
4. Guest Post: Web Product Management 101 for “Offline” Managers

ProductCamp New York was last weekend and it appears to have been quite successful. Alan attended and wrote up this post about it.

If you missed the New York session and want another chance to attend one, there are 4 5 more in the works in the coming months, starting with ProductCamp Austin in only a few weeks.

ProductCamp Austin
Date: Saturday August 15, 2009
Location: The University of Texas at Austin, McCombs School of Business, Austin
More details: click here.

Followed by one in September.

ProductCamp RTP2
Date: Saturday September 26, 2009
Location: Cambria Suites, Raleigh-Durham Airport
More details. click here.

And 2 ProductCamps in October.

ProductCamp Toronto 2009
Date: Sunday October 4, 2009
Location: Ted Rogers School of Business @ Ryerson University
More details: click here.

ProductCamp Seattle
Date: Saturday October 10, 2009
Location: Amdocs, 2211 Elliott Ave, Seattle WA
More details: click here.

And to round the year off, Boston is holding their camp in November.

ProductCamp Boston
Date: November 7, 2009
Location: Microsoft New England R&D Center, Boston MA
More details: click here.

For information on these events as well as other events relevant to the Product Management, Product Marketing and Product Development communities, check out our Events page. And if you know of an event we should list, let us know in the comments of that page.

Saeed

Related posts:

1. More ProductCamps!
2. A Plethora of ProductCamps
3. A 5th element for the Agile Manifesto
4. Towards a Product Management Manifesto (part 1)

NOTE: The following is a guest post by anonymous blogger GeekMBA360, author of the blog by the same name.  If you feel inspired to write a guest post of your own, click here to find out how to submit it to us.

- – – – – – – – – – – – -
Phil Jackson has won more NBA championships than any other coach in history. He won six championships with the Chicago Bulls, and then won another four championships with the Los Angeles Lakers.

If you’re a basketball fan like myself, you probably know that Phil Jackson utilizes a unique offensive system called the Triangle Offense.

The Triangle Offense has been around for a long time. According to Wikipedia:

“the triangle offense’s most important feature is the sideline triangle created between the center, who stands at the low post; the forward, at the wing, and the guard at the corner. The team’s other guard stands at the top of the key and the weak-side forward is on the weak-side high post — together forming the “two-man game”.

The goal of the offense is to fill those five spots, which creates good spacing between players and allows each one to pass to four teammates. Every pass and cut has a purpose and everything is dictated by the defense.”

I’d like to make a few observations about Phil Jackson’s success and his use of the Triangle Offense.

First, Triangle Offense is neither sufficient nor necessary for winning a championship. It’s true that both the Chicago Bulls and Los Angeles Lakers had great successes with the system. However, there are also many other teams who had been very successful by employing other offensive systems.

For example, the San Antonio Spurs has won four championships between 1999 and 2007 (the most in the NBA during that period) by having a totally different system. Other championship teams such as the Detroit Pistons and Houston Rocket also had very different offensive systems.

A good team implements whatever system fits it the best. It doesn’t try to impose a system on a group of players.

Second, triangle offense requires the right combination of players. Because it is such a fluid system, it requires the players to be very flexible. For example, the systems prefers a big-man center who can pass the ball well, and a small forward who can defend and shoot the 3-pointer. It’s a complex system. The players must have the patience to learn and practice in order to play effectively in the system.

It’s not a system that could be retrofitted to any team. Some players are simply not good fit for the system.

Third, Triangle Offense requires an excellent personnel manager and a solid X’s & O’s guy. According to this ESPN article:

“Being a great NBA coach is about managing egos, earning your players’ respect, developing team chemistry, making (in-game and off-day) adjustments, and emphasizing the right things. And no one’s ever done all that better than Jackson.”

Phil Jackson has Tex Winter as his assistant coach. Tex Winter literally wrote the textbook on triangle offense, and is an expert in teaching the X’s and O’s of Triangle Offense. Clearly having the right supporting cast is incredibly important.

The relationship to Product Management

Now, let’s move to our professional world of product management and software development.

In the past few years, I think our industry has had a “Scrum mania” — there are armies of consultants and trainers who tout the merits of the Scrum methodology. Company executives send people to get “Scrum Master” training and assume that their products would be shipped on-time.

An example from real life

I worked for a start-up company that provided a hosted data mining product. It had about 30 clients. Each client had a separate instance of the application.

Because of the amount of customization for each client and complexity of the software, it would take a couple of weeks to deploy a new version of the software since the new software had to be tested for each client. The deployment process was a little bit different for each client due to customized settings and configurations.

The development team had been doing a good job. But, one day, the big boss attended a seminar on Scrum. He wanted the company to adopt Scrum methodology. He sent two Program Managers to get certified.

He even brought in a trainer to give all of the developers a one-day Scrum training session. His rationale is that instead of shipping a new release every three months, we’ll get something done and ship product every month.

It was a disaster.

Most developers on the team used to work for large packaged software companies such as Microsoft, Oracle, etc. They were excellent developers who were used to the waterfall development model. And most of them had been working at this start-up for a long time.

They rebelled against the Scrum process. Instead of daily Scrum updates, they’d much prefered spending the time on design and coding. They also hated to update their tasks using the Scrum software.

Because of the complexity of the software, each developer got very little done during each 3-week scrum cycle. And then they have to attend another several hours of scrum planning. It became very inefficient.

The morale was low. Scrum Masters and developers spent hours debating the right way to do Scrum during each Scrum planning session.

You could argue that this company implemented Scrum incorrectly. There is nothing wrong with Scrum itself.

However, I think this is an example of a company that probably should not have implemented Scrum at first place. Just like the Triangle Offense, Scrum is a methodology, a system.

Scrum is neither sufficient nor necessary for running successful software projects.

Scrum requires the right combination of personnel: Developers must buy into the new systems, and be willing to adapt. In this example, the company had a group of very experienced, senior developers who were used to a waterfall development model that had worked well in the past. It was very hard to get their buy-ins, especially given the nature of the products they were building.

Running successful Scrum requires a excellent personnel manager and a solid X’s & O’s guy. In this particular company, the Scrum Masters were well trained. However, the development manager and senior management team didn’t fully understand the cultural and organizational challenges of implementing a new system. And this was what led to the downfall.

Are you thinking about putting a new system in place? Think and plan carefully. You want to put in the best system for your organization. Simply adopting systems used by other organizations won’t work.

—

GeekMBA360 is a product management executive with over a decade of experience in e-commerce, online advertising and enterprise software. His blog,  GeekMBA360.com, offers career insights at the intersection of business and technology. He also publishes the popular Great Depression 2.0 Survival Guide for High Tech Professionals.

Related posts:

1. Agile/Scrum Software Development and Product Management
2. Agile/Scrum and Product Management (part 3a)
3. Agile/Scrum Software Development and Product Management part 2
4. The value of Scrum