Agile moving forward

My first experience of trying an Agile methodology was a hit, but we needed to fine tune our process a bit before we tried it again.

Our first step was to put together a template within SharePoint to help us gather and track the project information.   

Here it is.   

At the top there is a link to the Charter, which is just a Word document that captures things like:  

Scope, Business need, Goals, Product description, Assumptions, Constraints , Who’s on the team and their role, Issue, risk and change management, Test plan, Communication strategy, What does done look like

Below that is a list of the most recent documents in the document library (this is also where you will find a Microsoft timeline).

Below that is the project discussion section we used to capture meeting notes in (microblogging).

On the left hand side a link to the backlog:

Here is the information we were capturing in the backlog: 

Each backlog item has some key pieces of information which helps us put it into the right sprint and allows the developer to capture notes.

An Issues log.  As changes were made, and testing happened, if we ran into an issue we tracked it here.

Finally there is the test plan section that pulls the short description from the backlog item.

1 … 2… 3… go!

So with this in hand we started up our next Agile project, which was v.2 of our first Agile project.  There was one big difference with this project in that there was a constraint of  6 weeks to complete v.2 (which included a whole new section to the website, some code fixes, moving data to SharePoint to create a digital workflow with alerts).  And finally the killer … we had to use a QA representative to create a formal test plan.

We put together a small team.  3 expert users.  2 programmers (one php expert and one SharePoint expert). 1 QA rep.  1 PM/Scrum guy (me, it is funny how these mission critical projects keep landing in my lap).  

We started out with normal Agile methodology telling stories and breaking them down into backlog items (remember the backlog items are now in SharePoint).  Then we put together the timeline (keeping that must end by date in-mind).  Meetings were scheduled for the duration of the project which included Mon, Wed, Fri 15 minute status updates (what I did, what I’m going to do and a little show and tell) and one 1 hour meeting on Thursdays (short update, but more show and tell, workflow, reviewing requirements, reviewing documentation, expanding timeline tasks as needed).  

Again all of the meeting notes were captured within SharePoint discussion board and any changes to the requirements were also updated.

Part of our communication strategy was a short weekly update email (by me) sent to the executives (to calm their nerves about hitting the timeline).  Once we had a working prototype I included a short 5 minute video of the product in use (so they could really see we were making progress); this is a great example of using web 2.0 technologies to communicate the project status.

The project was a success!  We came in 2 days early and our client was happy with the results!  And yes, we did get cake!

Lessons learned. …

There were many email discussions about various parts of the product that were not tied back into the project site (it is possible within the SharePoint discussion boards to have an email address assigned to a project to capture project related email).

Timeline is still in Project.  For a project this small it wasn’t really an issue (20 tasks versus the normal 1000 I’m use to).

Small team of experts and many meetings was the key to the success of this project.  If we used waterfall methodology we would of blown by the “must end by date” before one line of code was written.

Project size.  Again this was a small project using experts who have coded similar products in the past.  This was key for the project to hit the end date or come in early.

Celebrating with the Team:

“The agile project management approach ensures constant communication and faster, transparent decision making.”  - Why Agile? And Why it is Not a Silver Bullet WHITE PAPER

Here is a nice overview of Agile:

http://www.projectmanagers.net/profiles/blogs/what-is-this-thing-called