Agile Prototyping to Confirm Requirements

Why did we want to meet with them when we had a (very clear) 250 page RFP document?

Because face to face communication is far better than any other form. People communicate with their whole being; they nod in agreement, and show excitement when they "get it". Significantly, they display hesitation or confusion when something is unclear and that allows us to repeat or ask questions.

First Features Go-Live Tomorrow

I'm writing this at midnight on Wednesday evening and the team will invite the first users onto the sites tomorrow so they can give us feedback on the structure and layout. Let me put this in another way:

We have done a significant piece of work, and if the client is satisfied with it, they will start using it on Thursday.

What Did We Really Do?

This is quite shocking to people until they start experiencing the benefits of Agile methods, so some explanation is required. This is the background, steps taken, and what will be delivered:

• No development work was done before the meeting, but there had been three days of reading the documents and discussion within the team.
• We created, estimated and prioritized  a set of tasks that would need to be performed
• One of those tasks was to produce a demonstration
• The platform had been selected (SharePoint), so an online SharePoint farm was provisioned in readiness. This was built from scripts and took about 30 hours. The build was started late on Tuesday afternoon.
• As the solution architect, I implemented my first draft design of the site collections, portals, sites, and sub-sites. I customized a few of the home pages to show the specified site names.
• There is nothing like "on the job" training, so one member of the team, who is new to SharePoint, worked together with me, until he was comfortable enough to take over the task of creating the menus and site navigation.

This early phase of work is really important because it tests the architecture, implements the stated requirement, and allows the client to see if what they asked for is actually what they want!

Until the client has approved this or a proof of concept, it is not worth investing in any more development, because the cost of making changes rises very rapidly once the site architecture is in place. However, you cannot design that architecture without building and testing it, which is the very nature of Agile – understand, build, test, refine, understand more, build more, test more, repeat until done.​

Delivering Packets of "Done"

The overall project we are tendering for may take 12 months or more to develop, and skill that successful Agile practitioners develop is to divide larger components into their smallest units of functionality and value to the business.

Tomorrow, we will deliver the following:

• Overall site structure showing navigation between business areas and sites
• Public internet website with home page and live blog
• Web Portal intranet site with authentication for two (real) users
• Three directorate sites with test users from each, all with appropriate access rights
• Extranet site for partners and consultants with one test user
• A process for deploying the application

Benefits to the Client​

The only working functionality here is the blog, so what are the benefits to the business?

• Users can start getting used to the new system – early adopters and champions emerge
• Builds interest and buy-in for users – who actually see something happening quickly
• Proof of design – reduces risk of doing more work on something that turns out to be wrong
• Proof of architecture – better to discover early if users can access the site
• Proof of performance – and get an idea of the performance doing something real
• Proof that the development team can deliver to a forecast – builds confidence and trust
• Business can prioritise the next feature for development

That's about it for this blog post, so all I need to do is publish it to that shiny new SharePoint farm of ours.