To those in the trenches getting their hands dirty writing code and implementing, designing, and engineering real-world software, smooth and painless development projects often seem like unicorns: Rarely heard of and more rarely seen. Given how often we tend to hear of or are directly involved in software development projects that run into problems, we can find ourselves searching hard for true and measurable successes. In this environment of uncertainty, it is to everyone’s benefit to step back and thoughtfully consider what it takes to be successful and to learn from those failures we’ve perhaps been a part of and witnessed during our careers.
To understand what success looks like as a software developer, let’s take a contrarian view for a moment and consider briefly what issues may potentially cause failure:
a. False or unrealistic expectations.
b. Lack of time and/or unrealistic milestones.
c. Bloated or insufficient requirements.
d. Lack of funding.
Taking these examples as a whole you might think you now have a template for failure; that is, now you know “what not to do” – and how often have you repeated that thought to yourself? The issues that may have stalled a particular project before are with the proper development and project methodology easier to identify and work past. Whatever the sins of the past, the good news is that the bad habits exemplified in the above list can – with proper focus using development and project management methodologies – be fixed and the dilemmas created by them remedied by a solid, collaborative, and balanced development plan.
Our experience as developers may hone our sixth sense of when a project might be stalling or falling apart, but even our awareness of the warning signs that could lead to failure does not automatically set the stage for success. Success is not as simple nor can it be immediately qualified by a well-balanced project management triangle. Having a quality team, a plan of attack and a method of bringing all of those pieces together are all critical components in realizing a project’s success.
To routinely achieve and practice success at Scalable Path we use the Scrum software development methodology. Scrum as a methodology is simple and its methods repeatable, but its disciplined and daily practice isn’t necessarily so easy. One of our primary goals at Scalable Path is to use Scrum as a truly relevant methodology for driving projects through to completion and to deliver client satisfaction.
What makes Scrum so effective? Scrum facilitates communication by creating feedback loops. We want developers to stay in sync with each other and we want the customer to stay in touch with the development team. We also want to create cycles of development in which the customer can see tangible results and give feedback early. There is nothing like working on a deadline for months only to find out the customer was anticipating a different result. Scrum’s methods are designed to help eliminate gaps in the development team’s understanding of what a customer wants so the project’s goals are achieved quickly and transparently.
With this background in mind regarding what is achievable with Scrum in the abstract, let’s get down to some specific tips that will help you and your team effectively use Scrum methods successfully:
1. CLARIFY, CLARIFY, CLARIFY
You are in a meeting and the conversation is going back and forth. Everyone else says “Great, makes sense to me.” Problem is, it doesn’t make sense to you, but you don’t want to be “that guy” right? Well don’t be embarrassed and don’t be fooled into thinking it made sense to everyone else. Clarity is everyone’s job and getting clarity later is usually more expensive. Once you have clarity, document the decision.
2. USE THE RIGHT TOOLS
Everyone has their bag of tricks, their go-to tools. I personally like the combination of JIRA Agile combined with Stash, but there are many other great tools out there that will help you do the same thing. If possible find something that allows you to visualize the status of a sprint like a Kanban board. Tooling for code reviews is really important too. If it’s too hard to do, it won’t happen. The right software doesn’t have to cost a fortune, but it can make a big difference in the success of a project.
i. Use JIRA, Podio & alternatives for code review
ii. Use Git for development and remote collaboration
iii. Use Slack for communication and integrations (JIRA’s integration with slack has made all our lives easier)
iv. Use GoToMeeting/Google Hangouts, Appear.in for remote communication.
3. WRITE GOOD STORIES
Don’t just assume everyone will remember every goal and nail every feature discussed in a meeting. After talking about a feature, it’s easy to walk away and forget the details about the decision that was made. It may seem obvious, but it’s not usually done well. This goes back to tip #1, lack of clarity is one of the biggest problems you can have. So write good stories and keep them up to date.
4. TIMEBOX YOUR SPRINTS
When you decide on the length of a sprint for your team, it’s best to keep to the agreed-upon length (1 to 4 weeks max). Don’t just stretch the length willy-nilly. If it’s two weeks, don’t extend the sprint to three weeks because a certain feature needs to go out. The sprint is your cadence, your rhythm section. It helps to maintain momentum. A sprint carries a certain degree of mental baggage with it too. Now, if you are starting to sputter because you think I’m missing a very important point about releases and deadlines, stay with me, that’s where my next tip comes in.
5. DECOUPLE THE IDEA OF A SPRINT AND A RELEASE
Is a sprint the same as a release? It’s easy to think of them as the same thing, but how often do you release a hotfix mid-sprint? Or what about Continuous Deployment? You can certainly deploy more than one time in a sprint. It really comes down to QA, and if you plan to do rapid releases, you’ll probably need to invest in your test automation.
6. DRINK THE KOOL-AID
Writing software is a challenge. It’s especially hard when developers and company stakeholders have completely different ideas about how it should be done. Scrum is a tool that works best when everyone agrees to buy into the process and drinks the Kool-aid together. One way that may be helpful to get buy-in is for people in various positions of the company to take Scrum training. It may seem like a costly expense, but it’s really quite reasonable and more cost-effective than building software nobody wants.
Even with the best methodologies, the best tools, and the best people, your success as a Scrum practitioner isn’t a guarantee. The right people and right idea don’t always and automatically translate to success. Creating successful products is a combination of great talent, right culture and clear lines of communication. It’s often more art than science. People will often try to bend the methodology because it isn’t working, but sometimes the problem is bigger with the business and its processes. Those processes can be broken and dysfunctional. There have been instances where the CEO didn’t want developers to have much say in those things that impaired their work and as a result, it created stress and sub-par products. It left the team deeply frustrated with a bad taste, a bad experience, and ultimately an unsuccessful product.
When engaging and setting up your next development project make sure you’ve addressed issues that could impact that project from a business perspective. Fix your business processes to allow Scrum to work. Success is a shared regimen and value system.