Agile X Factors

11 December 2013

Dele Oluwole
Qual IT


Competition is the keen cutting edge of business, always shaving away at costs.
-- Henry Ford

Today, local and international markets have become volatile and highly competitive. This invariably forces value-driven businesses to require that application be delivered in less time and also that it accommodate constantly changing features for the purpose of competitive advantage.

It is therefore almost inevitable that businesses seeking advantage over competitors would not only adopt Agile as a method but also religiously adhere to most of Scrum's best-known technical practices as means to an end. For most organizations, added business value stems from striving for technical excellence.

In May 2013, the Google Android UX team, in its presentation by Miki Komo and Bethany Fong, gave us an insight into how Google deems it critical to get users' feedback frequently and consistently, so that the development team can be driven toward delivering best-in-class design for their users. They applied "pulse studies," also known as iterative research sessions.

This approach, according to the team, enabled Google to put new ideas, designs, and concepts in front of users on a regular basis without thorough advance planning. This can have immediate impact and help meet urgent needs. In my opinion, Google has successfully used this approach to achieve pushing the researcher and product owners' role to the field.

What we are now seeing is that while businesses that have keyed into Agile and Scrum practices are exceeding others that were once pro-Waterfall -- and that are now also fast adopting Agile -- thereby making software development a catalyst for development teams, so as to deliver incrementally, iteratively, and transparently. Today, unlike in the 1990s, trying out Agile and its technical practices has become almost a natural, instinctive decision. This is because, since 1995, the Agile method has become proven, tested, and trusted.

For organizations like Google, IBM, Yahoo, and Facebook, Agile is solution for late app delivery to the highly competitive global market. You can also say it is medicine for curing divergent usability problems, which has lately become an innuendo to the management of most companies.

Agile, or Scrum, technical apparatus, such as continuous integration, test-driven development, pair programming, refactoring, collective ownership, etc., are what has made it possible for most of these organizations to be able to tailor customers' requirements and deliver business values efficiently and effectively. Teams that are dedicated to sprint planning, the Daily Scrum, and sprint review and retrospective will do well. But they will have even more improvement, or become twice as productive, if they adopt some of these technical practices.

Even though Scrum does not prescribe engineering practices, the team is expected to take the initiative to adopt particular technical practices that will help deliver business value or shippable product at the end of every sprint. For example, if a team is saddled with the responsibility of developing a clean and high-quality code, Scrum does not specifically prescribe TDD, pair programming, or refactoring; rather, Scrum recommends a high-quality, potentially shippable product at the end of every sprint. It is therefore the responsibility of the team to decide what technical practice is best to adopt. A team with good self-organizing skills will not struggle to achieve this.

Using the Agile Manifesto and value as a delivery paradigm, let us look at the five technical practices from the pack that an organization can use to deliver business value.

1. Collective ownership
When every developer, or, rather, every member of a Scrum team, has a sense of ownership over all artifacts of the development process, there will generally exist the spirit of collective ownership and encouragement for all to be responsible for all parts of the application program, especially the code and automated testing. The benefit, therefore, is that no one developer can lay claim to a module nor restrict his or her programming to a module of the program. Everyone can work on every module.

The spirit of collective ownership here reminds me of the long-forgotten African tradition in which every farmer in a household/community commits his farm produce, especially yams, to one yam barn. No one lays claim or ownership to the yam tubers in the community, and because of this, famine was a rare occurrence.

2. Continuous integration
With continuous integration, the era of developing modules in segments for future integration and testing is over. Now, new or changed codes or modules can be integrated instantaneously and application tested in order to ensure that nothing is broken. The benefit here is that the evil days are not pushed to the future of the product development stages, when they become more difficult and expensive to manage. Continuous integration could also mitigate the risk of late introduction of a feature that could help an organization gain competitive advantage.

3. Pair programming
Pair programming may cost more in the short term, but the extra cost of paying two programmers to do the job of one cannot be compared to the benefit in the long term.
There will certainly be fewer defects with pair programming, which will ultimately mitigate the cost associated with late fixes.

Aside from improvement in quality, pair programming also facilitates knowledge transfer, especially for new developers who are finding their feet.

4. Test-driven development
Developing by writing enough code to pass a test is a measure employed to make sure that no code makes it to the production environment or the system untested. The approach helps eliminate uncertainties, and it can almost invariably drive the development of a system. This can, therefore, have a huge long-term, positive impact on return on investment, as less time and money will be spent on fixing defects.

5. Refactoring
Refactoring is about changing the structure of the code, but not the code itself. This, for instance, implies that where there are two methods that contain multiple and identical statements, the multiple statements are better extracted from the two methods and kept in another new method that can be called from the two old repositories.

Because some codes or programs are called and then reused, it means refactoring can improve readability and maintainability as duplicate codes can now be in a single location.
Agile prescribes that designs must simply begin with the simplest approach/modules and grow incrementally where possible. This, most times, can best be achieved by refactoring.

These technical practices can, in their own unique and peculiar ways, help propel an organization beyond its competitors if religiously practiced.


References
  • Konno, Miki; Fong, Bethany. Agile UX Research Practice in Android. 16 May 2013.
  • Cohn, Mike. Succeeding with Agile: Software Development Using Scrum. 2010. Pearson Education, Inc.

Article Rating

Current rating: 4.7 (3 ratings)

Comments

Be the first to add a comment...


You must Login or Signup to comment.