A non-techie software development observation, part 1
About a year ago I set out to revolutionize the way the philanthropic grant process worked. I had a great idea for a tech company that significantly increase efficiency and save all nonprofits a lot of time and money. The only problem was…I’m not a tech guy. This problem of mine was kind of a big deal. So I read many different tech blogs to try to figure out what to do. Below is a high level over view of what I learned.
Disclaimer: The subject of this blog is about software development written from perspective of a non-developer entrepreneur.
To give a little background, traditionally, developers used a waterfall methodology to develop software. This methodology was taught in computer science classes all over the world and it originates from manufacturing (as the son of a General Motors assembly line worker, it instantly made sense to me). It’s when you have a step-by-step plan to build a product and to start one step you must have completed the previous step. For example, 
This method works well if you know exactly what you are building, like for example, a car or calendar pop-up reminder software. This method dose not work well if you and your team are trying to introduce a disruptive technology into a stagnant industry. The reason it does not work is because the steps are based off of an hypothesis and assumptions of what customers will want and leaves no wiggle room. Anyone who has tried to order lunch for a group of people can tell you how having a hypothesis and making assumptions of what people want to eat usually yields bad results. The same happens with software development. Instead of using a process that is set in stone, you need agility. Scrum development is an agile process that follows an iterative methodology.
[Scum is not as easy to visualize as Waterfall but its much more effective way to build a software product]. What Scrum has that Waterfall does not have is wiggle room. Scrum development is a series of iterations with there being a deliverable of a usable product in each iteration. Because there is back and forth communication between the development team and the customer, the development team is implementing customer approved value adding changes to the product. This is huge! (Wait…Why?) Think of your birthday and you receive a crappy gift from someone who didn’t ask what you wanted. That is what usually happens with Waterfall software development - you receive the end product and thats it. Now imagine someone asked you what you wanted for your birthday, and then would follow up with questions about color, size, etc. until they knew exactly what you wanted and how you would use the gift. Thats Scrum software development.
Why is a non-techie writing about software development? I am writing about it because Rethink Impact switched from Waterfall development to Scrum-light development (we can not fully implement Scrum due to lack of resources) and I see a positive difference. I think the biggest benefit for us is communication. In Scrum, the team is forced to have quick 5-10minute conversations that are a review of what was developed and obstacles faced, as well as conversations about whats next on the “short-term to do list”. As a virtual team, it helps everyone know what every other team member is doing and helps manage expectations. I am a fan of Scrum development and I look forward to the opportunity to be a apart of a team that cam implement the Scrum methodology a full 100%.
