How does rapid prototyping fit into an agile methodology?

Question

I work for a large company, which dictates the use of agile processes. For example, for our projects, we use cloud-based services that are specifically targeted at managing agile development.

The specific engineering group I work for has not traditionally developed software (instead we help drive projects from a much more birds-eye point of view), but that is changing. We have a wide range of upcoming/planned software projects that are mostly data-centric - e.g., we will be doing data monitoring, collection, aggregation, and some reporting. Other tasks involve automation with specialized hardware and various types of client/server (multitiered) architectures. I am to assist in the process of hiring several people, and formulating many of our plans in moving forward.

My question is whether or not doing rapid prototyping (throwaway code) fits into an agile philosophy. For example, I love Python and its wide range of packages. I see the possibility of implementing many of our ideas very quickly with a Python based workflow. However, I think that there will be a lot of perceptions that Python is not "enterprise-quality", and much of this work would need to be rewritten in Java or maybe C++.

However, creating the Python prototypes would give us a lot of bang for our buck in enabling us to quickly deliver real results.

Have you been able to incorporate rapid prototyping - hopefully in Python - into a solid agile workflow in an enterprise environment?

Answer 1

The concept of "prototyping", as intended in RAD, is a bit foreign to agile development. This doesn't mean it can't be done, but it's unusual.

There are different cases that need to be explored:

1. Is the prototype an "empty shell", a mock up or a demo, built to give an idea on how a product would look like? You can certainly do it with one or more stories -- however you are building something out of your own imagination, not building a product out of real feedback. People don't evaluate a demo like they evaluate a product. For example see the feedback about our top bar prototype versus our real top bar implementation.

2. Is the prototype something that needs to be built in order to understand better the problem space? Then it should be covered as a spike, and only its results kept (source code is transient).

3. Is the prototype a version 0.x? A mininimum viable product? Then use the agile process of your choice for it. If you need to rebuild it in another language, you are likely to be better off if you treat that a different product. Note that sometimes this is treated as a way of shortcutting writing a spec ("it should do the same as the prototype!"). That's a really poor way of documenting a product, but this is probably better explained as a separate question and answer :-)

Answer 2

Isn't rapid prototyping (i.e. iterative and incremental development) sort of the whole point of Agile?

It sounds like you're having issues with "perception is reality" at your organization. You might want to remind everyone that Agile doesn't mean "throw out all plans," any more than Test-Driven Development means "throw out all architecture."

And Python is not (if it ever was) a toy language. NASA and its contractors use Python, and if it's good enough for them, it's good enough for me.

Answer 3

There is a quite stablished practice in Extreme Programing called Spike. This means that it is throwaway code. There is nothing special in it. It is just a Sprint in which the expected result is the knowledge about the throwaway code.

The above link has enough information about the good practices, pitfalls of spikes.

Your specific case of use seems a good example: it can be helpful to design the interface, validate the utility and show it to some users.

Answer 4

You're going to throw the code away and not put it into production (make that perfectly clear to EVERYONE), so being agile or not doesn't really matter. Any agile practices are purely optional for prototypes: sprints, burn-downs, testing, pair-programming or whatever else you plan on using.

If you're mainly going to be building functional models in Python to help product owners and other decision makers to conceptualize the project, you don't need to be enterprise ready. However, if you're creating proof of concept or trying to see if you can handle certain performance levels, you should probably stick to the production language. That doesn't mean you can't try it in Python.

Regardless, you're going to throw the code away, but have the knowledge of being able to make this work along with a better sense of what the owners want. Now you can use any methodolgy you want.

Answer 5

I'd add that prototypes are crucial for learning, and also in the Agile spirit. If the prototype allows you to learn, especially within faster feedback cycles, then go for it. It's all about maximizing learning and sharing learnings with the team.

Answer 6

In terms of learning, I'd add that prototyping gets you to learning, faster. That way, you can validate whether people even care about the problem you're trying to solve - and if the solution you have in mind is at all what they're looking for - without wasting a lot of time building a full solution that may, in the end, not solve a painful enough problem or not solve it the right way.

Answer 7

The true spirit of Agile is about interaction and communication. I would say if the prototype works well as a tool to help communication, there is nothing wrong to use it in Agile world. In our team (we have been practicing Agile for more than 5 years) we used it from time to time. And there are some benefits I can see from that

1) Assist communication

2) Get users into solution interviews and get early feedback

Caveat:

Direct communication between UX and engineers should NEVER be replaced by any prototyping artifacts. If possible, pairing with engineer works way more better than communicating through a mediator (prototype).

Answer 8

Others already mentioned the learning purpose of spikes. What is missing is the underlying agile principle of it which is fail fast.

One of the pillars in agile development is to recognize the hard parts and go for proof of concepts, see if you can do it at all. The classic way of working your way through all the tasks in some "logical" order may turn out to be really expensive if you find you cannot do something late in the project. Everything done thus far could be a waste.

If it has to end up that way you want to know as quickly as possible. Then the stakeholders can choose to either just stop burning money while not a lot has been burnt yet and accept what they want is not feasible or to try a radically different approach to the problem that will have a new chance of succeeding. If your prototypes are serving this purpose they are most agile indeed.