All software companies use a development methodology. At Simplifya, you should know that we use the Agile Scrum methodology.
The methodology is generally a reflection of company culture. The State of Colorado and most government entities, for example, are traditionalists that are most comfortable with the waterfall methodology – heavy requirements and project planning, development in a vacuum, deliver at the end. I didn’t like it, but had to admit that it fit the legislative process well.
At Simplifya, the method is a reflection of, well, to be honest … me. Prior to my arrival, the team had a patchwork methodology that incorporated several different styles. I firmly believe that all tech start-ups should be using the Agile Scrum methodology. Thankfully, John and the team in Sri Lanka were eager to adopt it!
A working description of Agile Scrum
Scrum has many nuances that I’m intentionally glossing over. This is just the high-level stuff that is likely to come up in business conversation. Agile Scrum is a development methodology with the following attributes:
- The scrum team consists of a Scrum Master (facilitator), Product Owner (someone who represents the user), several developers (3-5 based on type of skill required), and a QA Analyst (tester). We currently use one scrum team.
- Work is organized into iterations called sprints. We use two-week sprints.
- Sprints always start with a planning session to decide what work will be tackled and end with a review session to demo what was completed.
If you’re interested, the infographic below does a nice job of filling in some of the nuances.
The benefits of Agile Scrum
Of the many benefits of Agile Scrum, some are particularly helpful to Simplifya:
- Two-week sprints mean we can deliver new versions as often as every two weeks. This is critical because we’re learning about the strengths and weakness of our software at least that fast.
- We don’t waste time trying to plan our work in detail beyond two weeks. At a start-up, you need to be able to change the work content for the scrum team as priorities change.
- We don’t waste time trying to write detailed requirements, project plans, or testing plans. We do those things in smaller chunks that allow us to begin moving forward quickly (be agile) and then fill in details along the way and only as needed.
- We can measure the velocity of the scrum team – the amount of work that is completed in each sprint. This allows us to build a reliable road map (this feature will be released in that time frame), analyze performance (our velocity this sprint was X% below/above average), and plan strategically (we need X more scrum teams to support that new line of business).