1

This question already has an answer here:

In agile, there is an emphasis on customer involvement. They provide user stories, provide feedback, and a lot of decisions are up to them.

There are situations that there is no customer for the software at the time of development. If we are going to ship a game -a software that people will be its customers after shipment- or if we are going to create a new service -like a new social network- and we are going to own it, there won't be any client present at the time of development.

I have a few questions for these environments:

  1. Is there any software development methodology/framework specially designed for such cases?
  2. Is agile applicable to such environments? If yes, How?

Update: It would be much interesting to know about a similar project developed agile.

marked as duplicate by user53019, gnat, user22815, Doval, Dan Pichelman Feb 5 '15 at 21:16

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 1
  • @gnat It's completely different situations. If the client does not want to be agile, it doesn't mean there is no client available! – Mehraban Feb 5 '15 at 17:52
  • top answer in there applies: Parts of your team can, however, act as "proxy" customers... And if you want a close situation, check answers in another question mentioned in comments: "Our team is trying to understand and adapt Scrum and other agile practices, but we can not figure out how to deal with customer feedback when there is no customer..." – gnat Feb 5 '15 at 17:56
6

You need someone to be a proxy for the customer. Someone in the team who takes on the role of Product Owner, or whatever it is called in your methodology of choice, and puts themselves in the position of a potential customer.

Note that this is a difficult job! But choosing the right thing to build is one of the difficult problems any start-up must face!

  • 1
    Customer != end user, which certainly does not yet exist. The development team is always working for someone though. – user22815 Feb 5 '15 at 18:59
  • I believe in Game Design, the role of "customer proxy" is generally the "tester" or "quality assurance" (in how the OP seems to be interpreting the word customer) However, there are still overall goals for the total experience of the game - these goals are laid out and managed by whoever is ultimately in charge of the game's development. This person, or group of people, is what is actually meant by "Product Owner" and "Customer" – DoubleDouble Feb 5 '15 at 21:44
3

... who will the future client be? If you can't answer that, you probably have more significant problems than "how to run agile" since you are adopting a, "if we make something cool, people will buy it!" perspective.

You can do a variety of techniques to create an identity for this client. Perhaps a user persona acted out by your team members.

Having a documented "this is a sample user, here are needs of this user" makes it a lot easier to act this out correctly as well.

  • It will be good to know about other techniques and maybe some reference about it. – Mehraban Feb 5 '15 at 18:42
  • You can SORT OF work around this by adopting Steve Jobs's approach: Apple built cool stuff that Apple people wanted to buy. If your plan is for your startup to get rich building something you couldn't get excited about to save your life, you've got a bigger problem than "how do we run Agile for this". – John R. Strohm Feb 5 '15 at 21:05
  • @JohnR.Strohm for every company like Apple that pulled it off, there are quite a few that don't exist anymore... – enderland Feb 5 '15 at 21:21
  • @enderland: How do you know that your sample user even EXISTS, much less exists in sufficient quantity and with sufficient disposable income to make it worthwhile to build your proposed product? Doing it Apple's way at least guarantees you know your customers are out there. – John R. Strohm Feb 5 '15 at 22:15
1

There are many possibilities open for you for situations such as this.

For the scrums meetings and day to day, as others mentioned, you should appoint a member of your team, typically the one with a more "visionnary" feel for your game, to act as the stakeholder. Do make sure that the person that is signing the checks is also represented, at least for your sprint reviews and sprint planning.

Next you should definitively get a broader feedback, play tests for example would be a great source of information. Usability testing is also good, they do overlap but both target different parts of your system (first checks if it's fun, the other checks how easy it is to get into it).

Stakeholders are an important part of the scrum methodology and should not be overlooked. They are in big part what keeps the dreams and wishes of the team firmly grounded with their perspective. So if you decide to play the role internally do make the extra effort to get external feedback as often as possible.

1

You may already know about this but you want to look at the books/ movements "Lean Startup" by Eric Ries and "Running Lean by Ash Maurya.

Both cover concepts and methods of determining with incremental design, prototyping and development, discovering who your customers might be, what your product needs to be and where it needs to go, and in general, continuously testing your premises for even wanting to develop your product. They help you ensure that you don't spend a ton of money up-front in building stuff that no one might want.

Once you start actually building the product, techniques such as Scrum and Kanban can help you build incrementally/ continually - and prioritize what you should build by focusing on risk/ cost of delay and other factors.

This is a very basic response to your question - but one needs to better understand your situation for that. And if you haven't read those two books, you MUST!

HTH

0

Replace the word "customer" with "stakeholder". For a contract-software development gig, the primary stakeholder is the customer footing the bill.

For a speculative software or a game, the primary stakeholders are the owners of the company, or whoever else is putting the up front investment to make this happen. The stakeholder in that case often times has plenty of stuff to do other than programming, but needs to be kept up to date and involved with the development process. That person is responsible for imagining what the customer is going to want, or is responsible for selecting someone else to fulfill that role and serve as the stakeholder.

Then, read this: Five Worlds

  • I'm primarily talking about a startup without any big investment upfront. – Mehraban Feb 5 '15 at 17:55
  • @SAM: putting a lot of hours in without necessarily getting paid still counts as investment. – whatsisname Feb 5 '15 at 17:56
  • I agree about that, but it doesn't mean the team "has plenty of stuff to do other than programming". – Mehraban Feb 5 '15 at 17:58
0

I would say you should put yourself in the shoes of your customers. Try to do a SWOT analysis to figure out why would you buy such a software and decide on the potential requirements that a customer would request. From there you can I would recommend reading Business Model Generation written by Alex Osterwalder. I think this is a question that relates more of a how to build a software that is desirable.

0

Often Agile seems geared towards B2B interactions, where your "customer" is another company with a few representatives who are there to tell your group what they want. From what I understand, you are talking about the situation where you are making a product for mass distribution. In such cases, your customers are millions of people you hope want to use your product. You don't really have anyone to invite to your review.

The way we handle this is with a separate position, a "Product Manager", who is in essence responsible for acting as the customer. They will analyze the market, do competitive analysis, survey customers, do user testing, and anything else to try to understand the target customers. That person acts as your customer. They end up working closely with the product owner in that regard.

If you are small, and can't have a separate product manager, the product owner can often double-up on that role. Though it is generally better to have someone separate, as the product owner also has to manage technical stakeholders.

Not the answer you're looking for? Browse other questions tagged or ask your own question.