Table of contents
Introduction
This article is a quick FAQ of Agile. By reading this, you will understand the fundamentals of Agile and the different ways of implementing Agile.
Can you explain the concept of refactoring?
If you read the XP life cycle, one of the things after we implement the task is code refactoring. Refactoring is the process of changing the software in such a way that it does not change the behavior of the code but on the other hand improves the internal structure. No code can be perfect with architecture, coding conventions, and high reusability at the first level itself. Normally it improves over time. It helps developers to implement the necessary solutions today and improve / make the code better tomorrow. Refactoring is the process of changing the system to improve the internal structure without changing what the system does. Below are the three major activities performed during refactoring.
Simplify complex code
XP is all about light-weight and simplicity. This holds true not only for a process but also for coding. When you see a code can be simplified, discuss it with your developing partner and implement it. For instance, shown below is code which was further simplified into one equation:
Figure: Simplify code
Move similar operations into reusable code. If we have similar operations, move them to one reusable code. For instance, in the class below, we have various sort functions which sort by phone, code, name, and date. We can combine them into one function called sort and make it simple.
Figure: Reusable code
Remove duplicates and redundancy
When a project has constrained timelines, it’s very much possible that the project can have lot of duplications. So when developers have finished their tasks, they can review for these kinds of duplications. For example, the below figure ‘Remove duplication’ shows how the phone number duplication is removed from the customer table. The customer table has repetitive fields like mobile number, land line, and office number. In abstract terms, these represent telephone numbers. So we split the customer table into two tables, customer and customerphone, and build a relationship between them.
Figure: Remove duplication
Shown below another scenario where we have an invoice class which has two methods GenerateInvNo and CreateInvNo and they do the same thing, generate unique invoice numbers. We can refactor / improve the code by combining these two methods into one.
Figure: Code duplication
No code is perfect, it has to be made perfect.
What is a feature in Feature Driven Development? Feature is a process which adds value to the end customer and it can be planned. In short, it has two characteristics:
- We can plan and schedule a feature.
- It should be something that delivers value to the end user.
Figure: Feature
In short it’s not necessary that a feature maps with a use case or a user story. It should also be planned and manageable. Features are delivered in a given time box (we will discuss this in detail in the coming sections).
Can you explain the overall structure of FDD projects?
FDD is an iterative methodology to deliver projects. Rather than delivering projects in one go, we deliver features within time limits. Let’s understand how the FDD cycle moves. We will have two views: the overall flow and the detail iteration flow. The figure below ‘Structure of an FDD project’ shows a step by step approach for FDD projects.
The below points are looped for every iteration (the sections below are covered in more detail in the upcoming section).
- Identify the features: In this phase, we identify the features in the project. Keep one thing in mind, features are not simple user point of view requirements; we should be able to schedule a feature.
- Prioritize the features: Big bang theory thinking is bad. Many project managers think about delivering everything in the first step itself, but that’s practically difficult. Rather, deliver first the most needed functionalities, then the ones that are needed next, and then the so called over the top cream functionalities. To deliver in a feature by feature manner, we need to prioritize the feature list from the user’s angle.
- Define iterations and time boxes: The first thing which must have clicked your mind is we should deliver a group of features, but that’s not the case in FDD. We deliver according to the size of the iteration. An iteration is based on “timeboxes” so that we know how long the iteration is. Depending on the time boxes, whether features can be delivered or not is decided.
- Plan Iteration: At the start of every iteration, we need to plan it out how we are going to execute the plan.
- Create release: We code, test, and deliver according to the plan chalked out in the “Plan Iteration” phase. If everything is OK, we move ahead, if not we take the next iteration.
Figure: Structure of an FDD project
The above defined FDD cycle is an overall view. Let’s go deep into how every iteration will be executed. The figure below ‘Steps in iteration’ shows how an iteration execution happens in a detailed manner.
- Iteration kick start: The length of the iteration is already defined but just in case you want to validate it, then this is the phase.
- Plan features for the iteration: This is the phase where we prepare our WBS. We map the features to work packages in WBS. This plan has to be accepted by the end user.
- Study requirements: In this section, we write a detailed requirement document / user story or use cases.
- Design architecture: This is the phase where we chalk out the overall architecture of the iteration and features. Once the design is done, we review the architecture for any issues and we iterate to close the review.
- Write test plan: Before we start coding, we write test plans to validate the features of the iteration.
- Execution: We do the coding according to the design decided in the design phase of the iteration.
- Testing: Once the execution is done, we run the test plans written in the ‘Write test plan’ phase. In case of any failures, we move back to execution and fix them. We also run the acceptance test plans from the user angle at this phase.
- Deploy: Finally we are done and we deploy at the end customer premises.
- Next iteration: In this phase, we analyze what features we have delivered and we pass them on to the next iteration. If everything is fine, we take up the next iteration.
Figure: Steps in an iteration
Testing is done at the end of each iteration. This ensures frequent checks on each deliverable of every iteration.
Can you explain the concept of time boxing?
Every iteration in an FDD has to be limited to some kind of timeline. Deciding the length of the timeline for every iteration is termed as time boxing. The same has been explained in the previous question in a detailed manner.
When to choose FDD and when to choose XP?
Iterations in XP are small, i.e., between 1 to 4 weeks. This sounds good for smaller projects, but when it comes to large projects, iterations go for months. That’s where FDD comes i to the picture. Iterations in FDD can go for months and probably years.
What is SCRUM?
SCRUM is a methodology which believes that rapid changes in customer requirements can not be solved with the traditional approach. So it adopts an empirical approach where it believes problems can not be understood or defined. Rather concentrate on the team’s ability to respond to emerging requirements.
What does product owner, product back log, and sprint mean in SCRUM?
Before we understand the SCRUM cycle, let’s get familiar with some terms regarding SCRUM.
- Product owner is the end customer or the user.
- Product back log is a list of prioritized items to be developed for a software project.
- Sprint is the task breakup of the product catalog. It’s the detailed task breakdown for a development team.
The figure ‘Product catalog and sprint’ below shows a typical product catalog broken into sprint. In the left hand side of the figure, we have two items in the product backlog: “Create Customer” and “Create Supplier”. To complete “Create Customer”, the developer needs to do the following sprint tasks: “Code Business Logic”, “Design UI”, and “Prepare Test Plans”.
Figure: Product catalog and sprint
Can you explain how SCRUM flows?
The figure ‘SCRUM flow’ shows how the development flow moves in a project. We will understand the SCRUM flow step by step.
- Step 1: Product owner (i.e., the customer) creates a list of product logs (list of functionalities).
- Steps 2 and 3: In these phases, we sit with the customer and prioritize the product catalog. We discuss with the customer which functionalities are a must and must be delivered first.
- Steps 4 and 5: In both these phases, we breakdown the product catalog into tasks called a sprint backlog.
- Step 6: We start executing the sprint task and monitoring the sprint activity.
- Steps 7 and 8: Once we are done with the sprint activity, we take the next sprint / task by going to the sprint phase.
- Step 9: If there are no more sprint / task, the product log has been completed, which means the project has been completed.
Figure: SCRUM flow
Can you explain the different roles in SCRUM?
SCRUM has different terminologies when it comes to role names. Below is a list of roles with what they actually mean. People with pig roles are those who are committed to the project. If the project fails, it affects these people. So the pig roles are developer, customer, project manager, etc.
- Product owner means the end customer or user.
- Scrum master is the process driver. These are the people who drive the scrum process. They are consultants for Scrum processes.
- People with chicken roles work indirectly on the project. They do not really benefit from the project but their feedback is valuable to the project. They can not be held responsible if the project is not successful.
Figure: SCRUM roles
Can you explain DSDM?
DSDM, also termed as Dynamic Systems Development Method, has the following characteristics:
- It’s based upon RAD (Rapid Application Development).
- DSDM is best suited for projects which have tight schedule and budgets.
- It’s iterative and incremental.
Figure: DSDM characteristics
Can you explain the different phases in DSDM?
DSDM has three basic phases: pre-project, project life cycle, and post project phase.
- Pre-project phase: In this phase, the project is identified, project funds are allocated, and commitment from all stake holders is ensured.
- Project life cycle phase: This is the most lengthy and detailed phase in DSDM. This is where all the actual project execution happens. This phase is explained in a more detailed manner in the coming section.
- Post-project phase: In this phase, the system is operating smoothly. The main activity conducted in this phase is maintenance, enhancements, and project defect fixes. Maintenance, enhancements, and defect fixing can be viewed as an iterative and incremental nature of DSDM.
Figure: DSDM phases
Can you explain in detail the project life cycle phase in DSDM?
There are in all five phases in the DSDM project life cycle:
- Feasibility Study: During this stage, the project used for DSDM is examined. For that, we need to answer questions like "Can this project fulfill the business needs?", "Is the project fit for DSDM?", and "What are the prime risks involved in the project?".
- Business Study: Once we have concluded that the project has passed the feasibility study in this phase, we do a business study. The business study involves meeting with the end customer/user to discuss about a proposed system. In one sentence, it’s a requirement gathering phase. Requirements are then prioritized and time boxed. So the output of this phase is a prioritized requirement list with time frames.
- Functional Model Iteration: In this phase, we develop a prototype which is reviewed by the end user.
- Design and Build Iteration: The prototype which was agreed by the user in the previous stage is designed and built in this stage and given to the end user for testing.
- Implementation: Once the end user has confirmed everything is alright, it is time to implement the features.
Figure: DSDM project life cycle
Can you explain LSD?
Lean software development has derived its principles from lean manufacturing. The figure below ‘Principles of LSD’ shows all the principles.
Figure: Principles of LSD
Let’s understand in brief about the principles.
- Eliminate waste: Only deliver what’s needed to the end user. Anything more than that is a waste. In short, anything which does not add value is a waste. If we can bypass a task and still deliver, then it should be bypassed.
- Decide as late as possible: Software systems are complex. The more they are near to execution, more is the clarity. So delay decisions so that they can be based on facts rather than assumptions. For instance, your team decides to use automation testing, but when you complete execution, you come to know the changes are delivered every day by the developer. After execution, you conclude manual testing is the best option. The bad part will be if you have already bought an automation tool, it is a waste of money.
- Deliver as fast as possible: The faster a product is delivered, the faster you will get a user response, and the faster you can improve the next iteration. The concept is not fast coding, but trying to deliver small user identified chunks for better understanding.
- Motivate team: Team members is the most important aspect for the success of any project. Motivate them, give them roles, keep your team spirit high, and do whatever you can do to make them feel good in the project. A highly motivated team delivers a project on time.
- Integrity: Software systems should be delivered in loosely coupled components. A component or module can function individually and when integrated with a project, it works perfectly well. It should be a plug and play from the end user point of view. This spirit is derived from how the actual production system works. You can assemble a car with wheels from one organization and seats from another organization.
Can you explain ASD?
ASD (Adaptive Software Development) accepts that change is a truth. It also accepts in principle that mistakes can happen and it’s important to learn from those mistakes in future. The figure ‘ASD cycle’ shows three important phases in ASD.
Figure: ASD cycle
Let’s understand all the three phases in a detailed manner.
Figure: Speculate
- Speculate (nothing but planning): This is the planning phase of the ASD cycle. The below figure ‘Speculate’ shows in detail what happens in this phase.
- Define project scope: This is the first phase in the main speculate phase. In this, we set the main goals and the scope of the entire project.
- Set time for scope: Timelines are decided for the scope identified in the previous phase.
- Decide the number of iterations: Depending on the time lines and the scope, we identify how many iterations the project will have.
- Break scope to tasks: In this section, we break the scope in to tasks. Tasks are nothing but development activities which a developer has to do to complete a scope.
- Assign tasks to developers: Assign the tasks to developers. Now that we know who will do what task, it is time for coding / execution.
- Collaborate (coding/execution): Execute as per the tasks and test it.
- Learn (Review and give feedback to planning): At the end of the iteration, see what lessons we have learnt and apply them on the next iteration.
Note
From all the methodologies shown above, XP is the most used for Agile. One of the important points to be noted about all the XP methodologies described above is that everybody believes in accepting changes. Principles of all agile methodologies are more or less the same. So do not get confused, just understand what every methodology concentrates on. For instance, FDD plans around features, SCRUM uses the product owner and catalog for describing a project, DSDM gives importance to RAD. So understand the main theme of the methodologies, but yes the common acceptance is everyone believes in ‘Accepting Changes’.
