Practices That Can Help a Software Project Succeed

Introduction

There are many pieces to the puzzle that make up a successful software development project — from an awesome multi-faceted team to realistic deadlines and requirements. Usually playing the roles of an individual team developer and a team lead of some sorts, I have noticed a pattern of some things we have put into practice over the years that have helped make projects successful. The practices are definitely from a developer & lead perspective and I share some of these ideas below:

Supply an Early Estimate and Project Plan

No matter what methodologies I have used in the projects I have been involved in, or the type (consulting fixed-bid or time-and-material, start-up company product, production web site, etc.), an early estimate on costs and milestone dates are always desired by someone sponsoring the project. Providing somewhat of a detailed estimate sets realistic expectations and attainable goals up front — even if just for the first phase of a large, incrementally-phased project. To provide such an early estimate I typically:

• Review the known requirements and wish lists for a project
• Have a whiteboard session with preferably one or more team members to:
  • Discuss requirements
  • Generate and get consensus of an idea for the application architecture, design, frameworks, and tech stack to some degree that will fulfill the known requirements
  • Create a task list of all known tasks including requirement time for unknown requirements, prototyping and R & D where needed, and other known details
  • Estimate the tasks in some fashion, receiving consensus from those involved
  • Quickly create a high-level sprint plan along with some assumption of team members skills and assignments
  • Share the high-level estimate in hours and a delivery-to-QA date
• Use these estimates and preliminary sprint plans as a starting point for the sprint plans that are created when the construction portion of the project actually starts

Create Project Communication Hub

Creating a communication hub to create, update, and find any information for your project is way more efficient for the project team than just using email and network shares. Also, it is great if versioning is supported, especially if documents have to be uploaded. I have been involved in many projects where team members (developers, QA, Analysts, etc.) have been added incrementally to the project and having the project hub set up has helped immensely to get people ramped up without draining time from team members already knee deep in a project sprint. These hubs also help support teams greatly after the release of the project, too.

• Preferably create a project wiki or web site, something accessible, readable, and searchable through a browser — budget, company security/compliance, and other factors may give constraints which may dictate what tools you can and cannot consider
• The Information Architecture of the site will vary from project to project, and might depend on the type of content on the site. I have found it more efficient to organize and categorize the information even if searching is available and especially if searching is not. For example, in the requirements category/page, you might just have a link to a requirements tool, but you might also have requirements documents and wireframes/high-fidelity application screens.
• Some Information Architecture categories and home pages that we typically include in the hub:
  • Project Plans (e.g., sprint plans, resource plans, estimates, home page with links to project tools, deployment plan)
  • Requirements (e.g., user stores, use cases, water-fall-ish spec, wireframes or hi-fidelity screens, sprint backlogs, issues lists)
  • Architecture (e.g., tech stack, application architecture documents and drawings, frameworks and patterns, abstraction layer information, etc.)
  • Design & Implementation documents (e.g., functional and component designs, database ERD diagrams, configuration information, etc.)
  • Testing (e.g., test plans, test cases, etc.)
  • Bugs (e.g., link to bug tool, bug lists)
  • Build and Deployment Info (e.g., build & promotion group or tagging policies, systems info that are part of deployment, deployment checklist)
  • Support (e.g., development environment set up, perhaps a site map for the communication hub)

Create Ramp-Up Documentation

At the beginning of a project, as decisions are made, development environments are set up, and things like frameworks and patterns are implemented, take the time to quickly document information that would be helpful to a new developer joining the project. Even if you do not anticipate new developers joining the project, whoever will support the project (immediately or eventually) will be grateful. Also, if/when someone unexpectedly leaves the project or is replaced, you will be thankful you did this.

Identify and quickly document (in some fashion) things like:

• The tech stack, application architectures, and frameworks
• Abstraction layers, transactional boundaries, and design/implementation patterns to follow
• Document how to set up your development environment as you set up your own development environment
• Document development/implementation policies — e.g., unit test policies, error handling, code reviews, etc.

Understand and Confirm Requirements

Whether it's agile or waterfall, and whether the requirements are well documented or not, it is wise to make sure you understand and confirm the requirements. My experience over the years has been that no matter how well-documented the requirements are perceived, there are always missing details when you actually start implementing the solution. Asking questions and confirming our opinions and thoughts during implementation has resulted in very happy stakeholders at the end of the project.

Don't:

• Make assumptions
• Be a know-it-all or think you know what is desired when it isn't clear — you may actually know what is best and be correct, but confirm it with the stakeholders

Do:

• Listen carefully while eliciting or confirming requirements and read carefully while reviewing documented requirements — take notes!
• Be efficient and make lists of questions and push for and participate in reviews with stakeholders — even if that is during software deliverable review sessions as opposed to official requirements reviews
• Take time to prototype and provide options for cloudy requirements and to help define better requirements and implementations

Help Define & Implement Missing Requirements

Do not use missing requirements as an excuse to ignore things you know (as a developer) that are necessary to implement. Expose the fact that the requirements are missing and help define them. Important requirements like error handling, different kinds of performance, concurrency/load, and forms validation have been missing from many projects I have worked on but we always push to get them defined and implemented. Otherwise, what we would have delivered would have been a disappointment.

• Identify and help define important, technical requirements for things like performance (e.g., application latency, API latency, batch processing time, etc.), validation, error handling, concurrent usage, bad data, client platform requirements, etc.
• Make time for these missing requirements as part of the implementation plan
• Regarding bad data – when dealing with someone else’s data via some integration or pre-existing data that is out of your control, it is a good idea to consider worse-case scenarios and handle them in the requirements and the code (e.g., null fields, incorrect formats, missing “required” fields, etc.). In fact ,we have typically implemented some type of flag in the log files and sometimes in the UIs (when appropriate) to indicate that there is a data problem to be resolved but we have made sure the system as a whole still functions in an acceptable manor.

Be a Considerate Team Player

As a team lead:

• Don't be a dictator, try to involve the team in team decisions — ask for ideas and input, but make decisions when no one will.
• Identify people’s strengths and weaknesses so you know how to integrate them into the team — don’t try to make someone something they are not during the project, but do try to give people the chance to grow
• Make time to help those in need. For example, take the time to pair-a-design/-program with junior developers. Code reviews can help too but the up-front pair-a-work-together sessions can be more efficient on tight schedules.
• Be selfless. Ask people what interests them when assigning tasks and don't save interesting tasks only for yourself

As any team member, be transparent, patient, and know your strengths and weaknesses:

• Let the team know if you need help but have your thoughts/questions in order before interrupting other team members if on a busy project
• Let the team know if you unexpectedly finish something early — someone always can use another set of eyes on a problem or it can be helpful to get out further ahead on a future sprint task or new requirement
• Give yourself some set time to figure something out — whether it be prototyping something brand new or resolving an issue or enhancing existing code — if you exceed the time, ask for help from the team
• Don't panic if things are taking longer than expected, be patient and don't just, “get ‘er done.” If you are running short on time, make sure to test what you implemented

Be Your Own System Tester

Something that I have seen many developers hide behind can be summarized in the statement, "I can't test my own code. It is a conflict of interest." I have also seen some developers write new code, unit test it, but never system test their implementation and then they're surprised it didn’t work as anticipated in the context of the application when someone else tests the application.

I have been a member of several startups, software product companies that have large QA groups, and, most recently, a consultant that engages with many different IT departments and some product companies which may have or may not have formal QA groups. Throughout these experiences I have found it is always better to system test what I have implemented in addition to any other testing that I -- or anyone else -- has done or plans to do. Knowing the different branches of logic, I perform somewhat of a white-box system test and make sure the implementation meets functional and quality expectations myself before handing the release over to others to test.

Besides the obvious up-front time-savings to the project, this testing has saved me time in the long run because formal testing happens some time later at the end of the sprint and/or at the end of the project. It is better to find issues earlier while that code is fresh in your mind rather than have to dig back into it days, weeks, or maybe even months later.

Hold Stakeholder Implementation Reviews

Whether your project is following an agile approach or something else, make sure to iteratively review what you are building with the stakeholders. Some advocate end-of-sprint reviews; however, several of my projects over the last few years have been holding weekly stakeholder reviews as soon as we have something the stakeholders can see.

Such meetings have been instrumental in making the projects run smoothly and making the final deliverable meet expectations of everyone involved, especially the main stakeholders. Yes, new requirements and changes are many times exposed during these meetings, but also many undocumented requirements and questions get resolved in those meetings very quickly and efficiently. Project timelines and task estimates can dictate if new scope can be handled or placed on the backlog for another sprint of the same or future project.

Do not hide what you are developing until the end of project; review what you are developing often and throughout the project implementation.

Set Up a Continuous Integration and Unit Testing

Whether following the "test first" methodology or not, take the time to set up a continuous integration and unit test environment.

Especially on large development team projects, the continuous integration environment that automatically builds and deploys to test environments while running automated unit/integration tests can be very helpful in finding issues early in an integrated environment.

Always Design and Implement with Support/Maintainability in Mind

Many agile developers preach about implementing only what is needed at that moment. However, I don’t think you should have to give up maintainability with that mindset.

If not for others, I recommend designing and implementing with support/maintainability for yourself. I can’t tell you how many times in my career I have hit a comment I wrote or a good design I implemented a year or two earlier and was thankful for it in that new moment. I also can’t count the times I have had to reverse engineer other peoples’ code that were no longer part of a group or project and spent a good chunk of time understanding it since maintainability/support wasn’t really a concern for the original author. Then due to the implementation state, I had to unexpectedly refactor that code to support what I was currently implementing.

As a consultant I am often re-hired by the same clients with gaps in between my assignments with them and I always appreciate when I hit some easily expandable and maintainable code I or another team member wrote on an earlier project.

Hold Bug Reviews

Push for and participate in bug review meetings and include as much of the cross-functional team as possible (e.g., stakeholders, BAs, PMs, developers, QA, etc.).

On most software projects I have beeen on, a time seems to come when we are inundated with bugs (a lot of the issues are usually requirement changes or enhancement requests). Whatever the case, I have found it extremely efficient and helpful to get in a room and walk through the bugs with the whole team.

Sometimes different team members fear having a bug review meeting with the whole team — particularly with the stakeholders — because the fear is that that scope creep will prevail. However, my experience has been that as long as we can explain the technical and time challenges accurately, everyone involved gets on the same page and is realistic and quite flexible in regards to what can and can’t be done within the new scope. The results of the bug meetings typically are great — bugs are understood, prioritized, closed, some are put onto a backlog list, trades and compromises are made, etc. Most often the team feels good about working together and making progress.

Empower Project Management

Typically a project manager or development manager is part of your project. No one knows better than you about the intricacies of the system you are implementing. So take time with your PM or Manager to engage them and empower them to help you and the project. Time spent with your Project Manager will help increase trust in the team and make the project run more smoothly overall.

• Be transparent and expose issues but also describe and provide options — be realistic too
• Be humble and patient, in explaining issues and technical details
• Something specific that has been very appreciated by PMs on many past projects is to make deployment checklists that identify deployment tasks in sequential order and responsible team members. We typically provide these details then the PM has taken over maintaining and getting team members on board once it is all understood

Conclusion

I hope these practices offer you some ideas on ways you can improve your software projects. Most of these items are common sense, involve team communication, and ask that you be conscientious, considerate, and thorough with your team and your development efforts. These things are worth the time and effort it takes to implement them and have proven their value in many successful projects.

From a developer perspective, these items might not be interesting from a technical standpoint, but if you follow these practices you may free up more of your time so you can spend it on the more technical project issues. You and your team will also likely experience less crisis and surprises during the project and will surely help you experience a successful project delivery.