In our post on Product Owner, we discussed, how some of the most effective product owners have deep knowledge of the market, connect with the customers and can structure as well as prioritize requirements for the development team. In addition, they have great facilitation skills to set up environment where collaboration is fostered and utilized for competitive advantage resulting in sustainable delivery of high quality software.

We have been working with one such product owner. Sean Devlin plays the role of product owner for Front Rush - he explains requirements with business and acceptance test perspective and ruthlessly simplifies and prioritizes them. And its partly because of him that despite no face to face communication, what so ever - the product has been built to great quality and tremendous success, and continues to be built with great quality and tremendous success. In this interview, Sean Devlin shares his experiences in being a product owner.

agilecollab :  What was the business case around Front Rush and how did initial idea come about?

Sean Devlin : Collegiate Athletics in the U.S. is big business.  College coaches are under huge amounts of pressure to perform successfully because of the correlation between athletic success and alumni giving rates, total applicants, and national recognition which in turn supports the universities’ academic initiatives.  The first step in building a successful program is recruiting high school athletes to play for the respective university and with this comes a huge burden of storing large amounts of data for each recruit.  Coaches need to track, not just the contact information but also the number of times they communicated, visited, and evaluated each athlete.  A single coach can track anywhere from 50 to 12,000 recruits in a single year and prior to Front Rush, this was mostly done through hard copies and archaic databases not built specifically for recruiting and certainly not suitable.  In addition to storing data, coaches also need to be able to communicate with their athletes the same way athletes communicate with each other.  The old model of sending a letter and a follow up call has become obsolete in a society built on real-time communication.  The coaches recruiting model is nearly identical to the sales model used in big business today except replacing ’sales leads’ with ‘recruits’.  Front Rush simply applied the CRM technology pervasive in the business space and tailored it to collegiate athletics.  The focus is on usability so that coaches of all ages and technological backgrounds or lack there of can benefit from the application. The co-founder of Front Rush, Brad Downs, played collegiate baseball, and while being closely affiliated with the coaching staff saw first hand the inadequacies of the current hard copy/excel driven model of recruiting.  He had contacted me because of my background in the technology sector and together we developed ideas for Front Rush based on current CRM Systems, new technologies and scalable processes that would simplify a coach’s day to day.

agilecollab : Why did you select Net Solutions as your development partner?

Sean Devlin : During the dot-com boom, I had two high school colleagues who were using an outsourcing partner in India to develop web-sites for state-side clients.  For a brief period of time, I had done research on potential outsourcing partners which is where I first came across Net Solutions.  I later started a company, esman productions, which focused on organic marketing campaigns through college students and used Net Solutions’ services to develop our flash website.  Spin the big hand on a clock a few years and we needed a partner for development with Front Rush.  I contacted Net Solutions first because of the history with esman productions.  I also contacted other firms world wide.  We made the decision to work with Net Solutions because of their immediate understanding of our needs and the quality of product we could expect.

agilecollab : As a Product Owner what were the challenges in constructing requirements and getting market feedback?

Sean Devlin :  Getting market feedback is easy for us.  We have a perpetual dialog with our end-users about the speed, performance, usability and functionality of Front Rush.  Coaches know how they want Front Rush to work for them, and we work very hard to make this happen without diluting the core focus of the product.

agilecollab : In this light, how your overall experience been in working with Net Solutions?

Sean Devlin : At Front Rush, we expect only the best.  That is why we work with Net Solutions.

agilecollab : What were your original concerns in going with Net Solutions? How do you think we fared in this regard?

Sean Devlin : Our initial concern was whether or not the needs of a non-tech savvy coach would translate and scale in our CRM-type application.  This concern only lasted until we built the first mock-up of Front Rush and realized immediately that anybody would be able to use Front Rush regardless of their tech knowledge.

agilecollab : You have worked on both a fixed price and an hourly queue model. We know both were Agile in nature. Which one you liked more and why?

Sean Devlin : A fixed price model was sufficient for getting Front Rush off the ground and into a working application.  However, because of the growing needs of coaches, we have had to evolve our development model in order to be completely Agile.  Having a dedicated team makes it much easier to abide by SCRUM rules which results in more productive, effective development.  SCRUM allows us to develop in the moment and take projects in different directions as we see necessary.

agilecollab : What were some of the things you would recommend for a great development team - remote product owner participation?

Sean Devlin : I would recommend getting the best talent that you can find and set up an environment that will allow you and your team to be as light and quick as possible.  Make certain that there are no communication barriers and always err toward simplicity.

agilecollab : What sort of tools you use at your end to manage requirements, weight their priority or do you keep it simple?

Sean Devlin : From a development perspective, we do in fact have the giant white board with every recommendation, and every idea, every bug, and every concern that our end-users express to us.  The reality is that we rarely reference it.  We work very hard to engage our customers in open dialog so that we can understand their needs in and out — the white board is really just a formality. From a communication perspective, we are moving exclusively to 37 Signals’ Campfire. Its a great medium to collaborate with your team, share projects, files and then reference later on.

agilecollab : Finally, what are future plans for Front Rush?

Sean Devlin : Front Rush just released an application for Coaches to manage their camps which is a simple spin off of the current Front Rush application except with an e-commerce component for campers to pay online.  This is a major step in building an environment, through our applications, that will give coaches all of the tools necessary to spend as little time in the office and more time out on the field winning games!

Popularity: 23%

Posted on March 13th, 2008 by admin
Filed under: Case Studies, Interviews, Outsourcing 2.0 | No Comments »

In her presentation at Agile 2005 Workshop, Mary Poppendieck, talked about 1/3-2/3rd contracts. We think this is an interesting way to structure a collaboration schema for engagement of Agile teams. Here is how it can work:

• The team/ analysts get together with the product owner or customer and write down the requirements and understand the acceptance scenarios as well as objective for each of the requirement.
• The product owner or customer would prioritize the requirements to arrive at a “can’t live without” list of requirements. You can use YAGNI for business value as well.
• The team can provide an estimate of the complete project using whatever estimation methodology they choose.
• The team then calculates what is one-third the time of the project.
• Based on the initial requirements list, the team and product owner would further narrow down only the main work flow requirements.
• For these requirements, the team does further analysis to define acceptance scenarios, presentation and task planning.
• The team develops a no whistles working version [yes it does calls to database and all functionality is actually working] of the project in 1/3rd the time.
• After 1/3rd the time, the team can get together with the product owner and review the functionality.
• After this, we would encounter the following scenarios:
  • If the product owner or customer like what is happening and the original requirement list still stands - continue and develop the project with the confidence that it is moving in the right direction.
  • If the product owner or customer don’t like what is happening and would like to change the requirements or assumptions, then you can do so. Although, this is not ideal, it is still better to do this when you are only 1/3rd done than when you are a 2/3rd done or worse when you are 100% done.
  • More than likely the process of actually getting down to development would uncover and test hypotheses, priorities and assumptions used while actually developing a project and generate new and better idea on how project should actually be developed.
• If you do not decide to change, then the original contract still stands. If you do decide to change, then the team and product owner can discuss the project from a new perspective [almost like a new project].

It is important to note that working version of the functionality above is different from a proof of concept. Proof of concept focuses on determining feasibility of an idea or approach, rather than determining the usability or effectiveness of ideas or approach. The proof of concept might be a step in the 1/3rd - 2/3rd approach but not by itself would be a complete 1/3rd of the project. A software prototype can sometimes work as good way to approach 1/3rd of the project. However, for a 1/3rd - 2/3rd approach, you actually develop 1/3rd of the project. For one project user interface might be the single most important aspect and hence, that would be first addressed during the 1/3rd of the time via a click through prototype. For another project, a core workflow of how various members interact would be important and hence, calls to the database might be important. The 1/3rd of the developed project is incrementally and iteratively enhanced and not thrown away unless found completely unusable.

When the product owner or customer and the team are on their first project or first release together, they can estimate the project in detail. However, as they understand each other and learn to work with each other, the estimates and requirements discussion can be high level or as low level as needed. Hence the above process would work like this:

Rough requirement discussion — ballpark estimate provided — 1/3rd of estimate calculated — 1/3rd of requirement list discussed — 1/3rd requirement list detailed — 1/3rd requirements developed — Feedback

The advantage of this approach is that overhead of meetings and discussions is less and you actually get down to focus on your core functionality sooner.

An important question is to understand why 1/3rd and why not 1/4th or 1/5th or even 1/2 of the project. Well a simple answer is that you can pick a number as you want. For a risky project or unclear domains it is recommended to ruthlessly prioritize and re-prioritize your requirements, you could go to as low as 1/5th of the project. Using the Pareto’s Principle, 20% of all requirements would generally give 80% of all business value. However, doing anything more than 1/3rd is keeping feedback away longer and hence, inherently more risky on relatively risk free projects. If you have multiple workflows that would need to be tested, prioritizing is important. If this is not at all possible [which is highly risky as well], you can start two 1/3rd approaches relatively separately. Even if a contract is not specifically constructed as a 1/3rd - 2/3rd contract, it makes sense to develop each project in this way.

Popularity: 25%

Posted on January 18th, 2008 by admin
Filed under: Collaboration, Outsourcing 2.0, Pricing | 1 Comment »