POGE (Principle of Good Enough)

POGE (Principle of Good Enough) is quite agile and very aligned with the MMF concept.

Wikipedia definition:

The principle of good enough (sometimes abbreviated to POGE) is a rule for software and systems design. It favours quick-and-simple (but potentially extensible) designs over elaborate systems designed by committees. Once the quick-and-simple design is deployed, it can then evolve as needed, driven by user requirements. Ethernet, the Internet protocol and the World Wide Web are good examples of this kind of design.

However, thinking about an ever evolving system, we should add two letter to this acronym, an F and an N:

POGEFN or Principle of Good Enough For Now.

This will help us build and market a system that is good enough for now, but always keeping an eye in the future of this system.

Erci Norlin wrote in 2004 at ZDNet that de POGE used in designing internet gave room to the

the endless schemes, scams, and shams that now dominate the Net are quickly dragging us toward a future wherein the Net as we know it is basically unusable.

So, use the POGE, but don't forget that it should be good enough for now and may not be good enough in the future.

Top 10 Agile Team Management Practices

Mike Griffiths from Leading Answers just wrote an interesting post where he explains the top 10 team practices for managing an agile team:

1. Empower them


2. Listen to them


3. Trust them to get the job done and solve problems


4. Judge when to step in / away


5. Create a productive workspace for them


6. Provide support for them


7. Encourage reflection and adaptation


8. Reward and recognize them


9. Communications


10. Align objectives and promote people

To get an explanation of each of those best management practices, please access Mike's One-Page Best Practice Summary.

What's the ideal sprint length? Part II

I already talked about this issue previously, but I recently read a post about the same topic at InfoQ that brings more insights to the question:

Forces that tend to Shorten

• No Changes: The rule of no scope changes during the current sprint. This means the organization must be able to wait on average 1 1/2 sprints before asking for a change.
  
• Closure: The end of a sprint creates a good feeling, it's a chance to celebrate the team's accomplishments before starting all over again (Ilja Preuss).
  
• Feedback: This is the chance to reflect on the work completed and how the team performed. More frequent feedback means smaller course corrections each time. (Ilja Preuss)
  
• ROI: Every sprint provides an opportunity to deploy new features. (Ilja Preuss)
  
• Reliability of Commitment: With shorter sprints it's easier to tell if the commitment can be meet. With longer sprints team the team is more likely to over-commit, thinking they should be able to get that story done. (Paul Oldfield).

Forces that tend to Lengthen

• Getting to "Done": In some environments it can be technically challenging to get a story finished in a short sprint. (Ash Tengshe).

Being a PM is an exercise of leadership

In a recent post at schmula, the author mentions:

Gary Convis was recently brought in to be the CEO of Dana Corporation (DAN), an $8.7 Billion manufacturer of auto parts. Convis is a 40 year veteran of the auto industry and a former executive at Toyota. Dana Corporation is a struggling giant, currently in bankruptcy. When asked what words of wisdom he has to impart to his new team members at Dana Corporation, he said “manage as if you have no power”.

Well, that's the core of the Product Management role. A PM has to manage her products asking a lot of people in her organization to do stuff for the product without having any power to demand anything from anyone. So being a product manager is an exercise of good leadership skills. Enjoy your exercise!

Locaweb launches 4 new blogs

I was not able to write here this last 15 days because I was working on a new project at Locaweb which also demanded writing posts. We decided to launch 4 blogs with content specially written for our customers:

• Succeeding on the web: it will bring information on how to make your web site a success (SEO, SEM, customer care, web statistics, tracking, etc.).


• User Experience: having a beautiful web site is not enough. We should guarantee that the user's experience is good so she comes back and recommend the site to her friends.


• Internet technology: focused o technical topics such as programming, frameworks, databases, etc. We will talk about Ruby on Rails, Python, Django, MVC, ASP.Net, PHP, MS SQL, MySQL, Java, …


• Agile Software Development Methodologies: or the readers of YAPMB, this is not a new topic, but in Brazil it is. Since many of our customers are web developers, we figured out the agile methodologies that have been so useful and helpful for us probably would be very useful and helpful to our customers. So we decided to start to teach agile to our custmers through this blog.

All those blogs are in Portuguese, so for the readers that don't read in Portuguese, I apologize. Maybe you could consider this an opportunity to learn Portuguese! :)

Now I want to come back to my weekly posting routine at YAPMB!

Minimal Marketable Feature

Minimal Marketable Feature or MMF comes from a book named Software by Numbers by Mark Denne and Dr. Jane Cleland-Huang, In this book they introduce the concept of:

Incremental Funding Methodology (IFM), an ROI-informed approach to software development in which software is developed and delivered in carefully prioritized chunks of customer valued functionality. These chunks are known as Minimum Marketable Features or MMFs.

To illustrate MMF they used an example very simple to understand: imagine that you have to build a web internet banking system. There are lots of features, and it could take many months or even years to be delivered with all "must have" features. When thinking in terms of MMF, we should look at those "must have" features and find out if we can release them independently, i.e., if a certain feature, if released independently would bring any value to the customer. In a web internet banking system, we could choose to release it with only account balance report and no other feature. That would be a very simple web internet banking system, but if released as soon as ready, and not after some other features get ready as well, it will bring value to the customer earlier. And whenever you bring value to the customer you are bringing value to your company as well. Besides the happy customer, in this example you probably reduced cost, since if the users don't get their account balance reports through web they certainly use another way to get that info and probably this other way is not as cost effective as the web.

Joe Arnold, an Internet Executive specializing in Agile Development at Yahoo!, mentions in his blog:

A Minimal Marketable Feature (MMF) is a feature that is minimal, because if it was any smaller, it would not be marketable. A MMF is marketable, because when it is released as part of a product, people would use (or buy) the feature.

Next time you are planning a new system, product or set of features for an existing product, try thinking in terms of MMF. It may bring you and your customers a lot of value.

Bezos on Innovation

In a recent interview published in Business Week site, Jeff Bezos, Amazon.com's founder talks about innovation at Amazon. It is worth reading it all but I would like copy here one question:

Q: Every company claims to be customer-focused. Why do you think so few are able to pull it off?
A: Companies get skills-focused, instead of customer-needs focused. When [companies] think about extending their business into some new area, the first question is "why should we do that—we don't have any skills in that area." That approach puts a finite lifetime on a company, because the world changes, and what used to be cutting-edge skills have turned into something your customers may not need anymore. A much more stable strategy is to start with "what do my customers need?" Then do an inventory of the gaps in your skills. Kindle is a great example. If we set our strategy by what our skills happen to be rather than by what our customers need, we never would have done it. We had to go out and hire people who know how to build hardware devices and create a whole new competency for the company.

It doesn't let us forget:

It's all about the customer!