I've heard that it's not very often that a software dev team actually delivers a "start-from-scratch" project on time. I mean, let's face it. There are a lot of moving pieces and if just one gets out of place, the entire project is thrown out of whack. So, how then can a dev team possibly complete something on time? Well, since my dev team just accomplished a huge project and delivered it on time, I think I may have some insight.
It's all about having team work, being vocal, timing, early demo, realistic planning, work ethic and, of course, respect.
Let me explain.
From the mob programming sessions and the group Skype calls, to off-the-cuff team "water cooler meetings", there was a whole team understanding of what the project was and the plan to complete it. Daily stand-ups kept each member on board with what the other was working on (and in what environment to reduce the likelihood of code being overwritten). Problems were mentioned in stand-up and often led to an after-stand-up Skype call to discuss and address the issue. It really helps when the whole team applies KISS to stand-ups. ;)
My actual coding skills aren't the strongest so, when my team included me in the mob programming sessions, I was a little on edge. I mean, what could I possibly help with?! But wow. What an enriching experience for a tester to be in a room and hear the thoughts of these code geniuses and, as a team, contribute to the project as a whole. I cannot begin to tell you how awesome this was. And one of the best things that came out of those mobbing sessions for me was that when I didn't understand a part of the solution, my team would explain it to me. If I don't understand something, I'm not afraid to ask for clarification. And that alone enables me to become a better tester. My testing effectiveness is only as good as my understanding of what I'm testing, right? So, speak up and speak up early. This leads me to my next point.
I feel one of the most important things to do to deliver a project on time is to be early. Ask questions early: after a project is specked out, take a few minutes to read the project plan and jot down any (no question is a stupid question) questions that come to mind. No matter how insignificant you think it may be, ask it! As the project develops and code and testing are done, continue to re-read the project plan and ask more questions. We all know that once you dive into something, certain things start to make sense and more questions arise. Code early. As soon as it was possible, these devs began putting all the background pieces in place that they knew they'd need to get this project off the ground. Test early. Using KANBAN as the method for managing all items assigned to the team has been the "oil that made the engine run smooth". I cannot speak highly enough about how the Kanban process helped this team work together EARLY and enabled us to deliver the product on time.
Sometimes what looks good on paper, makes a terrible user experience during execution. That's why it is super important to demo everything as early as possible. On my team, we were all in charge of demoing whatever was available to the PM. I enjoy taking the lead on the task to demo because I get to add my UX advice on what I thought as a user when the steps are completely non user-friendly. When caught early, this can lead to lower dev costs and a better UI experience all together!
It helps to have a team (PM included of course!) full of reasonable people who don't want to bite off more than they can chew. You definitely need your dev team to be "small bite takers". When the project plan is delivered to the dev team and they commit to only what they know they can accomplish, timely expectations are met. And having the whole team included in the planning process keeps everyone on the same page and keeps a certain degree of team spirit going where everyone feels they are contributing to the solution. This is another crucial piece to getting software out on time.
A dev team who wants to deliver on time, will deliver on time. Make sure the drive to accomplish the end goal is there across the team. If even one person is slacking, the whole deliverable date is in question.
Everyone is creative. And in a team of intelligent minds, the last thing to do is limit creativity. There must be an enormous amount of respect within the team so that the way a solution is written is owned by the person writing the code. And if another team member has a different opinion, everyone should listen and work together on the best solution for the business. Respect one another's work. Respect one another's creativity. The open respect everyone had for one another on this team is another major reason why the flow of this project was continual.
So, there you have it. Seven helpful tidbits that I learned through experience about how to deliver software on time. If you use these suggestions and your project doesn't ship on time, perhaps I forgot to document one. Either way, these suggestions are sure to help the flow of a software project to be smooth, consistent, and constant.