Agile software development is the preferred way for a lot of companies and successful software projects nowadays. As a professional software developer I used a lot of methods in the last years. School drilled me with traditional waterfall approaches like SDM and SDM II, this quickly changed to the Rational Unified Process (RUP) and a more eXtreme Programming XP kind of style during my internship.
The problem with the traditional methods, in an enterprise world, is iteration. Although they pretend to iterate, in practice iteration is almost never feasible, because of time pressure and the cost of changes. SDM effectively freezes software requirements at the start of the project, while in practice changes will almost always occur, especially with new projects. I think this was responsible for a lot of failures in big software projects in the late 90’s. Developing good software is a more organic process, in a couple of iterations you will get to a good solution for a problem.
So what’s Scrum about? Scrum is a efficient way to develop software with a self organizing development team that will work, in fixed length sprints, on releasing incremental better software. After each sprint a short demo is organized for the stakeholders and the development team has a meeting about what went OK in the last sprint and what could have gone better. Then the next sprint is started.
When a team is proficient there will be almost no deadline stress, no super long meetings, no long planning sessions and almost no management interference. After a couple of sprints the team gets into a cadence and because releasing is already an habit by then reaching a big milestone will cause less stress; it’s just another finished sprint.
The Daily Stand Up meeting is enough in most cases to determine the focus, risks and impediments of the team members. Detailed planning is done for just a couple of sprints ahead by the team with simple tools like; planning poker and story points.
The team members are the ones that pick what to do and when for the given iteration. This takes time when people are not used to it, but ends up making team members happier because nobody is dictating who gets to do what. They decide.
Because releasing incremental better software is a must you’ll get a system that quickly evolves to a solution instead of trying to arrive with a one big bang at some suboptimal solution
I can’t emphasize this enough, testing is an integral part of SCRUM. If you work with scrum and don’t test you software you are not scrumming, sorry. By testing I mean running fully automated unit tests, to ensure quality is as expected and refactoring code doesn’t accidentally break other parts of the system.
Each ticket in a sprint will go trough at least 4 stages: Not started, In progress, Testing, Done. Most Scrum teams use a, analog or digital, card-wall with columns containing the tickets for each stage. For the team members this is the primary way to keep track of the current sprint progress, and to be able to quickly adapt to problems in the flow/team.
As the stakeholders get a demo of the release they will be triggered to think about the possibilities. Often this will result in small changes in the road-map, to adapt to new business opportunities, or new user wishes. When the changes in software requirements are deemed to have high priority they can even be addressed in the next sprint.
Because scrum encourages changes you will deliver software that suits the changing perspective and requirements of the stakeholders better. In practice it’s very hard for humans to define a complex system in their heads; idea’s start to live when people experiment with them. Other software methods will often kill the ability to adapt a running software development process as it’s very costly to change all the requirement docs or all the planning. In Scrum you’re planning will get more detailed towards the end, and only stuff that’s really done will get documented. This ensures the possibility to adapt and iterate without sacrificing the project quality.
Scrum, as other Agile methods, uses internal and external feedback to improve the process, it relies on transparency. This leads to an open culture in which team members are stimulated to share their feelings and input. It’s also important that team members can express impediments.
Scrum theory states: ‘Significant aspects of the process must be visible to those responsible for the outcome.’ Scrum prescribes four formal events for inspection and adaptation:
Sprint Planning Daily Scrum Sprint Review Sprint Retrospective
As you may have noticed, there is no such thing as a detailed project planning, that dictates what should be done on a calendar. A, very global, road-map could exist. Only sprints are planned, by the team that does the work. This has quite an impact on a more traditional way of work were project managers are used to manage the project on a day to day basis. Management will get a lot of info from the scrum processes on each sprint end and from meetings with the product owner. The team will have all the info they need because they reach a consensus, on a per ticket basis, before a sprint is started in the sprint refinement meetings. They will also be trained, and getting skilled at, defining a Definition of Done for each item. It’s all about minimizing communication overhead while maintaining a shared knowledge domain around a project with less effort.
The term bus factor was coined in 1997 when somebody on the python mailing list asked what would happen when Guido van Rossum, the creator of python, would die in a bus accident.
Yes, even when you work with Scrum you have to write documentation. But you will write documentation when needed. Furthermore knowledge is shared within the team, there are no team hero’s or key persons, no single point of failure. When a person has info or expertise that makes him a single point of failure this will have a negative impact on sprints. This would be mentioned in a retrospective or as an impediment. Idea-liter each team member can do all the tasks in a sprint. A good Scrum team will therefore consists out of T shaped team members.
When a team is successful doing scrum for a while it will be very productive. After a couple of sprints the efficiency can be easily doubled or tripled. As high prio changes are easily applied in the process the customer or stakeholders will often see their requested change in the next release; trust me, this will ensure paid bills :)
Conclusion
Scrum is perfect for efficiently building complex software with a team, while minimizing risk and maximizing stakeholder and user satisfaction.
Related Posts
Quick Links
Legal Stuff