main banner

Development

Demystifying Agile, Part 2

Software development frameworks will provide you structure and direction to develop software in a particular or preferred way like “Agile” or “Plan-driven”, but it is up to you to decide what is the best way to do it; and that is the key difference between the two.

Framework or Methodology?

In the last post we agreed that “Agile” is a framework, not a methodology, however what is the difference? A lot of people confuses these terms, sometimes to the point of using them interchangeably, and they are different; in the software development context this difference is a very important one.


So, to clarify this difference, let us talk about methodologies and, what are they?

What is a Methodology?

There are many definitions for “Methodology” that you can find on the Internet; so I’m only going to mention one that I think is similar to most and is enough for me to clarify its meaning from the software development point of view.


According to the PMBoK a methodology is:


“A system of practices, techniques, procedures, and rules used by those who work in a discipline”.


Our discipline is “Software Development”; and for software development the deliverables, activities and processes are fundamental; as such, they are part of software development methodologies too. A software developing methodology is well defined, well thought out, well tested set of “practices, techniques, procedures, rules, deliverables, activities and processes” that are meant to allows us to develop software in a repeatable and consistent way every time.


To put it simple, a methodology is a “complete” approach that will give us the WHAT’s, HOW’s, WHEN’s and WHY’s during software development.


But there is a catch, each methodology is designed to solve a particular problem ( not a fix all, silver bullet type of solution) so to pick a methodology you must assess your problem to find out if it matches the one the methodology was designed for.


For software development methodologies the problem to solve is the way to develop software; so each software development methodology will provide a different way to develop software and will have their own conditions and restrictions it was designed for. If those restrictions and conditions do not suit you well, then you must use a different methodology.

What if I can’t find a methodology that suites my needs?

Enter the framework...


Frameworks are like methodologies, however they will only provide you the structure (principles and rules) and guidance (practices and guidelines) on a preferred way to do something but will let you decide the best way to do it (most of the times they will only give you the WHAT’s).


Software development frameworks will provide you structure and direction to develop software in a particular or preferred way like “Agile” or “Plan-driven”, but it is up to you to decide what is the best way to do it; and that is the key difference between the two.


Frameworks are designed to be loose and flexible, and will let you adapt to changing conditions; you can extend them, stitch more than one together or tailor them to meet your needs in a greater extent than methodologies.


This looseness and flexibility comes with a price:


“Frameworks are harder to use, more difficult to implement, have a higher level of risk, and have a less consistent outcome than methodologies.”


Frameworks work best when experienced and seasoned people (experts) are implementing them; methodologies, on the other hand, are a better option when working with a low experienced team.


Just remember, this is not a black and white world, there are frameworks more loose and flexible than others; as there are methodologies more rigid and prescriptive than others.Whether to adopt a framework or methodology, for software development, is a choice each organization must take based on their software development context (organizational culture, conditions, restrictions, level of expertise, etc.)

Agile Frameworks

Now that we have agreed on what is a framework, and that “Agile” is one of them, let’s talk about some of the most famous “Agile” implementations: XP and SCRUM.


This is eXtreme!!!


“eXtreme Programming” or XP is one of the most adopted agile software development implementations intended to improve software quality and responsiveness to changing customer requirements.It derives from the “Agile” framework and extends it including additional elements (practices, values, rules and principles) to specify a preferred way to develop software.


XP was created by Kent Beck (one of the 17 experts that wrote the Agile Manifesto) between 1996 and 1999 while working on C3 payroll project for Chrysler. It was called eXtreme Programming because it took some of the Industry best practices to extreme levels.


On XP work is done by a small team of multidisciplinary people (developers, testers, managers and a customer representative) that will work together to produce better software by developing it with a ready for change mindset using an iterative approach with multiple releases, where each subsequent release will add working functionality to the previous one.


Sounds familiar, right? Basically XP is a more detailed Agile framework; the idea to add this additional detail is to include information on the Hows, Whens and Whys - without spelling all out to make it too rigid or prescriptive for organizations to adopt; it could be classified as a more specific framework or a less specific methodology; as it lays somewhere in between them both- with one goal: producing better quality software.


So, XP main goal is to produce better quality software through agile development, but how does it achieve this?


To understand it we need to address some important facts that XP took into consideration when adding additional practices, values, rules and principles to Agile.


  • Good code is the most important thing in software development, without code there is no working software, without good code there is no lasting working software.

  • Good code, or quality code, is different than code that has few bugs; by finding and fixing bugs we can reduce the number of bugs in our code, but we are not improving its quality. Good quality code has fewer dependencies, has a good separation of concerns, is clear on what its purpose is, it has good readability and maintainability and tends to gravitate towards simpler solutions over convoluted complexity.

  • Software rots!, this is something that seasoned developers know, but is less evident to the rest of the organization; this phenomenon happens when changes in the environment (business changes) are not addressed properly in the software that resides in it, typically because a lack of resources (time, money or personnel) thus less quality in coding, design and implementations begin to carve its way into the software, duplication of code and increased dependencies start to become part of the software. This decay starts to get noticed when fixing a simple bug will trigger more bugs (usually more expensive and difficult to fix), overtime the software becomes harder to maintain and more expensive to do so… this will keep escalating until the budget is exceeded and it becomes unmaintainable.


XP focuses on values, practices, rules and techniques that will help the team to produce good quality code and also prevent it from rotting; XP values are: Simplicity, Communication, Feedback, Respect and Courage, you can get a complete description of them here (http://www.extremeprogramming.org/values.html); These values are translated into more concise principles and rules that will serve as guidelines when implementing XP.


XP rules are a bit more extensive and are classified in disciplines like: planning, managing, designing, coding and testing. Some of these rules include: using user stories and dividing the project in iterations for planning, working at a sustainable pace for managing, refactoring when possible and focusing on simplicity for designing, using pair programming for all production code and integrating often for coding -  all code has unit tests and when a bug is found more tests are created for testing, etc. You can read about these rules here (http://www.extremeprogramming.org/rules.html).  


So a typical XP project will begin by forming an appropriate team of developers, testers, project managers and a customer representative (or product manager) that will work together full time to produce the best product they can.


Then work starts with  customers writing a set of user stories (each one in a card), these user stories are the core of XP planning and will be used to create time estimates during the release planning meetings. They’ll explain in a simple way a thing the system needs to do for the customer (not just user interactions with the software being built); then scoping and planning is done by manipulating these user stories.


Good user stories are short, concise and centered on user needs (no technical language is used only business language); they must only have enough detail to produce a reasonable low risk estimate of how long the story will take to be implemented (all estimations are done by developers). Between 1 and 3 weeks of development time are considered ideal estimates; longer times indicate the story needs to be broken down into smaller stories, shorter times indicate you are detailing to much the stories and thus you need to merge a couple of them.User stories are also used to create automated acceptance tests; these tests will be used to verify the user story is correctly implemented.


When enough stories are created the team proceeds to create a release plan; this plan will indicate what stories are going to be implemented in each release of the system and on which dates. Each release gets implemented in an iteration (time window for the team to implement the selected user stories by splitting them into tasks).   


There are 3 levels of the release plan: one that groups stories a few months into the future, another for stories in the next iteration and a final one that breaks down stories into tasks for the current iteration. Developers will sign up for the tasks.


It's worth mentioning that for XP, plans are temporal artifacts; the plan needs to be recreated each time the customer gains insight, or when the team gets ahead or behind the schedule.Sometimes user stories will produce uncertain estimates, because of either technical or design problems. When that happens the team will create a very simple program called Spike Solution or prototype to explore potential solutions and produce a more confident estimate. This is a throw away code, its only objective is to provide more confidence in the produced estimates; however if the problem is complex enough pair programming is a good technique to use when creating this prototype.


When the Release Plan is done then iteration work begins; each iteration is a time frame in which the entire project gets divided;  between 1 and 3 weeks per iteration is reasonable, however you must keep iteration time constant throughout the project to measure progress in a reliable way.


During development the team must keep the code quality and its readiness to adapt high; to do this the team must design for simplicity and refactor often. All code must as well conform to agreed code standards; the customer must be always available to solve any business inquiries the developers may have. Automated unit test must be written before any other code and all code must have automated unit tests. Continuous feedback must be kept at all times by pair programming all production code. All code should be integrated often and must pass all its unit tests before it can be released; acceptance test must be run often and the score must be published.


When the iteration finishes, all selected stories are implemented and the produced code has been integrated and tested, then a release can be made and the team will repeat the process for every subsequent iteration until the project is completed.


If you want to adopt XP you can opt to go full XP (better on a new software development project) or you can add some of the XP practices and rules (even on existing projects) one at a time to try it out.
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