Matthew Chestnut is a Senior Consultant at ThreeWill. He has over 20 years of software development experience around enterprise and departmental business productivity applications. He has a proven track record of quality software development, on-budget project management and management of successful software development teams.
There is nothing like starting a new project to remind me of the best practices ThreeWill follows regarding project management. Whether the project is truly brand new, or we are working on an existing project after it has been in production for quite some time, the best practices I discuss below are from my perspective as a senior consultant at ThreeWill, practices that quickly help me be quickly productive in getting the proposed work done.
My primary goals with a project are to…
- Complete the project on time and on budget with the feature set we’ve committed to.
- Leave enough information behind (project artifacts, developer notes, documentation) so in the future, if we revisit this project, we can get started quickly.
The first goal is the customer deliverable, the reason the customer came to us for guidance.
The second goal helps us at ThreeWill … in the future, we may have to do some additional work on this project!
How do we at ThreeWill manage complex projects that will last for years, are subject to continual improvement and are worked on by numerous consultants?
Here’s how we do it at ThreeWill:
- Accurate Product Backlog
- Tools and technology
- Source control
We follow Scrum Methodology for project management, an agile method for software development.
The product backlog provides the guidelines I follow for the features and functionality needed for the product we’re developing. This backlog is populated with user stories that describe the functionality from the perspective of the user or customer.
These backlog items should be clearly written and complete, so there is no question as to the scope of what will be delivered. By reviewing these backlog items, I understand what needs to be done. We organize the backlog items into sprints, committing to complete the work along with a timeline that the customer agrees to.
Tools and Technology
We use Azure DevOps (Visual Studio Team Services / VSTS) to manage the backlog, sprints, and sprint tasks. This is the primary tool in our project management arsenal, giving us a window into the status of backlog items and the status of our current sprint.
From this Azure DevOps repository, our scrum masters can generate the necessary status report data to provide feedback to our project stakeholder, keeping them apprised to the status of the project.
Everyone should be using some form of source control for their projects. Having versioned code, scripts, provisioning data, and other development artifacts is just common sense.
A key point, however, and one not to be taken lightly, is to make certain that source control matches what is in production!
This may sound obvious, but, sometimes, reality gets in the way of what should be done. Certain things like changing the configuration settings directly in a production system may be “quicker” than going through a more formal process of making the change locally, testing the change, committing the change to source control, and then deploying the change to production. But, after a few of these “quick” changes, what is represented by the source code repository no longer matches what is in production, potentially causing quite a bit of confusion in the future if additional changes need to be made.
I’m not necessarily talking about end-user documentation. Rather, I’m referring to the type of documentation that developers need to be productive, and quickly!
I am a big proponent of annotating the steps involved in bootstrapping a development environment from “nothing.” This is one of the first things I look for when beginning a project for which we have already value in the past.
The items I capture in this documentation include:
- What environment is this product running in? What operating system is needed and what features need to be activated?
- What developer tools (and versions!) are needed to build, deploy and run? What third-party libraries need to be installed? Provide adequate detail. For example, don’t just say “install Visual Studio”, say “install Visual Studio 2017 update 5”. When using technology that changes rapidly, the version used today will be something completely different in a couple of months.
- Are there any “tricky” implementation details that aren’t obvious to a casual observer? This is often true when dealing with application authorization, application state changes or complex processing. For example, if the user interface changes behavior based on who is logged in or what has been done to an item, sometimes the rules behind this change in behavior are not obvious, so document them.
- Note how to build and deploy the application. If there are any manual post-deployment tasks that need to be done, make note of them.
Application testing is important, and a working application is critical for user acceptance.
In this instance I’m referring to “environment” testing, applying the information gathered in documentation and verifying that following the documented steps results in a development environment that can be used for issue remediation or feature development.
This means taking the time to carefully vet the instructions, while they are still fresh on your mind, to make sure that in the future when you must resurrect the environment to make changes to the product, you can do so quickly and without delay.
I accomplish this testing by creating a new virtual machine and going through the steps I outlined in the documentation. Or, I pair with another consultant who does the same. I can then make additions and corrections to the documentation to clarify any ambiguity.
When you start a new development project, are you thinking about your legacy, about what you are leaving behind, to help those in the future pick up where you left off?