I recently became a Scrum Master. Always aspired to be called a Master anyway so I might as well get some certification so I can tell people to call me their Master! I would also accept the term Scrum Sensei or just Sensei. I like to research topics before casting any judgement or opinion about them. You can’t get around agile methods when you step into corporate life or even some tech startups. Agile methods are very interesting but kind of useless in many situations. That is why I am always kind of baffled when people throw these words at meetings in the hope it will magically solve their problems. Matter of fact, if you don’t know what you are doing, bringing in a method which you know even more little of into the mix will end up disastrously. The most used agile methodologies are Scrum, Kanban, Crystal, DSDM and XP. I will summarize them very briefly for the purpose of this blog but you can find a more in-depth explanation of them online.
Scrum
Scrum is one of the most loved frameworks of agile methodology. It has a feature called sprint. Sprint is a set of backlogs set by client/customer. In simpler words, sprint is a set of features given by clients to implement on software. As for the developers, they take one small piece of the backlog and plans to implement it on software. To complete their goal they take small 15minutes meetings to address their progress and developments.
Pros
Scrum is one of the transparent agile methodologies you can find. Its transparency allows the project to be followed by all members of the development team thus making it effective to reach the goal. The daily meetings put the team motivated so they can get a clear view of what to do and what not to do. Which makes the developers want to meet the deadline of every sprint.
Cons
There are many complaints of the scrum from developers, the biggest of them all is that it feels overloaded with meetings. Sprint planning can sometimes feel like delaying the overall progress but are sometimes necessary. The backlogs review meetings takes often 1-2 hours and daily meetings are limited to 10-15 minutes. Most of the time daily meetings feel disruptive to developers cause they have to leave their progress in the middle for daily meetings depending on the sprint.
Kanban
The Kanban word is derived from Japanese origin and its meaning is “just in time”. Basically, the kanban method circles around a board or table that show every flow of software development. Kanban method projects are managed through boards that categorize tasks in three segments/columns: “To do”, “Running” and “done”.
Kanban is simple, the board lets programmers see the progress so far and what’s coming up next visually.
Pros
- Gives you a decent general idea of where tasks are on a board (particularly helpful for a pull-based approach).
- Creates a nice collaborative environment by allowing several people to use their heads on different jobs.
- Manages the very fundamental visual components of an agile development cycle well.
Cons
- Kanban does not clearly display the task or story. To see the project information, you must open the project separately.
- Kanban provides a higher-level view of project management, however, it lacks customization and personalization options
Extreme Programming (XP)
Extreme Programming (XP) is a basic type of agile development framework developed by Kent Beck. XP emphasizes communication, teamwork, respect, and customer feedback. To build software using Extreme Programming methodology, the whole team sits together. This team must include the representative of the customer or the customer himself. The customer provides information, priorities, and requirements.
Teams plan a modest amount of work and do it in short timeframes known as iterations, which range from one to four weeks. The fundamental difference between XP and other iterative frameworks is that XP focuses on extreme software engineering approaches. According to a lot of studies, code reviews are one of the most effective approaches to detect problems. Through pair programming, XP takes this to its logical conclusion and encourages peer reviews 100% of the time.
Specific roles are defined in XP. It places a major focus on programmers and expects them to enjoy the process of testing their programs. To execute approaches like pair programming, XP programmers require both wide technical skills and good communication and interpersonal skills.
Crystal
Crystal Methodology is a collection of software development techniques that is one of the most lightweight approaches to program development (Clear, Yellow, Orange, Red, Maroon, Blue, and Violet). When the International Business Machine (IBM) commissioned Alistair Cockburn to propose a framework for object-oriented projects in 1991, he created this methodology. Because he had no experience with project management, he developed this process through his research and interactions with teams. He concluded that every successful team uses the same technique and pattern without having to apply any project methodology after conducting extensive study and interviews.
Crystal, like other Agile methodologies, focuses on timely product delivery, regularity, minimal administration with high user interaction, and customer satisfaction. The Crystal family believes that each system or project is unique, necessitating the use of a variety of techniques, processes, and policies to obtain the best results, giving them the title of agile methodology’s lightest approaches.
Dynamic Systems Development Method (DSDM)
DSDM stands for “dynamic software development methodology.” It’s a step-by-step technique based on the Rapid Application Development (RAD) methodology, which prioritizes rapid prototyping and iteration based on user feedback. The DSDM Agile Project Framework is like many other agile project delivery methodologies, evolved from a software-specific solution to a more general project management tool.
Most projects follow the DSDM agile principles as a guide. There are a total of eight principles.
- Concentrate on the business requirement.
- Deliver on time
- Gradually build on solid foundations.
- Iteratively develop
- Consistently and clearly communicate
- Demonstrate mastery of the situation.
Do I need Agile?
The real challenge is mostly for companies who started the traditional way and are looking to scale up. They mostly suffer from the fact that they have become too big to manage growth because the whole operation is just not efficient. I mean sure it might have been efficient to let’s say process 10 orders a day. But now you have to do 200 a day and might need to pick an agile method
How can you scale up, make it efficient and do all the fun things that come with growing a company? the simple answer is… you don’t because it’s not your job, it never was.
This is when nosy people like myself will come along and guide everyone into this smooth transition where the company stays fully operational while the transition takes place. Even though I am a Scrum Master, I am also not one. I have managed and guided teams plenty in my life without using scrum. Agile is just a method. If the company culture is toxic and unhealthy, the agile method won’t work and we need to first work on finding that fire in their bellies first.
I never introduce Agile to a company where the employees are just for the paycheck because Agile is a pretty dehumanisation process. So you have to make sure the team connects also on a personal level otherwise people just come in, clock in and out.
Conclusion
My primary issue with the agile methods, in general, is the dehumanisation process and creating small frameworks of responsibilities. It just does not work efficiently in all settings. This is very important to realise that just because you are a startup, don’t use Agile because you have to. I can assure you, you will get work done much quicker without agile in many business settings. But at the same time, once you hit a certain scale, it just gets difficult to manage.
So in my opinion Agile is best used for big organisations while using agile for startups or small companies will actually hurt your growth. There is however an exception to this and this is if you are making software or SaaS in general. The reason for this is very simple, software needs to be mapped properly, the process is more linear. A clear example
Doughnut shop chain: Using agile on a day to day basis will just take precious time to discuss again the same stuff over because it takes months to see changes discussed
Candy crush game: Every day and hour there are changes in the market, analysing the growth, feeding it back, bugs, features etc. These are much more dynamic and prone to change and impact the viability of the company
Adidas: This one gets tricky because they are a worldwide brand that operates online and offline, both local and global. So the best method for this is probably going agile but recognizing that some departments will actually suffer from it but overall the organisation will be better off with using agile. This must be a conscious choice for the CEO and stakeholders to make.
I can go on for ages on this topic but it’s time to wrap it up, I hope after reading this piece you have become a bit wiser today. If not you can always send me an DM on LinkedIn and headbutt together.