Software lets us bring new and innovative ideas to life easily. Today we use plenty of applications in our personal and work life. With the tools and technology of the day, developing an application is the easy part. Anyone with coding skills can hack something together or one could approach a dev shop like ours to execute on an idea. But the results though are very mixed. Some projects end up being beautifully successful while many projects get delayed and end up in failure.
If software development is easy, why then are there so many failures? There can be many reasons why a project fails. The team’s (including clients in many cases) lack of understanding of what they’re building, poor communication practices, lack of direction and gelling are some of them.
Something that can help mitigate a lot of risk and indecisiveness in projects is what people call – a process. I’d like to share in this post, the process that has worked for us at Spritle for quite a long while.
On a high level, you can call what we follow as an agile process. But we’ve tweaked and improved our process with years of experience and feedback and I thought it would be useful to share it with everyone 🙂
You can just scroll down to the bottom to take a look at our process. But before we go there, I’d like to share few very important things that are crucial for maximizing the changes of success.
Who’s in a team?
Most teams are composed of just the Product Owner (the venerable client) and few developers. But we recommend having few additional roles in the team who can prove extremely valuable. They are –
- Project Manager (PM)
- Business Analyst (BA)
- Quality Analyst (QA)
For small teams and short projects, having a PM and a BA would not make sense economically. That’s completely alright but in such cases, we recommend that the QA take up those roles and fill the gaps.
On the board
We use a Kanban board to track our sprint progress. It’s a workflow visualization tool that enables us to optimize the flow of our work. Just by having a glance at the board a person could know the status of items in a Sprint and also who’s working on what.
What to build?
Discovering and understanding what to build is one of the most important exercises in a software project. We recommend that this be done as a team (Client, BA, PM, QA & Devs) sitting together. This should involve asking a lot of questions and exchanging ideas and suggestions. This is the phase where all our ideas are in thought form and hence are infinitely malleable and we should take complete advantage of this phase.
During this process we highly recommend building wireframes and prototypes to make sure everyone on the team is on the same page and has the same expectations about what’s going to be delivered. I can guarantee that wireframing can save hundreds of hours of rework and thousands, even millions of dollars in the long run.
Wireframes and prototypes let everyone get a feel of what’s going to be built and helps refine and even change the requirements. And changing requirements at this phase is very cheap. This is what management gurus call – Thrashing Early.
Kicking off
In sport or game, there is a fixed duration for game play and we call such periods as sprints here. Before starting a sprint, discuss as a team and pull tickets from the backlog, estimate and work on it. We make sure that we only pull items into the sprint for which the requirements have been fleshed out well and also we make it a point to break tasks down into very granular sub-tasks, which helps us track, build & deliver better.
While we’re working on a sprint, our team is also planning and fleshing out items for the next, future sprint. This makes sure that once the current sprint is done, we have items lined up in our backlog to kick start the next sprint. Also, we have a two to three day gap between our sprints for planning.
Draw the art
Let me share our current process art flow
Finale
I hope you enjoyed reading about the process we follow in our team. I must note that our process is not something that was dreamt up in a day. Rather it’s a living and breathing document that we continue to tweak and change depending on how our project and team is doing. When you’re adopting a process, make sure you’re doing the same.
There are many other things that help a project succeed. I’ll continue to write about things like setting priorities, status and report emails to stakeholders, team rituals and other tips and tricks which I hope will be useful to everyone.
Do share your thoughts in the comments below. Do you follow something radically different? We’d love to know about it.
