Agile - TDD, Simple Design, Refactoring, Evolutionary Design

Test Driven Development, Simple design, Evolutionary design and Re-factoring are interrelated topics. I am going to cover these topics, one by one.

TDD: 

TDD stands for Test Driven Development. I was fascinated with this term during my initial days in eXtreme Programming (XP). I was curious. I wanted to understand the philosophy behind it. I joined XP team from Waterfall background. Best Practices of XP were new to me. However, the terminologies were interesting!

As the name suggests, Test Driven Development is when development work is driven by testing. That means you create your unit tests first, then you progress through coding. How can it happen?

Ø        First you write automated unit test.

Ø        Run the unit test.

Ø        Test will fail since there is no supporting business code yet.

Ø        Next thing is you write the business code.

Ø        Run the same unit test.

Ø        Test will pass if your code is correct.

You test first, and then you develop the code. This practice is often termed as TFD, Test First Development.

Creating a unit test helps a developer to really think what needs to be done. Requirements are understood and nailed down firmly by unit tests. There can be no misunderstanding a specification written in the form of executable code.

Let me explain the process:

Ø        You are a programmer. A user story is given to you.

Ø        You break down the story into tasks.

Ø        Again you break down a task in your mind into pieces of requirements.

Ø        You create one unit test to define some small aspect of the problem at hand.

Ø        Then you create the simplest code that will make that test pass.

Ø        You take next small piece of requirement from the user story.

Ø        Create a second test

Ø        Implement code to satisfy the second test.

Ø        The above process continues. Unit test suit builds up. By the time you code the whole user story, it will be 100% unit tested.

So now you realize, writing of code is driven by unit tests. TFD is turned into TDD.

Benefits:

1.        Developers know what exactly the requirement. Requirements are understood and nailed down. You are writing clean code that works.

2.        Less chance of scope creep.

3.        No untested code makes it to the system. TDD is a tool to ensure full code coverage.

4.        There is also a benefit to system design. It is often very difficult to unit test some software systems. These systems are typically built code first and testing second, often by a different team entirely. By creating tests first, your design will be influenced by a desire to test everything of value to your customer. Your design will reflect this by being easier to test.

Mike Cohn recommends to do TDD for its testing benefits; any potential design improvements it brings as a bonus.

5.      You can get suggestions from your pair programmer while doing TDD to ensure better quality of code. Please check pair programming session at: http://chandrimachoudhury.blogspot.in/2013/11/agile-pair-programming-what-why-when.html

Kent Beck popularized TDD in case of XP. Beck's concept of test-driven development centers on two basic rules:

1.        Never write a single line of code unless you have a failing automated test.

2.        Eliminate duplication.

There is well-known objection about TDD. They say “Test First Development (TFD) takes longer; we don’t have time to waste.” I searched Mike Cohn. And he says: “There is evidence that doing TDD takes about 15% longer than not doing TDD (George and Williams 2003). But there is also evidence that TDD leads to fewer defects.”  TDD may take longer initially, but this is a tool you can use to make your code-to-the-point, assure higher percentage of code coverage. Those white box testers out there, do you have any different opinion?

My personal take is, if your code is testable 100% by unit tests, there is reduced number of defects during black box testing. As a result, reduced bug fixing and maintenance time. One more aspect is, developer nails down the requirement while writing unit tests first, the code has to satisfy the unit test. In this process, developer tends to understand the requirement in detail. This gives a chance to clarify the requirement gap found in stories (if any), leading to reduced number of defects found in the later stages of testing.

Simple Design: 

Sounds so simple! Yes, it is.

Simple design is something you have to practice while coding in agile. Agile (SCRUM and XP both) preaches simple design. Generally, in waterfall or V model, when a new functionality is conceptualized,

Ø        Requirement documents (SRS) are written.

Ø        HLD(s) are derived from requirement documents. There are rounds of reviews with client, subject matter experts, and application development teams. Sometimes requirements are progressively elaborated in iterative manner and HLDs keep getting complicated.

                  HLDs cover the design/architecture of new implementation that is part of whole system/application’s architecture. It contains database design, interface details, interface dependency details.

Ø        HLDs are broken down into LLDs (Lower Level Design). Low Level Design (LLD) is like detailing the HLD. It defines the actual logic for each and every component and each transactions of the system/application. UMLs (Unified Modeling Language) are normally part of LLDs. LLDs may contain class diagrams or object diagrams with all the methods and relationships between classes/objects. Developers interpret the diagrams and understand the relationship that may be called as Instance level relationship or Class level relationships.

Ø        What I want to tell here is developers/lead developers concentrate on whole design of the new code implementation and how the new design fits into the existing design/architecture.

Ø        They start coding in big-bang style when HLD/LLD is baselined.

Ø        When coding is complete, the code-build is deployed to test machines for testers to test it. (Functional/black box for example).

People coming from waterfall background, will find the “simple design” practice uncommon. It is a paradigm shift from how we proceed to code in conventional waterfall model to how we are supposed to code in agile. It is technical practice change.

Philosophy of agile is to have trust on the team. Team will deliver high quality, potentially shippable code at the end of each sprint/iteration. And when team has to deliver a working product after each 15 days (normally the length of each iteration/sprint), it is unlikely team will invest much time on thinking about big up-front design/architecture, review it, baseline it.

Am I talking design is not at all required in Agile? No, not at all.

While a robust architecture for application is important, the implementation strategy for individual user stories should be simple. The idea is to not over engineer the implementation of user stories, only plan and implement exactly what’s necessary. If you over engineer there is a high likelihood that the user story will change, and the additional work put in will amount to waste.

To sum up:                                                                                                                                     

1.        When you start working on a story, your first intention would be to implement the story, with simple solution in mind. You pair program, code the story, integrate the code with existing code by continuous integration tools, let the code and story pass unit tests and acceptance tests and let the whole integrated code pass if automated regression testing is applicable. You have shippable working product now. With this, you are in a position to give demo to the client.

2.        Now, if you feel an urge to improve the code design, if you feel to eliminate some duplicate code, or if you feel like moving a piece of code from one class to another (in case of object oriented programming) to make the module independent, maintainable, understandable – you do it. This is normally called re-factoring. I am going to elaborate this later in this session. Generally SCRUM/XP team keeps last 2-3 days for re-factoring work to be done. One or two persons in the team can identify areas of improvement and they re-factor the code. If, for example, an experienced team member is already aware of an impending story from the next iteration/sprint, and if he knows the current re-factoring of the code will help to implement that future story in a plug and play manner, he can go ahead with re-arranging/re-factoring the code in current sprint. Remember to follow activities like re-run unit test, re-run acceptance test, continuous integration, regression test after re-factoring is over. At the end of the day, customer wants a working product from you.

3.        Keep your design simple so that whole code is testable by Test Driven Development (if you follow), to make sure no untested code makes it into the system. On the other hand TDD helps to improve the design.

4.        Keep your design simple to make sure you can reach up to a certain code coverage percentage set by your client/product owner/internal quality policy guidelines, without spending significant amount of time.

Any objection? Yes, objections are bound to happen. Architecture experts often come up saying “I must decide architectural design first because I am working on a complex system”.

Yes, on a complex or large system, you probably will have a vision of architecture. However, the idea that being agile is about finding a right balance between anticipation and adaptation. How much architectural thinking to do up-front is of course your decision. Having said this, do not over-think design when it is not actually necessary.

In DonaldKnuth's paper "StructuredProgrammingWithGoToStatements", he wrote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.”

Evolutionary design: 

Evolutionary design is popularized by XP. Unlike waterfall model, there is an understanding in Agile that user story elements will change with time, so a Scrum team should expect to update the implementation strategy for those user stories with every new iteration. Evolution of design is an expected change in Agile. It is a viable design strategy of Agile. The idea is that the implementation strategy can change as new information is determined, so the Scrum team makes the updates accordingly, and quickly seeks feedback from the Product Owner.

Experts in Agile say programmers are expected to get used to life without big design. Why to invest big time to think on permanent design of the system, when requirement change is inevitable in Agile, hence, re-work is inevitable?

Refactoring: 

The definition says it is the process of clarifying and simplifying the design of existing code, without changing its behavior. Refactoring changes the structure of code, not its behavior. In some organizations, refactoring is termed as “technical debt”. That means they indicate team will come back and will improve the quality of code without changing its behavior.

Let me give you an example. Suppose a programmer has two methods (A and B) that each contains five identical or repetitive statements. In this case you refactor in this way:

Ø        Identify five identical statements.

Ø        Write a separate common method C that contains only those five identical statements.

Ø        Call C from two parent methods – A and B.

What I achieved by this? Well, I can list them down:

1.        Better readability

2.        Better maintainability since I reduced duplication. The duplicated code is now in a single location, method C.

3.        Method C can be reused in other places when required.

When refactoring, take care of the following:

1. If the new method C (above example) is a procedure (does not return any value) and just executes the statements, refactoring is easier.

2. If method C (above example) is supposed to do initialization operation or is supposed to return value to its calling method A and B or it is supposed to have certain signature (input parameters), assure you are taking care of these factors.

Try this code snippet:

Before Refactoring:
 
/* populate combobox1 with names */
private void PopulateCombo1()
{
String[] names = { "Vick", "Dave", "Miranda", "Felix", "Joseph" };
       comboBox1.Items.Clear();
       comboBox1.Items.Add(names[0]);
       comboBox1.Items.Add(names[1]);
       comboBox1.Items.Add(names[2]);
       comboBox1.Items.Add(names[3]);
       comboBox1.Items.Add(names[4]);
}

/* populate combobox2 with departments */
private void PopulateCombo2()
{
String[] departments = { "Sales", "Marketing", "Engineering", "Human Resource", "Administration" };
       comboBox2.Items.Clear();
       comboBox2.Items.Add(departments[0]);
       comboBox2.Items.Add(departments[1]);
       comboBox2.Items.Add(departments[2]);
       comboBox2.Items.Add(departments[3]);
       comboBox2.Items.Add(departments[4]);
}

After Refactoring:

/* populate combobox1 with names */
private void PopulateCombo1()
{
String[] names = { "Vick", "Dave", "Miranda", "Felix", "Joseph" };
       PopulateCombo(comboBox1, names);
}

/* populate combobox2 with departments */
private void PopulateCombo2()
{
String[] departments = { "Sales", "Marketing", "Engineering", "Human Resource", "Administration" };
       PopulateCombo(comboBox2, departments);
}

/* populate a given combobox control with a given String array */
private void PopulateCombo(ComboBox control, String[] sArr)
{
control.Items.Clear();
       foreach (String item in sArr)
           control.Items.Add(item);
}
 
 In the above example, methods A and B turn to be PopulateCombo1() and
PopulateCombo2(). Method C is PopulateCombo(). The "duplicate statements" in PopulateCombo() are replaced by foreach loop to give the code professional look.

Hope this helps!

Programmers with C# skill may wish to go through following:

http://www.jetbrains.com/resharper/features/code_refactoring.html

I used ReSharper tool that could be integrated with Visual Studio. You may wish to analyze the code manually and try to refactor the code. If you aim to refactor in large scale or if you want to refactor multiple functions, you may take help of a refactoring tool to avoid issues leading delay.

I cannot suppress my temptation to mention a few lines from Mike Cohn:

“Refactoring is not only crucial to the success of TDD, but it also helps prevent code rot. Code rot is a typical syndrome in which a product is released, its code is allowed to decay for a few years, and then entire re-write is needed. By constantly refactoring and fixing small problems before they become big problems, we can keep our applications rot free.” Robert C. Martin calls this the Boy Scout Rule.

The Boy Scouts of America have a simple rule that we can apply to our profession: Leave the campground cleaner than you found it. If we all checked-in our code a little cleaner than when we checked it out, the code simply could not rot.

Refactoring should be made a regular practice. If the whole team needs couple of days to refactor in every iteration/sprint, then probably it is a sign of different problem. If the team insists the product owner not to bring any change in current sprint because they are refactoring the current code, then again probably it is a sign of different problem. In these cases refactoring probably can be part of product backlog itself.

Reference:

1. http://www.extremeprogramming.org/rules/testfirst.html

Agile - Pair Programming - what, why, when, how and few objections against this practice

Pair programming:

When I heard there is something called “pair programming” 8 yrs. back when I joined an Agile team, I was fascinated. I was like “WOW”…what is that? I was swayed away by open atmosphere created in our team, and moreover perhaps I was more of relieved to know that my peer would review the code when I would be coding! Errors made by me would be immediately caught and would be rectified. Since this would be collaborative effort, everyone would be responsible for the code quality and I hoped to get hands-on guidance/training from my seniors in the team as well.

What is pair programming?

Pair programming is something where two programmers are engaged in coding, one being driver (actively writing the code), other being navigator (reviewer). They can switch the role periodically.

The navigator is expected to review the code when the driver is coding. Normally navigator gives the strategic direction on code, after having an open and honest discussion with her partner. Concept of user stories and pair programming shift the focus from regular waterfall documentation to discussion. Of course, we have to be engaged with effective and to the-point discussion.

When can you contribute to a discussion? – Yes, you are right, when you are a good conversationalist. As Dale Carnegie said, “to become a good conversationalist, you have to be an attentive listener”.  Ask good questions. Give honest input.

My experience is, pair programming is more effective and produce best result when both programmers are matured, good listeners and both believe on collective ownership of code. Pair programming can be a wonderful learning experience for both the programmers if both of them add value to code, if both of them are engaged with fresh thinking that is aligned with the story they are working on.

Driver and navigator generally have useful and effective conversation on, for example,

1.        improve code quality

2.        if a class/function(s)/module needs to be re-factored. If yes, they can discuss on effective way of re-factoring the code on-spot before proceeding to further coding.

3.        code coverage/statement coverage. If the agile team is following TDD (Test Driven Development), the pair programmers are normally concerned about the code coverage.

4.        they can decide to concentrate more on complex area of a class/function/module.

5.        spike/brainstorm on some issue

Why pair programming?

Probable answers are:

1.        Fundamental intention being code-review happens sooner and as a result; this gives wonderful chance to rectify the code sooner than the total time aggregated by series of process activities like - code-build goes to tester, tester finds a requirement gap (for example), raises defect, defect is picked up by developer, developer discusses with peers/HLD owner and then resolves it.

2.        Pair programming facilitates the knowledge transfer. This is an ideal way to bring new developers up to speed on the application.

3.        If in case, pair programming is genuinely not possible 100%, then team can gauge over most difficult area in the code or most sensitive module of the code. XP coach or SCRUM master can determine the stories that really require pair programming. Identify stories that may not be independent, i.e. code depends on other code module. Identify some stories that may not be clear from requirement point of view, OR some portion of the code seem like non-testable – those cases, pair programming is supposed be effective.

4.        XP coach or SCRUM master takes care of another aspect of pair programming, which is move people around.

         This helps the idea of “team” feeling, “collective ownership”, cross functional team. Members of a pair can break once a task is complete and pair with other member.

How pair-program?

Pair program, as the name suggests, two people working on a task on a single computer.

The best way to pair program is through co-location, sitting side by side in front of the monitor. Slide the key board and mouse back and forth. Both programmers concentrate on the code being written.

However, I observed an issue with this style of pair-programming set up. The navigator, if he has an input and wants to modify the code, he sometimes “hover over” the keyboard when the key board is with the driver. The best way I experienced was, having single monitor but a pair of keyboards and a pair of mouse, each device with each programmer of a pair.

Objections:

Sometimes, management discourages pair programming.

 Objections/concerns are raised from management point of view.

1.        “Pair programming is expensive. Why shall I pay two programmers for a job that can be done by one person?”

-Pair programming will cost more in short term. However, that additional initial cost will very likely be paid back with shorter schedules and with higher quality. That means lower maintenance cost. Since discussions and code-review get done at the same time of coding, there is less chance of missing a requirement, less chance of affecting an already existing functionality with your new code. This can be reinforced again by automated regression testing, I shall touch upon later.

Mike Cohn advises “Pair on the most difficult modules and see if they have fewer defects and are easier to maintain later, perhaps in comparison to similar modules from other programs done without pair programming.”

2.        During my initial days of exercising pair programming when I was in an Agile team (eXtreme Programming), I myself thought –“why the XP coach is deploying two resources to do one task. We are in hurry.”

-I asked her one day shading all my inhibitions. She was calm and replied “this is the time- we need pair programming the most”. Gradually I experienced, pairing leads to shorter project duration since fewer hours passed on the clock (it may take more person hours). High-visible projects are always under financial pressure. However, the comforting fact is- the overriding concerns are not so much person-hours as time to market. After all, everyone’s aim is to get the product faster in the market.

At last, ideally pair programming is not a mentoring program. There is not teacher-student relationship. The pair programmers are co-programmers, they are peers.

Agile: About continuous learning and how we can plan to learn

Plan to Learn is important concept and competency in Agile/SCRUM.

Management strives to foster team learning in different ways. If the scrum team behaves as whole team, if the scrum team is self-organized- this is when scrum master becomes happy and satisfied. Hold on! There are always scope of learning and improvement. The team is already performing, product owner is happy. Then why team needs improvement? Striving and achieving for knowledge improvement is again incremental and iterative process like SCRUM itself.

I must quote Mike Cohn’s remarks here. He discussed how to ensure learning conditions exist in the team.

In the proactive pursuit of team learning as a goal of the project, there are five conditions that are necessary for team learning to occur:

1.        Teams must be designed for learning.

2.        Individuals must have concrete ways of sharing knowledge.

3.        Leaders must reinforce the importance of learning.

4.        Teams need to be presented with motivating challenges.

5.        A supportive leaning environment must exist.

I believe these are the soft skills the leaders can cultivate in the team. Scrum team along with leaders can grow together as a “whole team”.

If the scrum environment is open and management foster team learning, there are built-in meetings in scrum that help to learn. Retrospective is one of them.

What is retrospective? Yes, you are right. The parent of English word retrospective is Latin word retrospectare. This means “Look back”. Why do we look back? We look back with the intention to improve. This is team improvement. The retrospective meeting is held by the whole team - Scrum Master, Product owner, scrum team. 

Who is facilitator? Scrum Master. Scrum master can maintain retrospective log. This is useful to validate the action items with next sprint’s events or actions. 

When does the meeting happen? Ideally it should happen at the end of each sprint, when team’s memory is fresh. If the sprint length is two weeks, retrospective normally happen at the end of the sprint, which is after sprint demo.

Ground rules to have successful retrospective? Leaders may wish to lay ground rules like:

1.        The team members need to give honest comments on what went well in the last sprint, what did not go well.

2.        Agile/SCRUM preaches to keep retrospective meeting short, simple and fresh. We followed Thinking Hat method to make the meeting interesting. We used two kinds (colors) of sticky notes - Yellow hat and Black hat. Yellow hat represents optimistic items - what went well. Black hat- what went wrong?

3.        Leaders should emphasize the learning aspect of retrospective, creating open environment. He is refrained from pin-pointing a team member who did not perform well and as a result velocity might not meet expectation.

4.        Promote active participation.

5.        Steal ideas from other scrum teams.

6.        Few steps/activities during retrospective meeting:

a.        Gather data,

b.        Analyze data

c.        Root cause analysis

d.        Generate insight

e.        Take decisions and

f.         Generate improvement plan if any.

The improvement plan and the lessons learnt are to be applied from immediate next sprint/iteration. For example, if there were significant impediments identified in the middle of last sprint and the team mitigated the risk of derailment of sprint schedule, should become a hot topic in the retrospective. 

Retrospective is different from project post mortem by nature. A project post-mortem is a process, usually performed at the conclusion of a project. This is to determine and analyze elements of the project that were successful or unsuccessful. Post-portem is performed when project is in closing phase, meaning there is no scope of implementation of lessons learned in the current project.

Learn through User Stories:

User stories can be defined as Agile requirement that indicates who will benefit, what we’re trying to accomplish, and clear acceptance criteria. Scrum team can learn about the product/service they are working on if they are thorough with each user story.

Having said this, user stories are different from well-formed requirement documents we create and baseline in waterfall model. Let me explain this below:

Initially, when the product is conceptualized, we have only high-level feature descriptions. This might be called “Epic”. Epic can give general shape of a product, but with missing specifics about functionality. Each feature is progressively elaborated as the project progresses.

Why progressively refine requirements?

·          Requirements will change due to priorities change over time.

·          Deliver as much as feature what is asked from scrum team, to give an early visibility of the product to the product owner/customer.

-          It helps us avoid falling into the trap of believing plan - While working in Waterfall model for quite sometime now, I have been creating test plan, reviewing test plan and baseline test plan. I do these series of activities when requirements for a project are said to be baseline. When I am happy considering my test plan is well-documented and is accepted by key stakeholders, I come to know there are quite a few CRs coming on the way and they have test impact. I have no other choice but to re-work on the plan including schedule. 

      Progressively refining a plan emphasizes the idea that even the best plan is subject to change.

  

User stories are derived from Epic-level user stories. Epic is divided into lower level deliverable user stories, forming product backlog. So backlog is desired functionality not present in the product. It is maintained by the product owner and can be shared with whole team. In contrast with traditional requirement documents, product backlog is dynamic in nature. Stories are added, removed, reprioritized each sprint as more learned about the product. Fix of a defect can become a user story in the next sprint or in current sprint if capacity allows.

User stories along with the simple steps are written on a HTML file or WORD file, for the developers to code. These are maintained in software tools.

One interesting fact is name of the user stories are often written on sticky notes and arranged on walls or tables to facilitate planning and discussions. Stories are arranged like: “Not started”. “WIP (Work in Progress)”, “Completed” in the story wall. Don’t you think if you are practicing agile/scrum, you are working in a vibrant ambiance?

Stories typically follow a simple template:

As a (type of user), I want (goal) so that (some reason).

Gaining acceptance on user stories:

Definition of “Done” – Team’s agreement on criteria to determine whether a story is complete

Definition of “Done Done” – Product owner’s acceptance on functionality required to confirm successful completion of a user story.

I have heard an objection while training the team on agile – “We are back-end software developers. We work on database. Why do we have to create user stories?”

Yes. Back-end software developers also have to create and follow user story if they are following agile. We should remember user stories are small chunk of functionality a team can produce in one iteration/sprint.

I have plan to further add some more topics under "Plan to learn" section:

1. Pair Programming

2. Simple design

3. Evolutionary design

4. Spiking

5. Refactoring

6. Team-based estimation  

Coming up next .....till then Happy Reading! 

Agile: About Self-organizing team

As an agile trainer, thought to start a series of articles on Agile/Scrum.

Let me begin with the fundamental concept of agile, that is "team". Agile relies on its team, we love to call the team as "self organizing team".

Self Organizing Teams:

Self Organizing team is a group of individuals, practicing Agile/SCRUM, organize themselves around a problem/challenge given to them by organization, without management’s direct control. Individuals are right people, chosen by management or they are already conditioned and think agile way. They are matured to give and receive feedback in constructive and proactive manner. They work in an open work environment, being "honest" to each other. They understand the client's interest, hence the goal that says delivering the software frequently. As a result, they are groomed and start cultivating the qualities/competencies that help them to deliver frequently. If they are matured to exercise SCRUM, noise will be less in the team. If there is any noise, management should step in to remove impediments. Scrum master is responsible person to guard the scrum team from external and internal impediments.

We believe that agile/scrum starts from “team”, not from “process”. Self-organizing team is fundamental concept of agile software development.

A self organizing team ideally will have following features:

Collective ownership:

Multiple individuals within the Scrum team pull tasks to contribute to the completion of a user story. Everyone shares responsibility for the quality and completion of the code. No single person claims ownership over any part of the system, and anyone can make any necessary changes anywhere. Another way of telling this as team works as “Whole Team”.

Why collective ownership is emphasized in SCRUM? This policy is believed to minimize delay from absent member of the team. The individuals in the team are expected to be cross-functional and owner of whole code. Since every iteration/sprint is time boxed, delay or lag is not entertained.

Cross-functional teams:

Every member of scrum team is expected to be multi-skilled. Does that mean a developer can test or a tester can code? Ideally, yes. However, with growing complexity of the system, this might not be 100% possible. Scrum master should strive to encourage the team to be armed with multi-skills and independent of fellow team member.  Scrum master can create an open environment and reward system that during time of need, right member of Scrum team can step up at right time.  And this is largely possible when the team is small team, isn’t it?

Small teams:

Team size is limited to 5-9 people to ensure everyone knows what the other members are working on. Members will pull unfinished stories and nobody will duplicate effort. The goal is to ensure reduction of waste. I have seen - the team can self-organize themselves, so that few members can work on main user stories of that ongoing sprint, and some can work on re-factoring of existing code to make the code more flexible to adapt change. Experienced scrum member can identify the perfect time of need to re-factor the code.

Parallel development and test:

Fail fast. What is that? Scrum preaches this policy. This means identify defects sooner rather than later. To ensure this, coding and functional test occur at the same time reducing down time for individuals supporting their user stories and catching defects at the earliest.  

I can think of two ways to achieve this:

1.   Pair programming: Two/multiple resources within a scrum team sit together to complete a task/user story. One is driver, who writes the code, and the other member is observer, who reviews each line of code. This way static testing of code can be achieved. The two members can discuss coding techniques, design pattern to follow, optimization of code, code coverage during pair programming. 

2.   TDD, Functional test and Automatic regression test: Test cases in TDD can be unit tests.

            When the code for a user story is committed in a repository, it should be unit test/functional test-passed and regression test passed. Since, scrum is incremental and iterative development methodology, regression test is mandatory.

Sustainable pace or sustainable velocity:

Scrum master should try to achieve this. This is something to do with building trust with Product Owner by being able to deliver a consistent amount of work over multiple sprints. The goal is to drive consistency in delivery. “Whole team”, “independent team members”, “cross functional team” are keys to achieve this competency.

Everything is hunky-dory? Please read on...

Per Mike Cohn, a misconception is that because of this reliance on self-organizing team, there is little or no role for leaders of agile teams. He says, self-organizing team does not free from management control. Control is exercised; but, it is subtle, indirect. Management chooses the product to build, or sometimes chooses the members to work in the project. Management control is exercised when needed, for example, if team needs direction after impediments created from evolution of behavior that comes from interactions of independent members of the team.

Another impediment could be wrong attitude coming from a team member who has agile-phobia. A person, who comes from a background that exercised thorough waterfall model for too long, shows resistance to accept agile. He tends not to accept the idea of “whole team” OR refuses to accept cross-functional work. Management control is exercised in giving him adequate agile-training.