Agile Engineering practices are not new. They originate from extreme programming back in the late 90s. XP specifically calls out these practices as things you should be doing. And here we are 20+ years later still trying to get teams to adopt them. Why is that?
We do Scrum not XP
People might find these practices from XP too extreme so instead, they do Scrum. And Scrum does not specifically call out the need for these practices! However, Scrum indirectly implies that you need them. Scrum takes the approach that you should deliver a working Product Increment at the end of every Sprint and if you can’t then you need to figure out why in the retrospective. The idea is that you will realize in the retrospective that there is no way you can deliver a quality Product Increment at the end of each and every Sprint if you don’t start applying these practices.
Test Driven Development is hard
Yes, TDD is hard at first. It is not easy to do and does not feel natural. TDD is counterintuitive and it takes the way we work and flips it upside down. Also, how most teach TDD, with small exercises and micro steps, doesn’t help as it looks very different from the production code that most deal with. In addition, developers are not used to testing and are not familiar with how to test. They code and someone else tests. Now they have so much more to do with thinking about writing the tests. There is no time!
Pairing is uncomfortable
Pairing is uncomfortable. Pairing is actually exhausting as you are on and focused the entire time you are paring. It can be mentally draining. Plus, it is physically uncomfortable as you have someone in your physical space the entire time. Someone is constantly watching over your shoulder!
Collective Code Ownership is impossible
Collective code ownership is a dream. Developers barely know the one module they work in regularly. Now we expect them to learn all these other areas of the code. Just focusing on one of these modules is hard enough. And just from a domain perspective; That’s not even considering the technology aspect!
We already use Jenkins
Continuous Integration and deployment receive a lot less pushback. Developers say that they already use a tool like Jenkins. However, developers confuse the tool that enables continuous integration with the practice of continuous integration. Jenkins is the tool. The question is how often do we integrate our code base? Are we doing it multiple times per day, or do we have many long-running branches? Are we working off of trunk or the mainline? In addition, continuous integration has minimal benefits if we don’t have tests or have tests that someone else wrote but are super hard to maintain so we don’t run them anymore.
Agile Engineering practices are essential to succeed with Scrum and ensure that teams are capable of delivering a Product Increment at the end of every Sprint. Let’s walk through an 8-step approach to guide your team to adopt these practices and make them easier to learn and apply.
To learn more about these Agile Engineering Practices, consider signing up for our next CSD – Certified Scrum Developer Class.