Kickstart your career with best deals on top training courses NY10 Click to Copy

Search

Realizing You Are ‘WRONG’ In Agile: Relooking Agile Tenets

Solution development today involves a lot of trial and error. This results in teams doing multiple iterations in order to figure out the best possible way to make things work. But how do you determine whether you are doing the ‘right thing’? How do you ascertain whether you are going down the right path? More importantly, when do you establish that it is the right time to stop?Fail Fast, Learn FasterOne of the key principles in Agile is to ‘Fail fast & learn rapidly’. In simple terms, this means that teams should try things out, demonstrate to relevant stakeholders, get feedback and adopt the learning as early as possible. This is better identified as the ‘Plan-Execute-Inspect-Adapt’ cycle in Agile. Teams may end up doing this cycle for a particular feature or a task over and over again in an iterative manner. More often than not, this will make the solution stronger and seldom it will fail. But when do you call the feature ‘Done’?  Even so, are these stories ‘Really Done’?The definition of ‘Done’An important concept in Agile is what we call the ‘Definition of Done (DoD)’. In simple terms, it includes the circumstances under which we determine that a story or feature is completed. It helps teams determine when to move a feature card to the ‘done’ state in an information radiator.The definition of done is unique from project to project and from team to team. Before the start of the project, the team must sit together to determine the criteria that constitutes a definition of done. Below is an example of a well-crafted DoD.The feature must be elaborated and acceptance criteria defined with examplesThe solution / component must be designed, reviewed and agreed uponThe UI design is doneCode is developedCode reviews are done and passedUnit tests are done and passedQA testing is done and passedFeature is integrated into the main solutionIntegration testing is done and passedWe normally move the story to ‘Done’ state if all criteria are met. However, more often than not the feature requires changes or revisiting in the future. This may result in a new story being created in the backlog to do the necessary changes. So in reality, the story is not ‘done-done’.Achieving the done-done stateDoes the ‘done-done’ state really exist? Yes, it can happen. When the story doesn’t require any more changes and never crops up in the future then it really is ‘done-done’. The team may be required to do multiple iterations to get the solution to such a state.Obviously, this process involves a cost. Cost to the sponsor in terms of resources (human and non-human) consumed, opportunity cost and the cost of waste in the form of mistakes, defects, and throwaways.                                                                   “That which does not kill us, makes us stronger”                                                                        Friedrich Nietzsche (German Philosopher)So how long should you continue? This is like a situation where a rock climber tries to climb a perpendicular mountain. The climber will use his hands & legs, his climbing gear, and his willpower to propel him forward step by step. He will lose his grip, slip and lose ground multiple times. But he will get up and keep on climbing till he reaches the summit. But if it becomes too dangerous and if the risk is not worth it, he will bail out and stop climbing.Know when to bail outIt is important for Agile teams to know when to quit. In Agile terms, we call it ‘Pivoting’. To pivot is to understand that you are doing something wrong, quit iterating and move on with another feature. There are multiple reasons as to when you may decide to pivot.Read this article for examples of pivoting.https://techcrunch.com/sponsored/pivoting-to-success-agile-founders-who-turned-their-companies-on-a-dime/Agile teams are most probably ‘wrong’ when,The cost to implement the feature or to move it to ‘done’ state increases exponentiallyThe opportunity cost of foregoing other tasks, features or even projects is extremely largeThe ROI gets diminished fastThe end is not in sight – You keep on iterating and doing improvements but what you are doing is so uncertain and ambiguous that you are unable to see the finishing lineThe ‘done-done’ state never materializesAbove are just some reasons as to realize that you are most probably doing something wrong. Act fast to identify this and quit what you are doing. It may really be pointless for you to keep on iterating and more beneficial for you to invest your time and energy on something else.So, act wise!! Fail fast, learn fast and most importantly pivot faster!!
Rated 3.5/5 based on 1 customer reviews

Realizing You Are ‘WRONG’ In Agile: Relooking Agile Tenets

186
Realizing You Are ‘WRONG’ In Agile: Relooking Agile Tenets

Solution development today involves a lot of trial and error. This results in teams doing multiple iterations in order to figure out the best possible way to make things work. But how do you determine whether you are doing the ‘right thing’? How do you ascertain whether you are going down the right path? More importantly, when do you establish that it is the right time to stop?

Fail Fast, Learn Faster
key principles in AgileOne of the key principles in Agile is to ‘Fail fast & learn rapidly’. In simple terms, this means that teams should try things out, demonstrate to relevant stakeholders, get feedback and adopt the learning as early as possible. This is better identified as the ‘Plan-Execute-Inspect-Adapt’ cycle in Agile. Teams may end up doing this cycle for a particular feature or a task over and over again in an iterative manner. More often than not, this will make the solution stronger and seldom it will fail. But when do you call the feature ‘Done’?  Even so, are these stories ‘Really Done’?

The definition of ‘Done’
An important concept in Agile is what we call the ‘Definition of Done (DoD)’. In simple terms, it includes the circumstances under which we determine that a story or feature is completed. It helps teams determine when to move a feature card to the ‘done’ state in an information radiator.

The definition of done is unique from project to project and from team to team. Before the start of the project, the team must sit together to determine the criteria that constitutes a definition of done. Below is an example of a well-crafted DoD.
Definition of Done path

  • The feature must be elaborated and acceptance criteria defined with examples
  • The solution / component must be designed, reviewed and agreed upon
  • The UI design is done
  • Code is developed
  • Code reviews are done and passed
  • Unit tests are done and passed
  • QA testing is done and passed
  • Feature is integrated into the main solution
  • Integration testing is done and passed

We normally move the story to ‘Done’ state if all criteria are met. However, more often than not the feature requires changes or revisiting in the future. This may result in a new story being created in the backlog to do the necessary changes. So in reality, the story is not ‘done-done’.

Achieving the done-done state
Does the ‘done-done’ state really exist? Yes, it can happen. When the story doesn’t require any more changes and never crops up in the future then it really is ‘done-done’. The team may be required to do multiple iterations to get the solution to such a state.

Obviously, this process involves a cost. Cost to the sponsor in terms of resources (human and non-human) consumed, opportunity cost and the cost of waste in the form of mistakes, defects, and throwaways.

                                                                   “That which does not kill us, makes us stronger”
                                                                        Friedrich Nietzsche (German Philosopher)

So how long should you continue? This is like a situation where a rock climber tries to climb a perpendicular mountain. The climber will use his hands & legs, his climbing gear, and his willpower to propel him forward step by step. He will lose his grip, slip and lose ground multiple times. But he will get up and keep on climbing till he reaches the summit. But if it becomes too dangerous and if the risk is not worth it, he will bail out and stop climbing.

Know when to bail out

It is important for Agile teams to know when to quit. In Agile terms, we call it ‘Pivoting’. To pivot is to understand that you are doing something wrong, quit iterating and move on with another feature. There are multiple reasons as to when you may decide to pivot.

Read this article for examples of pivoting.

https://techcrunch.com/sponsored/pivoting-to-success-agile-founders-who-turned-their-companies-on-a-dime/

Agile teams are most probably ‘wrong’ when,

  • The cost to implement the feature or to move it to ‘done’ state increases exponentially
  • The opportunity cost of foregoing other tasks, features or even projects is extremely large
  • The ROI gets diminished fast
  • The end is not in sight – You keep on iterating and doing improvements but what you are doing is so uncertain and ambiguous that you are unable to see the finishing line
  • The ‘done-done’ state never materializes

Signs you are doing agile WRONG

Above are just some reasons as to realize that you are most probably doing something wrong. Act fast to identify this and quit what you are doing. It may really be pointless for you to keep on iterating and more beneficial for you to invest your time and energy on something else.

So, act wise!! Fail fast, learn fast and most importantly pivot faster!!

Rumesh

Rumesh Wijetunge

Chief Innovation Officer - Zaizi Limited, Chief Operating Officer - LearntIn (Pvt) Ltd., Director /

Rumesh is an IT business leader with over 12 years of industry experience as a business analyst and project manager. He is currently the CIO of Zaizi Limited, a UK based data management company heading the operations in Sri Lanka, the COO of LearntIn, a global training institute based in Sri Lanka and is also a lecturer / trainer at multiple private universities on management, IT, business analysis and project management subjects. He is the current president of the IIBA Sri Lanka chapter and is one of the most qualified and sought after trainers in Sri Lanka. Refer his LinkedIn profile for more details and to see more articles he has written on linkedin

Join the Discussion

Your email address will not be published. Required fields are marked *

1 comments

Francesca Godfrey 04 Jul 2018

Very Good Work

Suggested Blogs

Project Manager Vs Product Owner

Traditional waterfall projects had the Project Manager unquestionably at the helm of the ship. Today, as more companies migrate toward agile, the role of the Project Manager has become redundant. Agile advocates team work — wherein there are self- organizing teams, and much of the responsibility that was earlier shouldered by the Project Manager is shared by the group. In an agile environment, the Product Owner owns the product, the Scrum Master owns the process and the team works together toward fulfilling the tasks. In a traditional project, the Project Manager holds all the cards and owns the entire project. Today, Project Managers need to redefine their responsibilities in the agile context, and depending on their inclination frequently take on the mantle of the Product Owner or ScrumMaster. There has been much heated debate on this topic in many online Scrum forums, with differing results … but research shows that there is no definitive answer that squarely references the PM to the PO. While Scrum rejects the role of a Project Manager per se, there are many who believe that this role has been reframed to include the two roles of a Product Owner and a ScrumMaster. The ScrumMaster is by definition a servant leader. The Product Owner, by definition, is the person who represents the business stakeholders and keeps the team focussed on the product itself. As a Product Owner, his or her job is to tell the team what to do…but not how to do it. The ‘how’ is decided by the team members themselves. And that, in a large part, sums up the difference between a Project Manager — who needed to spell out the Hows, Whats and Whys — and the Product Owner, for whom only the definition of the problem…or the What… is all-important. In Scrum, there is no single management position. And that’s where the beauty of Scrum, and perhaps its efficacy, lies. Scrum teams are self-managing, and when each member of a Scrum takes on some responsibility, the project has a much higher chance of success.
Rated 4.0/5 based on 20 customer reviews
Project Manager Vs Product Owner

Traditional waterfall projects had the Project Man... Read More

INFOGRAPHIC: Agile And Management Learning Path For Your Next Career Move

Agile has become the most important methodology for companies searching for an incremental way to deal with project management and software development. And, this has enhanced the demand for IT professionals who have a sound knowledge of the methodology and its implementation. There are different certifications available to test the knowledge and competency of the IT professionals on Agile frameworks. Here, KnowledgeHut provides you the ‘Agile and Management certification roadmap’ that will help take your career to the next level.Be familiar with all the Agile and Project Management certifications offered by different accreditation bodies that are categorized based on the courses offered and make a wise career move.Scrum AllianceKnowledgeHut is a Global Registered Education Provider (REP) of Scrum Alliance which offers certifications in Scrum, a leading Agile framework.Introductory- Foundation and Practitioner coursesCertified ScrumMaster®(CSM)This CSM course provides effective knowledge on Scrum basics and its implementation in the real world.Certified Scrum Product Owner®(CSPO)Agile professionals who are close to the business end of projects will benefit from this CSPO course.Certified Scrum Developer® (CSD)Developers and programmers who have work experience in an Agile environment will benefit from this CSD course. Training is provided through two different paths such as for:CSM Holders- 3-Day Agile Engineering Practices CourseNon-CSM Holders- 1-day CSD into course, 3-Day CSD Agile Engineering Practices Course and 1-day CSD technical elective course.Once you obtained the initial certification for your chosen track, you can start with the Advanced level certification which is the next stage of the pathway to CSP.Advanced- Individuals with foundation-level certification can enter this phaseAdvanced Certified ScrumMaster™ (A-CSM™)The A-CSM course targets individuals who already have experience with Scrum and the ScrumMaster role and existing CSMs.Advanced Certified Scrum Product Owner™ (A-CSPO™)This A-CSPO course targets individuals who already have experience with Scrum and the Product Owner role and existing CSPOs.After successful completion of Advanced level learning, candidates will be eligible to take the CSP certification of their chosen pathway. On successful completion of your chosen path to CSP, you can continue with the certifications such as CST (Certified Scrum Trainer), CTC (Certified Team Coach), CEC (Certified Enterprise Coaches℠), along with Certified Agile Leadership.Scrum.OrgKnowledgeHut is a Professional Training Network member of Scrum.org which offers certifications in Scrum, a leading Agile framework. It is recommended for every individual to pass the specific introductory course first, before going to the next levelProfessional Scrum Developer™The PSD certification is available for everyone who wants to prove their knowledge in building the complex software products with the help of Scrum.Professional Scrum Foundations™ (PSF)This PSF course targets freshers and individuals who want to revise Scrum basics.Professional Scrum Master™ (PSM)This course is aimed at Scrum Masters, Managers, and Scrum Team members who are responsible for getting the most out of Scrum. Three levels of certifications are available in PSM training:PSM I- IntroductoryPSM I certification holders will have a strong knowledge of the fundamental aspects, roles, and attributes of Scrum.PSM II- BeginnerPSM II certification holders understand the principles and processes of the Scrum framework and can effectively implement it in the enterprise context.PSM III- AdvancedPSM III certification holders demonstrate a distinguished level of mastery over Scrum.Professional Scrum Product Owner™(PSPO)This course is aimed at experienced Product Owners and Product Managers who want to improve their business success with Agile practices. Two levels of certifications are available in PSM training:PSPO I- Introductory to Intermediate levelPSPO I reflects an intermediate understanding of ScrumPSPO II- AdvancedPSPO II reflects an advanced learning of ScrumAfter successful completion of Advanced level learning of your chosen path, you can continue with the professional certifications such as PST (Professional Scrum Trainer™), PSPO Certified Trainer and the independent certifications such as Professional Agile Leadership™ (PAL), and SPS (Scaled Professional Scrum™) can be taken without any other Scrum.org credential as a prerequisite.Project Management Institute(PMI)Earning PMI® certifications will help you gain visibility within your organization and may expand your earning potential, enhance your job stability, and provide a competitive stand in the job market. KnowledgeHut is a Global REP for Project Management Institute, Inc. Here, we shall look at different PMI certifications available.Introductory- Beginning stage of an individual's journeyProject Management Professional (PMP®)This PMP course covers overall Project Management concepts and is the most important industry-recognized certification for project managers.PMI Agile Certified Practitioner (PMI-ACP®)The PMI-ACP® certification is designed for those willing to implement Agile practices in their projects.Advanced- Individuals with beginner level certification can enter this phaseProgram Management Professional (PgMP®)This PgMP® course is designed for those who handle complex and multiple related projects to achieve strategic and organizational results.Portfolio Management Professional (PfMP®)This PfMP course is designed for experienced project and program managers who want to enhance their ability to support and manage their enterprise project portfolio.Individuals can opt for Certified Associate Project Management (CAPM)® and PMI Professional in Business Analysis (PMI-PBA)® certification courses without any other PMI credential as a prerequisite.Scaled Agile AcademyKnowledgeHut offers different SAFe certifications from Scaled Agile Academy that are designed to help larger organizations struggling with Agile implementation for larger development efforts. Here we categorized the Scaled Agile Framework certifications based on different roles that can help you choose your career path.Agile Change Agents ConsultantsSAFe® 4 Program Consultant (SPC)SPC certification demonstrates your ability to deploy SAFe framework in the context of an enterprise-wide Agile transformation.Executives, Managers, StakeholdersSAFe® 4 Agilist (SA)The Leading SAFe® SA certification training will train the attendees on the skills required to lead an enterprise Agile transformation by leveraging the SAFe®, and its underlying principles derived from Agile development, Lean, systems thinking, product development flow, and DevOps.Release Train Engineers/Value Stream EngineersSAFe® 4.5 Release Train Engineer (SAFe® RTE)From this course, individuals will explore the skills required to drive end-to-end delivery of value through ARTs (Agile Release Trains) and also learn to build a high-performing ART through coaching and servant leadership by becoming a SAFe® RTE.Product Managers/Product OwnersSAFe® Product Owner/Product Manager (SAFe® PO/PM)Attendees will gain the skills required to guide the delivery of value in a Lean enterprise and learn about the tools, mechanics, and activities used to manage programs and backlogs.Scrum MastersSAFe® Scrum Master (SSM)- IntroductoryAttendees (Scrum Masters) will gain an understanding of the Scrum Master role as a part of the entire organization.SAFe® Advanced Scrum Master (SASM)- AdvancedCurrent Scrum Masters will gain the skills needed to implement Scaled Agile Framework and lead high-performing Agile teams.Agile TeamsSAFe® for TeamsIndividuals will gain an in-depth understanding of the Agile Release Train, how it delivers value, and what they can do to perform their role effectively using Scrum, XP, and Kanban.ICAgileICAgile-accredited courses help organizations and professionals in developing an Agile mindset and enabling sustainable organizational agility. Here we shall look at the learning roadmap of different ICAgile courses.Roadmap to ICAgile Certified Expert in Agile Testing (ICE-AT)Agile Testing- IntroductoryThis certification aims at Agile testers or aspiring Agile testers who wish to learn and practice Agile testing techniques. Even Test Managers, Testers, Developers, and Analysts with a passion for testing will benefit from this course.Agile Test Automation- AdvancedThis certification aims at Test engineers, Agile testers, or aspiring Agile testers with a desire to learn and practice Agile test automation. Test Managers and developers with a passion for learning automation skills will also benefit from this course.ICAgile Certified Expert Agile Testing- Expert/ProfessionalTo acquire the ICAgile Certified Expert in Agile Testing (ICE-AT), an applicant must show competency in the discipline of test automation and Agile testing to a review committee of three industry-recognized experts. The applicant will be assessed through an interactive virtual session with the review committee.Roadmap to ICAgile Certified Expert in Agile Coaching (ICE-AC)Agile Team Facilitation- IntroductoryThis certification is designed for Agile team leaders or aspiring team leaders who are passionate about servant leadership and have a desire to learn and practice the art of facilitation as part of coaching and team facilitation.Agile Coaching- AdvancedThis certification is designed for Agile coaches or aspiring coaches who are passionate about servant leadership and have a desire to learn and practice coaching, teaching, facilitation and mentoring in service of Agile teams.ICAgile Certified Expert In Agile Coaching- Expert/ProfessionalTo acquire the ICAgile Certified Expert in Agile Coaching (ICE-AC), an applicant must show competency in the discipline of Agile coaching to a review committee of three industry-recognized experts. The applicant will be assessed through an interactive virtual session with the review committee.Roadmap to ICAgile Certified Expert In DevOps (ICE-DO)Foundation of DevOpsDevelopers, Operations leads and team members, Agile Coaches, Managers, or anyone with a passion for DevOps will benefit from this certification.Implementing DevOpsDevelopers, Operations leads/team members, testers, security leads/team members, technical coaches, and technical leads, or anyone interested in the hands-on implementation of DevOps will benefit from this certification.ICAgile Certified Expert In DevOpsThe ICE-DO certification is still in development. So, it is recommended to obtain the above two certifications first before preparing for this certification.Winding UpDeciding to start a career in an Agile environment in the IT industry is an exceptionally good choice. Getting an Agile certification can help you get started and get ahead in your career. Remember, certifications show your ability to your managers, co-workers and future employers. Getting certified is a great way to differentiate yourself from your peers.Choose wisely! And all the best on your certification learning path!!
Rated 4.0/5 based on 1 customer reviews
INFOGRAPHIC: Agile And Management Learning Path Fo...

Agile has become the most important methodology fo... Read More

Adopt TDD for a smooth Scrum experience for your teams

As you might already be aware, TDD stands for Test Driven Development. Adoption of TDD is a key factor for the success of your Scrum teams and in turn for your success as a Scrum Master. I will explain the why and how of TDD and how it helps smoothen Scrum experience in this article. As you might be already doing, with Scrum approach, there are no grandiose design sessions/detailed designs done up-front but the focus is getting working pieces of code out and fail fast if there are any issues. The key reason being – designs change as you progress with the development of code and your code should be flexible enough to absorb major or minor changes until towards end of the development. If complete designs are done up-front to the detailed level, code is written assuming the designs are concrete and becomes rigid. This type of code can’t accept changes easily and as every developer is aware, changes to requirements are very common during implementation cycle.  A framework that can help the Scrum teams accept the changes easily, make the changes and quickly assess the effects of these changes can help alleviate these issues. Once the impacts are clear, it doesn’t take too long to get the implementation back to stable state. TDD provides one such framework for Agile development.  TDD (Test Driven Development) Following is the broad outline of adopting TDD during development. I will take developing APIs for a product as an example, which can be easily extended to other use cases. Do a high-level design of the components and APIs you are going to have. Prepare the interfaces against which you can write tests. Adopt a framework like JUnits for writing your test cases. Get the developers up-to-speed on writing these unit tests. For whatever components you are developing APIs, create a skeleton of tests and test cases. Normally, you would write a set of positive and negative test cases. This is the first step even before you write a single piece of implantation code. Make sure majority of the unit test cases are covered in this round of skeletal test cases. Implement the APIs with no code, i.e. now they can be called but will not yet return proper values. For example, they may return nulls where an object is expected. Since implementation of APIs is not yet ready, all of your tests will fail. That’s ok to start with. Now as development of APIs progresses, test cases will start to succeed. At the end of, say, sprint #1, you may have 20% of your test cases working. In parallel, add more or update your test cases to handle more complex usages of the APIs. The goal is to get 100% success rate of test cases, which should happen as the development is completed and more code is added. For example, this is how your tests may look to begin with:     @Test     public void testSingleObjectCreate() throws Exception     {       Object a = createObject(...);         Assert.assertNotNull(a);     }     @Test     public void testMultipleObjectsCreate() throws Exception     {       Object [] objs = createObjects(...);         Assert.assertNotNull(objs);     }     @Test     public void testSingleObjectReplace() throws Exception     {       Object replacedA = replaceObject(a);         Assert.assertNotNull(replacedA);     }     @Test     public void testMultipleObjectsReplace() throws Exception     {       Object[] updatedObjs = replaceObject(objs);         Assert.assertNotNull(updatedObjs);     }          @Test     public void testSingleObjectDelete() throws Exception     {       boolean deleted = deleteObject(a);         Assert.assertTrue(deleted);     }     Note that all of these tests will fail to begin since APIs are not yet implemented. Your goal is to get all of the tests passing incrementally, by implementing the underlying functionality. Once this set of test suites are built, they can become part of a continuous integration setup and are run as soon as changes are submitted to the source code system, giving an immediate feedback on whether there are test cases failing because of new code that is delivered. Following diagram summarizes this approach:   How does this help your Scrum team? TDD can augment Scrum processes in 3 ways: Ability to absorb changes to code on a continuous basis. Fail fast: Failures happen sooner than later. Reduce technical debt Let me cover details of each of these points. Ability to absorb changes to code on a continuous basis: As a Scrum Master, your job is to make sure that the working code gets produced at the end of each sprint and minimize the technical debt for going forward. At the same time, you want the code to be flexible so that changes can be accepted on a continual basis to improve the existing code or be able to absorb new changes, based on product owner or stakeholder feedback. This is especially important since you don’t get into detailed designs up-front and absorb changes as you progress to make implementation better. Having the suite of unit tests is one of your weapons in the war chest to make this happen – after all, code which is delivered at the end of release but doesn’t address the key requirements is of not of much use. Take this case – in the midst of development, one of the developers changes the inner workings of one of the APIs and now it fails for a given set of inputs (which used to work before the change). Now your unit test which depended on the success status of API starts to fail, giving you an immediate indication of the change. However, developer can take the risk of the change, knowing that the test framework will catch any side effects of such a change. As a second case, say half-way through the development cycle, there is a need for major change that impacts majority of the components. Unless you have a suite of test cases backing you, you just don’t know the impact and how much additional work is possibly required. (Knowing your developers, you know how hard it is to get a proper estimate of additional work!). Instead, now you can depend on your test suites and see how many are failing when the changes are put in place – if there are a large set of test cases failing, you are most likely looking at a larger impact change to the whole sprint and need to re-access the scope and priorities. Additionally, it makes everybody in the team aware of the impacts.  Fail fast - Failures happen sooner than later: Adopting TDD facilitates one of the key principles of Scrum – fail fast. With TDD, you start with failing tests, make them work as you progress and make sure they won’t fail again due to some unexpected changes. If there are such failures, your TDD set of tests alert you immediately. Knowing there is such a framework, developers will be more open to changes – since failures are caught immediately. Overall, this becomes a mechanism which gives a quick feedback on the impacts of a change and makes developers open for adopting the changes rather than shying away from taking the risk of late changes to the system. Reduce creation of Technical Debt: If developers can’t absorb changes fast enough, you will run out of time during sprint to do further changes. Pushing required changes out of sprint and eventually out of a release leads to the technical debt of future changes and re-work, which is not a desired outcome for any Scrum Master. Having a framework to facilitate quick changes avoids creation of technical debt. Key is to start with TDD from day one One of the key factors is to start with TDD from day 1 – it must not be an afterthought to be added after the code implementation. For any new code, tests should be written first, let them fail and implement code to make the tests work. For a Scrum Master, it is a key that developers are creating tasks to add unit tests for a given user story and have mechanisms in-place to continuously validate the code using build frameworks. Combining TDD with Code coverage can be very powerful TDD approach when used along with code coverage tools provides a very powerful combination to make sure your code base is stable all the time and all parts of the code are being tested. Greater the code coverage, better confidence you have to do drastic changes to your implementation code. For example, the following screenshot of code coverage shows which parts of the code are being exercised (green) versus which are not (in red). More unit tests need to get added to provide coverage for the code paths not being tested. Adopting TDD for existing products TDD can be adopted for existing product code as well, which lacks unit test coverage. It is not usually productive to add tests for existing code unless major changes are planned. Tests can be added to the incremental functionality that is being added, being aware that you may impact the existing code and may not know if you have caused failures in the already existing code. TDD Tools There are several tools that are available in the market, which help in TDD adoption. For unit testing of Java code, JUnit framework is the best choice. For continuous build and test, frameworks like Cruise Control or tools like Jenkins can be used. Code Coverage can be analyzed using tools like Emma and Clover. These have Eclipse plugins available as well. In conclusion, adopting TDD goes a long way in ensuring code quality is maintained in the long run and changes can be done to the codebase ensuring continuously working software. This essentially gives control for your Scrum teams to manage the software better and address the end user needs quickly.
Rated 4.0/5 based on 20 customer reviews
Adopt TDD for a smooth Scrum experience for your t...

As you might already be aware, TDD stands for Test... Read More

other Blogs