Projects are like trains: getting the train to the station on time is the goal of a good development team. In my experience, there are 5 key paths towards guaranteeing your passengers (users) and crew (dev team) have the best outcome possible.

Make time:

The easiest way to be on time is to give yourself enough time.

Typically scrums should be limited to 15 minutes and should determine the status of a project.  But what if the team updates uncover that a team member is blocked?  Stopping scrum because the 15 minutes are up may not be the best solution.

When scrum reveals the project is not going as planned, then and only then is the time to get things back on track.  A lack of time because of competing responsibilities like other projects will only heighten the issue and prolong the solution.  Roadblocks are best addressed the minute they arise rather than delaying for another scrum or for some later time.  Postponing a discussion and potentially a solution will leave a team member completely stalled unless they can move onto another task. The lack of time and, as a result, lack of commitment to a project will cause the project to go off the rails and fall behind schedule.

Solution:  Create more time to kill blockers! Stop scrums the minute a blocker is presented and discuss the problem(s) and the best way to a resolution of the problem(s).  Pull the team members that are blocked aside for further discussion, then with the limited members, determine a solution to unblock the project and allow development to continue unobstructed.

Consistent Resources:

A lack of resources at some point will force a project off the rails, resulting in missed deadlines and/or deliverables.  Identifying the lack of resources or that resources are constantly reshuffled on and off a project is of particular importance.  Shuffling resources on a project could potentially snowball into much larger issues such as loss of familiarity with the project and a constant need for new team members to ramp up on the project.

If you find that other more urgent projects pull your resources away, over time it will cause your project to derail.  When people are reshuffled in the middle of a project there will be a noticeable loss in the knowledge of the project.  Previous scrum discussions and side meetings hold the key to understanding project tasks comprehensively.

Solution:  Insist on keeping the project resources together on a project and committed to each other and the project.  The camaraderie from working together and shared knowledge of a project is extremely valuable to the success of the project. It is understandable that under certain circumstances resources may need to be shuffled, but minimizing the shuffle is most often the better option.

Complete Requirements:

Missing or incomplete requirements are analogous to broken train tracks and can effectively cause a derailment and delay.  Functional requirements established during the discovery phase of a software project establish the agreement between your team and the customer on what the resulting application is supposed to do.  The full and complete requirements play an important role in the success of your project.  If missing requirements are uncovered during the scrum, it should immediately be escalated to the Project Manager and the project’s Software Architect.  No time should be wasted to gather the needed data since it will have the potential to affect the status, pace, and scope of the project.

Solution:  Immediately schedule a meeting with the Project Manager and Software Architect to discuss missing or incomplete requirements.  It may be necessary to bring the client in as well. It can look poorly on a project for missed requirements to come up when work has begun and time is of the essence.

Open, Comprehensive Testing:

Quality Assurance (QA) and User Acceptance Testing (UAT) is a way to confirm the project’s destination.  If the result of the tasks that make up a sprint don’t get you where you were expecting to go, then you are going to be frustrated and extremely disappointed.  If your team is not provided with a complete set of testing scenarios and or you don’t have a fully allocated test environment, then you cannot be assured that you have met the real-world scenarios according to the project specifications.  Services that are not testable or have limited results often times will not provide a complete set of test results needed to confirm all test cases uncovered during discovery.  It is best to map out all stops along the route to confirm the destination before you step foot on the project train.

Solution:  Confirm during discovery that testing environments are properly set up and testable and can return the results needed before you pass off the project to UAT.  If you can’t test all user case scenarios, then document the limitation for the tasks so that the team is not held responsible for missed requirements.

Create a Dedicated Development Sandbox

Testing environments are just as important as QA and UAT testing.  Lack of dedicated testing environments is like a train without a track.  In order to fully test and merge code, the appropriate environments are critical.  Development should be completed on local sandboxes so that any testing can be locally restricted and not interfere with other development and testing tasks.  After coding is completed and reviewed, the code should be merged onto a development sandbox.   The development sandbox should be for testing and limited to code additions and changes that are targeted for a given sprint cycle.  Then a staging sandbox is next for UAT and regression testing to confirm new code doesn’t jeopardize the live production environment.  And lastly, the production environment is for fully-tested and client authorized code.  Separating these functions are critical for a smooth and secure software development environment. When these environments are not provided, i.e. development is not separated out to specific and timely releases, the result can be like riding on a train without an engineer.  No one is steering the train and we all know how that can end.

Solution:  Insist that your project has the correct and appropriate development sandboxes.  Don’t set up a project and team members up for failure and a potential train wreck when experience shows that all components, the train, the track, the crew and the passengers, are all guaranteed a safe and speedy destination.