Agile Development Part 2

Table of Contents

• Introduction
• Can you explain the concept of refactoring?
• Can you explain the overall structure of FDD project?
• Can you explain the concept of time boxing?
• When to choose FDD and when to choose XP?
• What is SCRUM?
• What does product owner, product back log and sprint mean in SCRUM?
• Can you explain how SCRUM flows?
• Can you explain different roles in SCRUM?
• Can you explain DSDM?
• Can you explain different phases in DSDM?
• Can you explain in detail project life cycle phase in DSDM?
• Can you explain LSD?
• Can you explain ASD?

Introduction

This article is a quick FAQ of Agile. By reading this you will understand fundamentals of Agile and different ways of implementing Agile.
I have been writing and recording lot of architecture related videos on design patterns, UML , estimation and C# projects. You can see the sample videos at http://www.questpond.com. 

Par1 Agile FAQ :- http://www.codeproject.com/KB/aspnet/AgilePart1.aspx. 

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 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, high reusability at the first level itself. Normally it improves over the time. It helps developers to implement the necessary solution today and improve / make the code better tomorrow. Refactoring is the process of changing the system to improve the internal structure with out changing what the system does. Below are 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 the same with your pair developer and implement the same. For instance below is code which was further simplified in to one equation:
 

Figure: - Simplify Code
 

Move similar operations in to reusable code.
If we are having similar operations move them to one reusable code. For instance in the below class we have various sort function which sorts by phone, code, name and date. We can combine the same in to one function called as sort and make it simple.
 

Figure: - Reusable code

Remove duplications and redundancy

When a project has constrained time lines it’s very much possible that project can have lot of duplications. So when developers have executed the task 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 had repetitive fields like mobile number, land line and office number. In abstract terms these represent telephone numbers. So we split the customer table in to two tables one is the customer table and the other is customerphone and built a relationship between them.

Figure: - Remove Duplication 

Below is again one more 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 in to 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 use case or a user story. It should also be planned and manageable. Feature 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 project?

FDD is an iterative methodology to deliver projects. Rather than delivering projects in one go manner we deliver the features with in time limits. So let’s understand how the FDD cycle moves. We will have two views one is the over all flow and one is the detail iteration flow.
Below figure ‘Structure of FDD project’ shows step by step approach for FDD project.

• 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 deliver everything at the first step itself, but that’s practically difficult. Rather deliver first the most needed functionalities, then needed and then so called as over the top cream functionalities. To deliver in 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 in group of features, but that’s not the case in FDD. We deliver according to the size of iteration. Iteration is based on “timeboxes” so that we know how long iteration is. Depending on the timeboxes the features can be delivered or not is decided.
  The below points are looped for every iteration (below sections are covered in more detail in the coming up section).
• 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 “Plan Iteration” phase.
  If everything is ok we move ahead if not we take the next iteration
   

Figure: - Structure of a FDD project 

The above defined FDD cycle is an overall view. Let’s go deep in to how every iteration will be executed. Below figure ‘Steps in Iteration’ shows how an iteration execution happens in a detailed manner.

• Iteration Kick Start: - The length of 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 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 any issues 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 the same. We also run the acceptance test plans from the user angle at this phase.
• Deploy: - Finally we are done and we deploy the same at the end customer premises.
• Next Iteration: - In this phase we analyze what features we have delivered and if not we pass it on to the next iteration. If everything is fine we take up the next iteration.
   

Figure: - Steps in a Iteration 

Testing is done at 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 FDD has to be limited to some kind of timelines. Deciding the length of timelines for every iteration is termed as time boxing. Same has been explained the previous question in a detailed manner. 

When to choose FDD and when to choose XP?

Iteration in XP is small i.e. between 1 to 4 weeks. This iteration sounds good for smaller projects, but when it comes to large projects, iteration go in months. That’s where FDD comes under picture. Iterations in FDD can go in months and probably years.

What is SCRUM?

SCRUM is a methodology which believes rapid changes of customer can not be solved by traditional approach. So it adopts an empirical approach where it believes problem can not be understood or defined. Rather concentrate on the team’s ability to respond to the 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 product catalog. It’s the detail task break down for a development team.

Below figure ‘Product Catalog and Sprint’ shows a typical product catalog broken in to sprint. In the left hand side of the figure we have shown two items in the product back log “Create Customer” and “Create Supplier”. To complete “Create Customer” the developer need to the following sprint task “Code Business Logic”, “Design UI” and “Prepare Test Plans”.
 

Figure: - Product Catalog and Sprint 

Can you explain how SCRUM flows?

Below 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 log (list of functionalities).

Step 2 and 3:- In these phases we sit with the customer and prioritize the product catalog. We discuss with the customer which functionality is must and must be delivered first.

Step 4 and 5:- In both these phases we breakdown the product catalog in to tasks called as sprint backlog.

Step 6:- We start executing the sprint task and monitoring the sprint activity.

Step 7 and 8:- Once we are done with the sprint activity, we take the next sprint / task by again going to the sprint phase.

Step 9:- If there are no more sprint / task the product log is completed, which means the project is completed.
 

Figure: - SCRUM Flow

Can you explain different roles in SCRUM? 

SCRUM has some different terminologies when it comes to role names in SCRUM. Below is the list of roles with what actually they mean.
People with pig roles are those people who are committed to the project. If the project fails it affects these people. So of 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 process.
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 different phases in DSDM? 

DSDM has three basic phases Pre-project, Project life cycle and Post project phase.

1. Pre-project phase: - In this phase project is identified, project funds are allocated and commitment from all stake holder is ensured.
2. Project life cycle phase: - This is the most lengthy and detail phase in DSDM. This is where all actual project execution happens. This phase is explained in a more detail manner in the coming section.
3. Post project phase: - In this phase system is operating smoothly. The main activity conducted in this phase is maintenance, enhancement and project defect fixes. Maintenance, enhancement and defect fixing can be viewed as iterative and incremental nature of DSDM.

Figure: - DSDM Phases

Can you explain in detail project life cycle phase in DSDM?

There are in all five phases in DSDM project life cycle:-

1. Feasibility Study: - During this stage the can the project be used for DSDM is examined. For that we need to answer questions like "Can this project fulfill business needs?", "Is the project fit for DSDM?" and "What are the prime risks involved in the project?".
2. Business Study: - Once we have concluded that the project has passed the feasibility study in this phase we do a business study. 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.
3. Functional Model Iteration: - In this phase we develop prototype which is reviewed by the end user.
4. 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.
5. Implementation: - Once the end user has confirmed everything is alright its time to implement the same to the end user.
    

Figure: - DSDM Project Life Cycle

Can you explain LSD? 

Lean software development has derived its principles from lean manufacturing.
Below figure ‘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. In short we can by pass tasks 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 in facts rather than assumptions. For instance your team decides to use automation testing, but when you complete execution you come to know changes are delivered every day by the developer. After execution you conclude manual testing is the best option. Bad part will be if you have already bought an automation tool, its waste of money.

Deliver as fast as possible: - faster a product is delivered, faster you will get user response and faster you can improve in the next iteration. The concept is not fast coding, but try to deliver is small user identified chunks for better understanding.

Motivate team: - Team members are the most important aspect for success of any project. Motivate them, given them roles; keep your team spirit high and whatever you can do to make them feel good in the project. A highly motivated team delivers project on time.

Integrity: - Software system should be delivered in loosely coupled components. Every component or module can function individually and when integrated with the 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 actual production system work. You can assemble a car with wheels from one organization and seats from other organization. 

Can you explain ASD?

ASD (Adaptive Software Development) accepts that change is a truth. It also accepts in principles that mistakes can happen and it’s important to learn from those mistakes in the future. Below figure ‘ASD Cycle’ shows three important phases in ASD.

Figure: - ASD Cycle

Let’s understand all the three phases in a detail manner.

Speculate (nothing but planning):- This is the planning phase of ASD cycle. 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 what’s 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 will the project have.

Break Scope to tasks: - In this section we break the scope in to tasks. Tasks are nothing but development activity which a developer has to do to complete the scope.

Assign task to developers: - Assign those task to developer.
Now that we know who will do what task, its time for coding / execution.
 

Figure: - Speculate

Collaborate (coding / execution):-Execute as per the task and test it.

Learn (Review and give feedback to planning):- At the end of iteration see what lessons we have learnt and apply the same for 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 every body believes in accepting change. Principles of all the agile methodologies are more or less same. So do not get confused just understand what every methodology concentrates on. For instance FDD plans around features, Scrum uses 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 every one believes on ‘Accepting Changes’. 

You must Sign In to use this message board.

FAQ  Noise Tolerance Very HighHighMediumLowVery Low  Search Messages    Layout Expand All MessagesThread ViewNo Javascript (slow)No Javascript Preview    Per page 102550

Msgs 1 to 8 of 8 (Total in Forum: 8) (Refresh) FirstPrevNext

Nice , Sweet and to the point Kfeeder 19:20 9 Nov '08   I think if i had read 10 books i still would not have understood Agile they way you put it in couple of FAQ....Great work. I read this article in 10 minutes and damn i can atleast now feel what Agile is all about. One more great article to your list...Good going. Sign In·View Thread·PermaLink What's the acronym FDD stands for? Liu Junfeng 0:10 31 Oct '08   What's the acronym FDD stands for? I am happy to work with people doing great projects. Sign In·View Thread·PermaLink This is nice. Rajesh Pillai 2:36 18 Oct '08   Thanks. Enjoy Life, Rajesh Pillai http://rajeshpillai.blogspot.com/ http://simply-url.blogspot.com/ Sign In·View Thread·PermaLink Link to Part1 cwp42 21:11 17 Oct '08   Thanks for your very informative article. Finding Part 1 could be more easier. Good Luck cwp42 Sign In·View Thread·PermaLink Nice overview Urs Enzler 5:59 6 Oct '08   You're article is a good overview of agile terms. Only one thing: I don't agree with you about when XP or FDD should be used considering the size of the project. Even in large projects (meaning large in the sense of man-months and not in team size) a small iteration or sprint timeframe works very well. I think, that the iteration length has nothing to do with the size of the project but with the size of the team. It will not be possible to have a 50 person team and a two week iteration. Acctually, all agile methods tend to have smaller teams - by splitting up projects if necessary. In my current project we use Scrum with TDD (Test Driven Development) with a sprint of two weeks, ~10 developers, 18 months duration. And we're very happy with this iteration duration. Thanks again for sharing your article Urs -^-^-^-^-^-^-^- no risk no funk Sign In·View Thread·PermaLink Sometimes simplification leads to change of meaning Mykola Tarasyuk 20:57 5 Oct '08   >> Figure: - Simplify Code Sometimes simplification leads to change of meaning. Local (unassigned!!!) variable in the left part changes to class field in the right part. Sign In·View Thread·PermaLink Re: Sometimes simplification leads to change of meaning Shivprasad koirala 21:53 5 Oct '08   I am sorry for that. Wanted to show the essence of simplicity i will rectify it. When i die i die programming Sign In·View Thread·PermaLink 5.00/5 (1 vote) Re: Sometimes simplification leads to change of meaning RuslanCanada 6:04 6 Oct '08   Agree. Also, it can lead to hindering of code maintainability, readability and effectiveness. Having an extra assignment to a variable can significantly simplify debugging process, by thus minimizing time during bug fixing. And, such assignments are often optimized by the compilers and affect on the code effectiveness very little. Having complex functions can lead to big and cluttered logic inside of the functions and may lead to branching out of such functions into smaller functions. Therefore, combining of functions should be made where it is appropriate. Knowing of design patterns is essential when writing such code. Another question that I have is how does the DSDM and ASD fit into the agile approach? I don't really see a place to fit relatively frequently changing requirements into the process. Unless you define requirements yourself, it may affect project time lines significantly and will affect the cost of the project. Is the project considered complete without providing documentation? Every time a requirement change late in the project life time, you would have to spend (waste) time on updating use cases, performing impact analysis (functional, code, etc.), update (re-write) test cases, make code changes and sometimes re-factor code base, perform automated and/or manual integration and regression testing, update documentation. One more thing that is often overlooked by project managers is the code review stage. How do you learn if you don't know what mistakes you have made? Please, do not understand me wrong. I am not against agile approach. Obviously, it works for many people. But, my concern is that not everyone understands it properly, making assumptions or coming up with theories that look good on paper. It is beneficial for the clients that are lazy or inefficient to create proper requirements in the first place. It is easier to blame development team for delivering poor quality project or for not delivering not on time without taking into consideration that the requirements were incomplete in the first place and how many changes and what kind of changes in requirements have been made. In my opinion, project manger should be in control of the project and should not be put into the defending position, unless he or she deserves it. Unless a theory is backed up by a practical implementation, it is what it is, only a theory. Shivprasad, I think you are did a decent job writing your articles, but I really wish you had more real-life examples that truly reflect the nature of your articles. Sign In·View Thread·PermaLink

Last Visit: Friday, November 21, 2008 1:58 AM     Last Update:Friday, November 21, 2008 1:58 AM