Your last software project didn’t go so well. You are about to start your next one and you are not sure of what to do differently. You’re sure this time things will work out better. Unless, that is, you screw it up from the very start.
Assemble Your Team
Look for the best people for your team, but make sure they can work together. Size, complexity, technology, and the nature of your project will determine the kind of skills you’ll need. No matter what, though, things will turn out best with people who can work together.
Software development is a team sport.
You don’t want to lose time because somebody’s stuck and is trying to figure it all out on his own. It is essential to work with people who know when to ask for help.
This is true not only for the software folks. Regardless of the reporting structure, your team includes,
- Product Owner
- Tech lead
- QA engineers
- UI/UX designers
- Scrum Master
- Configuration managers
Pick the person best suited for each of these roles. Not only the most skillful, but also the most committed.
The Kickoff meeting is the first time that you will fully engage with your client. It is important to officially mark the start the project. At this meeting, everybody in the team gets to know each other and discuss everybody’s role.
A typical Kickoff meeting should cover the following,
- Team introduction
- Roles and stakeholders
- Known risks and issues
- Project objectives
- Criteria for successful completion
- Business objectives
- Responsibilities of each member
- Key milestones
Make sure that everybody’s expectations are clearly lined up. Success is not just about coding, it also involves these, among others,
- Code review actors and strategy
- Version control repository
- Continuous Integration/Delivery (CI/CD) environment
- Unit testing tools and environment
- QA strategy
Make sure all involved understand what are the tasks and activities required for the success of the project (e.g., you are not done until the unit tests are written and the code passes).
You also need to put some infrastructure in place right from the start, including,
- Local environments with required tools (e.g., Eclipse, Firebug, SVN, MySQL, etc.)
- Testing, production, and database environments
If you don’t measure it, you can’t improve it. You need to collect metrics (e.g., defects density, estimated vs actual effort, etc). Put these tools in place from the start and make sure everybody knows how to use them, what to expect, etc.
People who have no experience working in a Continuous Integration/Delivery (CI/CD) environment will significantly underestimate tasks at the beginning. It might take them more than a couple of Sprints to figure things out. Leverage the experience of the other people in your team to help them adjust more quickly and painlessly.
Use better tools, too. For example, your team can use Planning Poker to help the folks who are new to Agile adapt faster.
For more information, see 10 Steps to Making Better Estimates.
Start Your Engines!
- Sprint planning—this is a commitment driven planning session where the team clarify requirements, make estimates and decide what features will be completed during the Sprint.
- Product Backlog—Make sure that the Product Owner involves everybody in the team in putting together the Product Backlog. This will enable the team to move faster than if they are constantly surprised by new Stories they don’t understand.
- Pick a fixed time for your daily Standups and insist that everybody shows up on time. Keep it short and to the point. When questions come up, have them offline.
- Make sure your team makes accurate estimates, including architecture, design, coding (with unit tests), code reviews, and QA testing.
- Plan to automate as much as possible of your Continuous Integration/Delivery system.
- Your QA team plays an important role here. They’ll save everybody’s butt more often than not.
Ready to Succeed form the Start
You are going to be pressured to “start coding” right away. Don’t give in to it. Think of the pressure (and abuse) you and your team are going to be under if things go south. The last thing anybody in your team wants is to have to play hero in order to save a project gone off kilter.
The work you do at the start of your project will pretty much determine how well you will meet your goals. Perhaps more importantly, your team will be happier with the results and with each other.