IT Project Tips and Tricks - 03 - Methodology

An IT Project Methodology describes how project work is identified, documented, assigned, tracked, tested, and deployed to end users.  At the start of my career, there was no true use of methodology. Requirements and tracking work was done in an ad hoc manner. A waterfall approach was used where all requirements, design, coding, testing, and deployment were done in their entirety one after the other.  This did not work well because by the time we got around to testing and the end users saw the app for the first time, often they would say, 'Hey this is not bad but really, it's not what we wanted, we wanted it like this instead, bla bla bla.' But by then the app was coded 100%, so it was too late to go back and do a rewrite because it would be too much work.  In the end, we would patch the app with band aids to give end users something resembling what they really wanted. 

Later in my career, I was exposed to several methodologies including Method1, RUP, and eXtreme/Agile. In the end I settled on using an Agile methodology that borrowed some artifacts from RUP. Here are the steps briefly. Note that a lot of these steps are discussed in more detail in other articles.

• Initial Use Case List - create a list of every use case in the app described at a very high level, no more than a few sentences per use case. Estimate each Use Case using an abstract unit like Points to determine total number of Points in the project. I prefer to use Perfect Days instead of the very abstract 'Point'. A Perfect Day is 8 hours of uninterrupted work by an experienced developer. Come up with the total number of Perfect Days in the project. Remember this is NOT the actual number of real days in the project. 
• Your project will be made up of Sprints and Releases. Here is how I define them:
• Sprint - a chunk of time (I use 3 weeks) during which a certain amount of work will be attempted. In my opinion, two weeks is too short to get anything done. Note we do not necessarily deploy the app to end users for testing after a Sprint, which is what a Release is for. 
• Release - A release of the app to the end users for UAT. A Release can contain 1, 2 or 3 Sprints depending on what the Release is targeting. It should be like a package of related use cases that go together for testing to the end user.  It is done at the end of the last Sprint in the Release.
• Project Plan (E0) - based on the Use Case List, plan how many Sprints and Releases you will have. This is a pure gut feel E0 guesstimate. To do this, calculate an estimated completion date by guessing at an average Sprint Velocity for the team and divide that number into the total number of Perfect Days in the project to determine how many Sprints there will be. This is your E0 and dont worry, IT WILL CHANGE.
• Example: 
• Project has 800 Perfect Days
• Guess Team Sprint Velocity - look at your team and assess how many fast people you have vs normal vs slow and take a bold guess. You will get good at this with experience. A Team with 5 people maybe 2 fast, 2 med and 1 slow in a 3 week 15 work day Sprint might go like this:
• Fast - 10 P Days in Sprint x 2 people= 20
• Med - 7 P Days in Sprint x 2 people = 14
• Slow - 4 P Days in Sprint = 4
• Total is 38 P.Days done per Sprint
• Project will have 800/38 = 21 three-week Sprints = 63 weeks
• Arrange your Uses Cases into Packages like this to identify Releases
• Team Setup - 1 Sprint
• Login and Data Support - 2 Sprints
• Security (Roles) - 2 Sprints
• Related Entities Maintenance 1 and their Processing use cases- 3 Sprints
• Related Entities Maintenance 2 and their Processing use cases- 4 Sprints
• Related Entities Maintenance 2 and their Processing use cases- 4 Sprints
• Interfaces to other systems - 3 Sprints
• Data Conversion and Roll Out - 2 Sprints
• Execute Sprints - I pretty much used the Agile approach
• Sprint Plan to assign work to everyone
• Daily Stand Ups
• Sprint Retrospective - I just sent an email letting the team know how many Perfect Days of work were done and any impact to the End Date.  Again, the End Date calculation is done by diving the total number of Perfect Days left in the project by the average Sprint Velocity giving you how many Sprints are required to finish the project.
• Tips:
• In Sprint 1 velocity is low because you are doing things like setting up the developer machines and the different environments and such, so don't calculate a new project end date here since it will freak everybody out.
• In Sprint 1 there are no Use Case documents yet as you are mostly working on requirements gathering, so DO NOT ADD DEVELOPERS to the team yet because they will be idle and chew up chargeback hours. Add developers as Use Case documents become available to code.
• In general, in a Sprint you have Requirements gathering for the next Sprint, and the Developers work on requirements that were created in the prior Sprint.
• By end of Sprint 3 everyone should be humming, and you need to be close to doing the first App Release to the End Users for UAT - that is your main goal at the project start and treat it almost like a Production Release because this is the FIRST REVEAL, and you WANT TO MAKE A GOOD IMPRESSION.
• Do a Release to End Users for UAT if it's time for it.
• Put a label in Source Code Control and release to the UAT environment.
• Add any bugs or additional work needed based on user feedback to the Project Plan
• After the first Release goes out, you will get an idea of Team Velocity how attainable the E0 End Date is - recalculate a new End Date and set expectations.
• Move one of the later Releases in the project to the Production environment just to make sure the Production env (servers and databases, etc..) works before the go live.
• Do the Final Release and Production Roll Out
• Create a Production Roll Out Plan with data conversions, cut off times, etc...
• Spend the first week in Production physically alongside the End Users and assign bugs and fix them ASAP with Emergency Releases.

Note: Other Articles will cover much of the above in more detail.