It's often that Scrum teams fail to appreciate the effect of adopting agile. They can't see an increase in productivity, an enhanced level of trust with the customer, or improved quality of the end product, all of which happen to be key objectives of agile. Teams are left pondering as to what is going wrong with their adoption of agile and Scrum. They plan before starting the sprint, have standups on time, have frequent communication with the customer, yet a lack of the wow factor makes one think, "why am I doing it." Most often these problems arise when we abide by all the Scrum practices but forget about doing programming in an agile manner.
Agile is recognized as a system-software development approach used to get quick feedback to keep the customer involved at every stage, building a disciplined team, and having working software at any given point in time. Extreme Programming (XP) is vital and necessary part of agile product development. These goals would impossible to achieve if the programming part is lacking agile. Let's see how things start falling out of place when agility on the programming side is ignored.
It all starts here
We always talk about agile being a mindset, not a methodology. This could only be true if we start contributing every single thing the agile way, including programming. As we expect to get feedback from the customer promptly, we should also strive to get the feedback from the code itself. For example, if we are not doing test driven development (TDD), we are not focused on defining what the code needs to do before writing the code itself. This is a differentiating feature of TDD versus writing tests after the code is written. It makes the developer focus on the requirements before writing the code, a subtle but important difference. Instead, programmers write the test cases as per the code written already. In this situation, the test cases become compliant to the implementation instead of the requirement. This is one evidence of breaking the trust. A team that doesn't have confidence in the code written by themselves, can't really expect the customer to put faith in them.
Cul-de-sac
Writing the test cases as per the code written already, as discussed above, leads to code with more bugs, I won't say that doing TDD is going to get rid of defects completely, but it definitely keeps them at a manageable level. Having more bugs in the code would require an extra effort over the estimated time from the programmer to fix. This time would come from the effort estimated to complete other stories. This puts extra pressure on the developer, which would eventually increase the probability of him/her making more mistakes. More bugs with the next story, that will need more time to fix, and finally the programmer gets caught in this vicious circle.
A way out?
In the retrospectives the blame would be put on the sprint estimation (which still might be true!). But even if the estimates were conservative and correct, the above situation would still occur at some point sooner or later. This might lead the team to re-estimate and reduce the sprint velocity, which is only going to harm the team with loss in the productivity, or maybe bring in a test engineer, which would increase the cost (something that the customer is certainly going to hate). If this is the way the team is going to react, we have another problem to deal with: a failed sprint retrospective.
If the team’s reaction to reducing its velocity was one of shame, another solution it has is to put in is extra hours. Sounds promising, doesn't it? Actually team members are setting themselves up for a disaster. More hours spent in the office, slogging around is usually counter-productive, even if the developers have something to show; primarily because the quality has been compromised(another objective lost). People who stay late in the office, at some stage start missing the morning stand-ups, the discipline the team so fondly used to talk about now becomes suspect. Because it now becomes obvious the discipline actually never existed. It is not just about showing up on time to meet your commitments, it’s about everything you do in your daily professional life. Programming is definitely high on that list if you are a programmer.
Breaking the promise
Continuous integration existed before people started moving towards agile, as teams set periodic builds on the codebase in a shared repository. This goes along well most of the time and people do make sure at their end that whatever they are checking in, doesn't break the build. Problems occur though when the integration test or the regression suite are run on a different profile because they take too much time to execute to be a part of the main build.
Usually people notice but don't bother about failing build on the regression suite profile and wait for someone else to fix it. Ignoring test cases in the failing build on one's own machine, so that individual's progress is not gated, is a quick way out. This is a good excuse for me, if I am not the one who has broken the build, and gives me every reason to keep myself out of it. Well, fair enough, but a promise has been broken, one that we made when we got the deal with the customer that the team should be ready with a shippable software at any given point, which happens to be one of the key objectives of agile. The fixes on regression suite are delayed to the last minute and the team finally hears the news from the customer about the build failure, which is disastrous. Broken promises do not help the team keep up a good rapport with the client anymore.
Two is a crowd
A lot of people think that “pair programming” reduces the productivity of the overall team by fifty percent. It certainly does, but only if the navigator does not understand his/her role. A navigator's job is to monitor the code written by the driver and raise a red flag as soon as the code starts going in the wrong direction. A navigator is also responsible for suggesting test cases to be written in a test-driven programming model. By not doing pair programming the visibility of code gets reduced and sharing knowledge doesn't happen. Not enough knowledge is flowing across the team and a potential opportunity to receive prompt feedback is lost. In Agile, the margin of error has to be kept minimally low, as no buffer time is kept in the sprint, the chance of fixing the same story has to be kept as low as possible. There is not enough time for programmers in an Agile team to do separate code reviews. No piece of code should be considered shippable, unless it has been verified by another pair of eyes, which the practice of pair programming implicitly takes care of.
Simplicity is for faint hearted
During design discussions, technology heavyweights within the team often pick up a marker and start drawing huge architectural diagrams on a white board. In the process, they forget about what the actual story was and what the scope of the discussion should have been. Having a lengthy discussion on the implementation of a user story defeats the purpose of coding a simple design. In such discussions, we always start talking about how the current implementation impacts the product in the future. Also, we try to close on the technical design which would again kill the idea of concentrating on the smallest problem at hand, thus undermining the philosophy of writing the simplest possible design, evolving the architecture, minimizing dependencies between components and driving at a flexible and extensible architecture. This leads to programmers doing more work than necessary to get the stories done they committed to get done. The result of which is sometimes missing out on meeting sprint goals and objectives.
It's freezing out there
As previously mentioned, when being agile, solutions are developed bit by bit and the design evolves over time. This is the biggest mindset shift, when a developer or an architect is first introduced to agile. Mostly because in the waterfall model, architects of the system take care of the designing part during the early stages of the project and try to come up with the most feasible design before developers actually start coding. The choice of technologies is made at the very start, and a team of people good at that technology stack are chosen to work on the project. Architects like to make a picture in their minds of what the final product would look like. People coming from a waterfall background find the idea of the architecture and solution evolving with time, as it happens in agile, abstract and impractical. Reason being, its always easier to move when one knows which route to follow, which doesn't happen in agile. One has to be flexible to adapt to change as soon as a problem is found with the current approach, before moving any further.
This is why an architect would find the agile way of designing awkward.
Let’s talk about why a developer, coming from a waterfall background, finds it hard to be agile. In the traditional approach, the decisions about design and technology were taken from the architects, which made minimized design work for the programmer. Now suddenly the programmer is working in an environment where the developer actively participates in design. This requires the developer to come out of his/her comfort zone and start taking initiative instead of being a follower. Stepping out of one’s comfort zone and to start doing things one has not done before can be disconcerting and feel like stepping out in the cold.
Summing it up
The whole idea of “agile” is incomplete if XP is not a part of it. People working in teams that ignore XP start getting frustrated, and the question “Why agile?” keeps coming to their minds. It is important that the ScrumMaster keeps a check on how well the programming practices are being followed, apart from how the planning, estimation, and communication (with the customer) is going on.
Talking in terms of numbers, almost 80 percent of a programmer's working hours are spent doing the coding work, the remaining 20 percent is spent in meetings, design discussions, etc. This clearly exhibits the impact of XP on the overall performance of a scrum team. A different programming approach for agile teams is in step with the overall goal of being agile. It cannot be ignored under any circumstances. The whole mechanics of Agile depend on the programming techniques. If the machinery is not right, things are not going to work for the team magically. Your success with beingagile hinges on the programming techniques and practices being applied.
Before a team decides to be agile, they should spend some time to learn about and get training on programming practices such as concurrent testing, continuous integration and test driven development. Focusing on the “why” factor of having these practices in place along with “how” to apply them in real life product development scenarios. One needs to understand why a certain practice is being followed in order to appreciate it. It's always good to learn early and from the experts rather than learning the hard way.
This is what I learned after spending time adopting agile product development and seeing different flavors of it (with and without XP). To sum it up in a sentence, the impact of XP and other agile development practices on the success of an agile team is huge, and it is impossible to make the mindset shift to being agile without changing the way we go about writing code.
