main banner

Development

Demystifying Agile, Part 6

In this post I will wrap up some of the content we discussed on the last posts and include bibliography as reference.

In the previous posts of this blog series I have discussed about agile and agile development, I mentioned its principles, characteristics, virtues and dangers; and also described the common frameworks, practices, techniques and named some of the tools typically used to aid with their adoption and execution.

I hope this series helped you clarify or reaffirm the concepts related to Agile Development; and also gave you a glimpse of the changes and commitments needed at the professional and organizational level to make it work; and by doing so removed the veil of mysticism that surrounds this software development approach.

In the end, Agile is another approach available to us (software developers, engineers, professionals and organizations) for producing software; how valuable and helpful it is to us depends on how we understand it and use it. It is up to us to make it work in our favor towards achieving our goals of producing better quality software that add value to its users.  

In summary

Here is a recap of the topics covered in these series:

Agile

  • Is an approach to software development with the goal to build better software in an iterative incremental way. The Agile Manifesto is the document that describes its goals and the principles that must be followed.
  • Has high tolerance for unstable requirements; thus making it a good option when the requirements are not developed enough or change too often than using a Plan-driven approach becomes too expensive.
  • Means ready to adapt; so Agile welcomes changes even during late development. This ability to adapt is seen as an important asset and is the core of Agile development.
  • Requires that the software being developed should be easy to adapt. If the software is not easy to adapt then the team can’t use Agile to built it. So, the development team, must adopt agile-compatible development practices and techniques like: adaptive planning (execute the planning process many times iteratively during the project by re-planning, re-measuring, re-adjusting, etc.) and evolutionary software design (software design that changes and evolves frequently over time)
  • Requires the willingness of the organisation and development teams to adopt the needed changes to enable Agile development; like defining an agile compatible approach to testing or publishing releases.
  • Promotes keeping a steady pace during development (it should not wear down or burn down people).

 

Plan Driven Approach or Traditional Approach

  • Is a way to develop software by using a plan as the main driver for managing development.
  • Has a project management process that runs in parallel with the software development process; the Project manager is a central role in this approach as he/she will be in charge of executing and controlling the project management process that inspects, measures, reports and adapts the work (its load and its distribution) of the team during the development process.
  • Has low tolerance for unstable requirements; it needs requirements (the most important ones) to be discovered and defined up front (in the initial phases of the project) then they must be developed enough (stable) to produce a reliable plan.
  • Uses a change control process to adapt to changes (is an expensive process)
  • Uses a risk management process to handle risk
  • Is well suited for large development teams on distributed environments (as long as the requirements are stable enough to produce a reliable plan).

 

A framework

  • Is a system of practices, techniques, guidelines and rules used by those who work in a discipline. Is more loosely defined than a methodology.
  • Is just developed enough to provide a reference context and a guide on what to do (the when’s, how’s and why’s are left out or are incompletely defined). So it is incomplete by design.
  • The users should define and implement themselves the missing pieces to have a complete system of practices, techniques, procedures, and rules tailored to their needs and reality.
  • Can be extended or can be stitched along other frameworks to tailor a specific solution.
  • Is harder to use than a methodology, and often requires teams with expertise to work well and to lower the risk.
  • Has lower predictability than a methodology.
  • Is flexible, customizable and extendable.

 

A methodology

  • Is a system of practices, techniques, procedures, and rules used by those who work in a discipline. Is more defined (or rather completed defined) than a framework.
  • Will indicate you what to do, when to do it, how to do it and why to do it.
  • Is highly prescriptive and thus predictable (it can reproduce the same results every time)
  • Is inflexible, it focus on a single problem or one that has a specific set of characteristics. An assessment should be done to choose the adequate methodology to a problem.
  • It's easier to use than frameworks; so is better suited for inexperienced teams.

 

XP

  • Is a methodology (or highly detailed framework depending on your boundary between framework and methodology) for developing software using an Agile approach (Abids to the agile manifesto).
  • Relies development to a small team of multidisciplinary members that will collaborate and work together as a unit to develop software iteratively and in small increments; such increments will be released often.
  • Primary goal is to produce high quality software. For XP high quality software is more than software without bugs (stable) is also software whose code exposes many quality attributes like: manageable, maintainable, adaptable, extendable, understandable, etc.
  • Focuses on values, practices, rules and techniques that will help the team produce good quality code and also prevent it from rotting.
  • Starts by creating a set of user stories, then the team plans and scopes the work to be done in the coming iteration by producing a release plan based on the user stories; then the team starts development using the release plan as a guide; during development the team keeps the code quality and adaptability at all times by using engineering techniques like Focus on Simplicity, doing Pair Programming (PP) on all production code, Test Driven Development (TDD) and Continuous Integration (CI).

 

Scrum

  • Is an agile framework to aid the development and sustainment of complex products (not necessarily software).
  • Focuses, mainly, in the management aspects of development by defining a set of roles, events artifacts and rules that bind everything together.
  • Is based on empiricism; empiricism asserts that knowledge comes from past experience (only the past is certain) and decision making should be based on what is known.
  • Lowers risk and increases predictability by working on small increments in an iterative way (sprints).
  • Is sustained by 3 pillars: transparency, inspection and adaptation (these are provided through a set of events, artifacts and definitions).
  • Team has only 3 roles; product owner, scrum master and development team. The development team must posses all abilities needed to produce an increment that should be potentially releasable. So scrum teams are self-organizing and cross-functional; (there is no project manager in Scrum).
  • Is lightweight, simple to understand and difficult to master.
  • Can produce software messes quite fast; because of this Scrum must be complemented with additional frameworks, processes, techniques or practices for guiding and aiding the team, during development, to produce agile-compatible (adaptable) software.

 

Technical Debt

  • Is similar to a financial debt; you acquire a financial debt when you borrow money to use it in a short term with the promise that it will be paid later on at the costs of interests. When a developer chooses to implement a feature or update existing code using a short term solution the technical debt of the software increases.
  • In a team with many developers, it can grow quite fast, and as with financial debts it must be kept under control at all times to prevent a crisis state or to get to a point where the debt is unpayable.
  • Teams working on software with a huge technical debt will spend most of their future development time paying such debt (fixes will take longer to implement and be harder to do, changes will impact more and more pieces, etc.) The time they’ll spend on adding features will be reduced because of the time they’ll need to deal with the technical debt consequences.

 

Engineering Techniques and Practices

Code Refactoring

  • Is the common name that groups a series of techniques used by developers to change the internal structure of software without changing its external behaviour.
  • Is used as a way to improve some of the software quality attributes like: maintainability, efficiency, scalability, accuracy, reliability, modularity, adaptability, etc.; to keep code clean and to reduce technical debt.
  • Is a way to improve adaptability,  maintainability and when done well, it helps keeping the code manageable as it grows. This serves well during Agile development as the latter requires high adaptability and maintainability in the code it is producing, while development teams need to keep working at a steady pace as code keeps growing (code growth is usually accelerated by agile development).
  • Could be risky and dangerous (when done improperly it can destabilize the software and introduce bugs); because of this, it's extremely important for developers to have a way to guarantee the applied refactorings are successful every time. Automated tests and Self Testing code helps to achieve this.

Self-Testing Code and Test Driven Development (TDD)

  • Self-testing code is the concept that each software piece must be able to test itself.
  • Self-testing code is achieved by defining and executing often a set of automated tests that must give confidence to the development team that the software is free of any substantial defect.
  • In self-testing code the software can’t be considered as done if these automated tests are pending. The automated test suite is considered an integral part of the software.
  • Self-testing code enables refactoring without risk.
  • TDD is a technique for building software: in it development begins by writing tests first; then the new functionalities are built by only writing the minimum amount of code needed to pass the written set of tests and then the code is refactored to make it clean; this process repeats over and over again until all functionality is developed.
  • TDD advantages are that it produces Self-Testing code, and also forces the development team to understand the requirements and to think in the code interface first, as these are needed to be able to write a meaningful and useful tests suite.

Pair Programming (PP)

  • Is a software development technique in which two developers work together, concentrating on the same code, using the same computer.
  • Requires that two developers collaborate as equals (not as a teacher-student mentoring type of collaboration) by doing so, continuous discussion and review is fostered, and as a result they will produce better designs, they’ll make fewer mistakes, learn from each other and write better code than if working individually.
  • Requires social and soft skills from the developers; like: good and continuous communication, teamwork, creative thinking, negotiation skills, etc; so to be effective pair programmers either need to have these skills or invest time to develop them.
  • Increases productivity of the development team, as the coding tasks are done faster and of better quality than when working individually, however the number of man-hours needed to finish a coding task will often increase as well, thus making it more expensive.

Continuous Integration (CI)

  • Is a software development practice that consist of frequently integrating the work done.
  • “Integration Hell” happens when the time it takes to integrate changes is longer that the time it took to develop them.
  • By Integrating often, the risk of encountering integration problems is highly reduced; and if problems are found, it would be easier and faster to fix them as the changes have been introduced recently.
  • There is no rule for how often to integrate, but a good rule of thumb is that each developer in the team has to integrate his work at least once a day.
  • Relies on the following practices to be effective: maintain a single source repository, automate the build, make the build self testing, everyone commits to mainline everyday, every commit to mainline should build on an integration machine, fix broken builds immediately, keep the build fast, test in a clone of production environment, make it easy to everyone to get the latest deliverables, everyone can see what is going on (the progress and results of the latest build), and automate the deployment.

 

References

These are the sources I used during the writing of these blog series, I highly recommend you to take a look at them:

Raúl N

Ever met one of those guys whose code should’ve been his natural language? Well, meet Raul, a Computer Systems Engineer whose hobbies include video games, playing with his ferret pets, reading and movies. He has over 12 years of experience as a developer and has a lot of experience with Microsoft Technologies (specially .NET) as well as architecture and software development process; he has written some really good articles about this topics.

Articles