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 must 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 difficult to do and does not feel natural. TDD is counterintuitive and it takes the way we work and flips it upside down. Also, the way 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 just code and someone else tests. Now they have so much more work to do with thinking of the tests and writing them. 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 watching over you 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 receives a lot less pushback. Developers will 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 are we integrated 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 if we do have tests that someone else wrote but are super hard to maintain so we don’t run them anymore.
The Agile Engineering practices we previously covered are essential for succeeding with Scrum and ensuring 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.