Agile, Requirements, Software Development

My #Agile #Pretotype experience

Two months ago I was introduced to the concept of Pretotyping. If I remember correctly, the introduction was through an excellent InfoQ article. The concept and practice intrigued me and I was able to apply it to a project I was working on recently. This is a recap of that experience in the hopes that is may assist others.

Definition

There is an excellent website that provides some great information on Pretotyping. The site is www.pretotyping.org. The definition of a Pretotype that is proposed on the site is:

Pretotyping[pree-tuh-tahy-ping], verb: 

Testing the initial appeal and actual usage of a potential new product by simulating its core experience with the smallest possible investment of time and money.
There are some excellent examples of how Pretotypes can be created using non-technical deliverables like paper or blocks of wood. But whatever the deliverable is, the concept is to create a deliverable that can be used early on to collaborate with the client on the Art of the Possible and then to confirm the high-level scope and functionality without needing to get drawn into the details.
There is a a quote on the Pretotyping site which I feel adds additional clarity to the concept of Pretotyping.
“We did not invent or discover pretotyping; it’s something that a small number of innovators do naturally. As a matter of fact, our concept and formulation of pretotyping was formed by reading and hearing stories about such innovators and the evolution of their ideas. But what these innovators were doing naturally was not exactly prototyping; it did not have a name and we thought it deserved one. We initially coined the term pretendotype because the most unique aspect of this approach was to pretend or imagine the intended functionality. However, since pretendotype was a quite a mouthful, we simplified it pretotype. The concept of pretotyping is also very close in spirit and practice to Eric Ries’ brilliant Lean Startup Movement and the practice of building the Minimum Viable Product (MVP.)”
In Many ways Pretotyping shares much in common with the Agile Practices of Paper Prototyping and UI Design studio. In fact I would argue that a Paper Prototype or the output from a UI Design studio session is a Pretotype. What I find interesting is the possibility of being able to create a Pretotype technical deliverable (more on what these can be later) that can give the client more of a sense of the solution.
And to be brutally honest, I don’t think some clients would be as accepting of a Paper Prototype as a deliverable. Although we know that the value is inherent in both, some people may see the Paper Prototype as being less professional. The ability to create technical Pretotypes allows for the value to be realized while also addressing any client concerns.

My Pretotype experience

So now that we can see the connection between Agile, Lean and Lean Start-ups, and Pretotyping, what was my experience with Pretotyping?

1. A Pretotype is an incredibly valuable tool to be able to design and perform analysis on the large rocks of value for a project and solution without having to get drawn into details. It was a great tool to stay grounded in what value the client would realize as opposed to the colour schemes, particular fields, and other minutiae.

2. It is difficult to communicate to the client and gain agreement as to where exactly a Pretotype will stop and where Prototypes and other deliverables will continue. Although we tried to state as clearly as possible the boundaries, people are used to Prototypes and find comfort in the detail that exists in Prototypes. My only suggestion would be to continue to over-communicate and continue to discuss the differences between a Pretotype and Prototype. My other thought would be to use the actual term Pretendo-type to more overtly communicate the purpose of the Pretotype. (Some people may assume a Pretotype is a Pre-Prototype, while it is a totally different animal)

3. Although the Pretotyping proponents talk about the ability to use paper and other deliverables for the Pretotype, our clients required a technical experience to allow them to interact with the Pretotype in a manner that is similar to the potential end state. The good news is that there are plenty of great tools out there to create Wireframes that can be used to create Pretotypes. Be careful though, the use of these tools can increase client expectations as to how far the Pretotype may go towards being a Prototype.

I ended up using Iplotz as my Pretotyping tool and I was very impressed with the tool. It was very easy to use and also allowed for the all the functionality I required. Iplotz has both an online and disconnected mode. Iplotz also allowed me to group all my Wireframes into a project and let people collaborate of the project. The suite of controls was also very extensive. I have heard great things about Balsamiq as well. There are a multitude of other solutions as well. I encourage you to review the options and decide for yourself which fits your needs the best.

Summary

Pretotyping has definitely found a permanent place in my Agile toolkit. It won’t fit for every project and client, but I believe it will be something that I will use more often than not.

Re-posted from http://bornagainagilist.wordpress.com

About Terry Bunio

Terry Bunio has worked for Protegra for 14+ years because of the professionalism, people, and culture. Terry started as a software developer and found his technical calling in Data Architecture. Terry has helped to create Enterprise Operational Data Stores and Data Warehouses for the Financial and Insurance industries. Along the way Terry discovered that he enjoys helping to build teams, grow client trust and encourage individual career growth, completing project deliverables, and helping to guide solutions. It seems that some people like to call that Project Management. As a practical Data Modeller and Project Manager, Terry is known to challenge assumptions and strive to strike the balance between the theoretical and real world approaches for both Data Modelling and Agile. Terry considers himself a born again agilist as Agile implemented according to the Lean Principles has made him once again enjoy Software Development and believe in what can be accomplished. Terry is a fan of Agile implemented according to the Lean Principles, the Green Bay Packers, Winnipeg Jets, Operational Data Stores, 4th Normal Form, and asking why

Discussion

No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: