Behavior Driven Development (BDD) Training in Bangalore

This program introduces Behavior Driven Development (BDD) to the audience and follows a life cycle approach where audience get to learn how to practice BDD in real life projects using some the best BDD tools like Cucumber, Jbehave and Specflow. Good Test First practices can reduce defects drastically, promote better design, make the code easier to understand, to change and cheaper to maintain. This workshop will give your team a solid grounding in practical BDD/ATDD, no matter what language they use or what background they come from. Participants will learn how to write high-quality unit tests, or more precisely, "executable specifications", to write better designed, more maintainable and more reliable code.

In this 2-day intensive course, Participants will also discover how BDD helps keep development focused on the real requirements, resulting in a higher quality product for the end user. Return on investment is immediate - these are skills that every developer needs to master.

This workshop teaches the principles of Test First and BDD, which are applicable in any modern programming environment. We discuss ATDD/BDD tools for Java, .NET and participants should bring their own laptop to practice same.

Contact me on +91 9810547500 or naveenhome@gmail.com for any agile and scrum training including Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO), Certified Scrum Developer (CSD), BDD, TDD, CSP or clean code etc.

Not much difference between Scrum and LeSS

There is hardly any difference between Scrum and LeSS as long as number of team is less than 8 and not moving to LeSS Huge. Since there is not much noticeable difference and if you don't tell team about LeSS, team will not even notice that they are adopting Large-Scale Scrum (LeSS). Though better is to conduct workshops to ensure team know about objective behind LeSS and challenges is adoption. Though there is hardly any difference in structure but still LeSS adoption takes time and required lots of effort and energy. LeSS is too simple and usually simple framework become more challenging than complex framework.

Learnt the areas where LeSS adoption takes more time while working as coach with one the biggest recruitment firm having offices across globe. I am working with one product team as of now and there are 3 more products. Highlighting some of the areas where adoption takes more time.

Definition of Product - Team of more than 40 people working on different component, enhancement, production support, testing and requirement management etc. These team has also named their team based on component that they are developing. These teams are having dependencies to each other and can't move their work in production until every team is not ready with their work. They are also having multiple product owner and separate product backlog. Defining product and aligning every team with single product is challenging work. Although senior management understood what I am trying and got full cooperation but still its taking time.

Single product but multiple product owner - This is because product definition was missing. This issue was identified earlier and management was working even before I joined them. Now There is only one product owner and product owner focus more on prioritization rather than clarification. Some challenges are still there and we are working on.

Component team to Feature team -  This is the toughest part. Change in culture, mindset, attitude everything needed but still if team is practicing scrum and already self-managed and self-governed then it will be easy. But truth is littler bitter because there is hardly any true self-managed and self-directed, cross-functional team and same here as well. Tester not part of development team because they don't have full-time work, middle layer service integration team is not part of development team, database and configuration management people out of team so essentially only software developers are there that too component-wise. Working with team and designing cross-functional team is going on and hoping to have little matured team in next 4-5 sprints. If this happen then will start working with 2nd product team.

Above all applicable to the organization already practicing Scrum for last 2 years and team understand concept of single scrum team.

     

    

Software Development - Metrics vs Practice

Every organization looking for more and more metrics and especially wherever I go as agile coach and consultant to talk about agile adoption or improving software engineering practices. Many time management fails to explain objective behind so many metrics. While talking to management, what I have felt that these metrics sometime initiate violent communication in team that leads to lack of trust. Organization should focus more and more on building practices and better innovative processes that will automatically help in meeting objective. Metrics needed for sure because it helps organization in deciding future course of action but metrics without practice will demotivate team that result in poor product quality. 

Some of the basic example:-

80% code coverage - What is the reason for this metrics? This is to judge individual performance or ensure code is maintainable? If objective is NOT well communicated to team and practices for clean code is not established then what team member will do? Team may end up meeting 80% code coverage by any mean to satisfy metrics but what about objective?

Similarly there are many other metrics like "defect ratio", "defect per feature", "Code complexity", "team velocity", "estimation accuracy" etc. These can be easily manipulated if team doesn’t know objective behind these metrics. There has to be a process for defining metrics and every metrics must have clear objective. Before measuring ensure there is a practice setup and practice and metric both are aligned to single objective.

Measure outcome not output.

Reach to me on naveenhome@gmail.com or +91 9810547500 for corporate training.

We deliver training on Test Driven Development (TDD), Behavior Driven Development (BDD), Cucumber, Selenium, Jira Agile, Scrum, Jenkins, Scrum Master, Scrum Developer, Product owner, agile estimation and planning, writing user stories etc.

Roles and Responsibilities during Scrum Ceremonies

Ceremonies	Scrum Master	Product Owner	Development Team
Release Planning	Make sure Release plan ends with List of PBI, number of sprints.	Why we do this release, stakeholders expectation on this release, timeline, PBIs for the release.	Provides team velocity to consider while release planning
Product Backlog Refinement	Confirm all questions of Dev team are cleared by Product Owner PBI are enough for next 2 sprint as per team velocity	Introduces the PBI and explain Definition of Done, any specific Voice of Customer related to the PBI, rank of the PBI, Clear all doubts, manages PBI splits.	Understand PBI and Definition of done and ask as much question to Product Owner to establish acceptance criteria and uncover potential technical challenges.
Sprint Planning	Make sure Sprint plan ends on time. Post a poster on burndown chart for team update. Quote Team capacity, indicate velocity.	Make sure the PBIs taken by Dev team are in line with produce release plan; Understands and decide on dependent PBIs, Conclude Sprint Goal.	Confirms the team planned capacity.  Indicate technical dependencies, Issues in Definition of Done, choose PBIs for the sprint, manage themselves on list of task and confirms task are leading to sprint goal.  Commit on the PBI.
Daily Scrum	Update chart, List down Impediments. Before Review: Remind Review preparedness to Dev Team.	Monitor scope. Help team to get further clarity on PBI	Update the progress to team. Plan for today and highlight impediments
Sprint Review	Send invite to all stake holders in advance.	Accept or reject sprint outcome	Show outcome of latest sprint and answer questions to the Stakeholders.
Sprint Retrospection	Read feedback, impediments faced, Action & results observations, Share Product Owner feedback, how much Scrum followed, Read improvements planned and actual from last Retrospection.	Not required but can join if team looking for help.	Open discussion towards improving the efficiency of the team; identify key problems faced, review last improvement action & Result.  Append new actions.

How CSD can help in getting CSP credential faster?

How CSD can help in getting CSP credential faster?

If you are CSM/CSPO then you are already eligible for 16 and attending 3 days CSD engineering training will give additional 24 SEUs so total category “B” SEUs is 40 and remaining 30 can be easily earn either through category C, D, E of F. Like if you attend 2 days PMI-ACP training then you will get additional 15 SEUs. 15 SEUs can be claim through reading 1 or 2 Agile and Scrum books. 

If you are not CSM/CSPO but having 36 months of working experience in agile/scrum environment then attending CSD will give you 40 SEUs. You can attend additional 2 days training on Scrum/Agile related topics provided by REP like Leanpitch to get 16 SEUs so total category “B” SEUs will be 56 and remaining can be easily earn either through category C, D, E of F. Like if you attend 2 days PMI-ACP training then you will get additional 15 SEUs and 15 SEUs can be claim through attending User Group's event. Play Scrum and Agile Software Developers Network keeps organizing such events every month.

Certified Scrum Developer (CSD) Training is available in Bangalore, Chennai, Pune, Hyderabad and Delhi.

Reach to me on naveenhome@gmail.com or +91 9810547500 for corporate training.

We deliver training on Test Driven Development (TDD), Behavior Driven Development (BDD), Cucumber, Selenium, Jira Agile, Scrum, Jenkins, Scrum Master, Scrum Developer, Product owner, agile estimation and planning, writing user stories etc.

How to earn 70 SEUs for CSP

How to earn 70 SEUs for CSP

Scrum alliance has 6 different categories through which you can earn SEUs and these categories also have some limitation.

Category “A”/Scrum Alliance Scrum Gathering – You can earn maximum 45 SEUs in this category. One SEU per hour of participation in scrum alliance global, regional or user group scrum gatherings as well as Scrum alliance affiliated user group.

You can earn these SEUs either through presenting, coaching and attending sessions. For example you can earn SEUs through attending Regional Scrum Gathering India event or event through user group like Play Scrum and Agile Software Developers Network.  

Scrum Alliance Guideline - 
Attended Global Scrum Alliance Gathering
Attended Regional Scrum Alliance Gathering
Attended Scrum Alliance User Group Activity
Attended Scrum Alliance-Sponsored Event
Attended Scrum Coaching Retreat 
Attended Scrum Coaching Retreat Pre-Workshop

Category “B”/Scrum Alliance Course – There is no limit for this category. CSM and CSPO certification is eligible for 16 SEUs, CSD is eligible for 24 SEUs. You can also earn through attending training course provided by REP or CST. Training by Scrum Alliance CST and REP must follow below guidelines.

If you are CSM or CSPO then attend 3 days CSD engineering training to get additional 24 SEUs. You not only get 24 additional SEUs but also additional certificate - CSD. 

You can also earn additional SEUs through attending various training deliver by CST and REP like Leanpitch. These training includes TDD, BDD, Writing USer Stories, Scaling Scrum and Continuous Integration.

Scrum Alliance Guideline - 

Received CSM Training

Received CSPO Training

Received CSD Training

Received Training from a CST (including video training)

Received Training from a REP (only approved courses and trainers)

Received Coaching by a CSC

Category “C”/Outside Events – Up to 15 SEUs in this category through attending Scrum conferences like AgileNCR or training on agile topics provided by someone who is not a REP or CST. Attending 2 days PMI-ACP training will help you in getting 15 SEUs.

Category “D”/Volunteer Service - Up to 15 SEUs may be earned by providing non-compensated, Scrum professional services to an organization or group other than your employer. You can earn these SEUs even through helping REP or CST in organizing and delivering seminars.

Category “E”/Asynchronous Learning – Up to 15 SEUs may be earned through various independent learning activities, such as preparing presentations, authoring relevant books or reading some books deeply and then describe benefits.

Category “F”/ Synchronous Learning – Up to 15 SEUs may be earned through a variety of other learning activities that doesn't fit in above category like working as co-trainer with more experience trainer.

How to earn SEU for CSP. How to become CSP.

Reach to me on naveenhome@gmail.com or +91 9810547500 for corporate training.

We deliver training on Test Driven Development (TDD), Behavior Driven Development (BDD), Cucumber, Selenium, Jira Agile, Scrum, Jenkins, Scrum Master, Scrum Developer, Product owner, agile estimation and planning, writing user stories et

Agile engineering is not just important but essential for higher ROI

Agile has become popular within software industries not only in product development organizations but also within software service organizations. There are many factors that driving this change including time to market, continuous change in requirement, increase productivity and better accountability etc. 

Agile get defined by Agile Manifesto and Agile Manifesto consists four values and twelve principles. It is easy to remember four values but not always easy to implement all principles because it's required engineering practices in place to implement. This is one the reason for higher demand for agile engineering coaches to provide supports to adopt these technical practices like TDD, BDD, ATDD, CI/CD, DevOps and Agile Architecture & Design etc. Nowadays all leading scrum certification authorities is promoting these practices through their certifications program like CSD (certified Scrum Developer) and PSD (Professional Scrum Developer).

Below is mapping of engineering practices against some of the agile principles to visualize how these become important.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Delivering product frequently with new features looks easy during initial stage and also when team is small but issues start appearing after few deliveries or when new team get added to work on same product. These issues are mainly related to integration of code and ensuring newly added code has no impact on already released features. Opting for continuous integration practice and using tools like Jenkins, CruiseControl, Hudson, TFS etc can resolve these issues.

Business people and developers must work together daily throughout the project. Working together mean whole team available to each other and help each other whenever needed. But it would be good if business people write acceptance test cases in way that enable developers to write code. Automating acceptance criteria using any BDD/ATDD tools like cucumber, SpecFlow, Nbehave, Behat or Fitnesse will give confidence to business people because implementation of new stories can be verified immediately. 

Continuous attention to technical excellence and good design enhances agility. Agile architecture and design is a need of hour. Having big design up front (DBUF) is not good practice and team moving towards emergent design. Ideally the team that code the system also design the system and focus should be on build a design that can possibly work. If development team is also designing the software then team focus is not only meeting the requirement but also on how to enhance design. Following SOLID design principles and coding through TDD will help in technical excellence.

Simplicity–the art of maximizing the amount of work not done–is essential. Agile architecture and design also talks about YAGNI (You aren’t gonna need it) and KISS (Keep it simple, stupid) principles but having BDUF is violation of these principles. Purpose is simple, Code as much as needed to meet the requirement and nothing more. Test First approach helps in writing less code and only that much needed to pass test.

The best architectures, requirements, and designs emerge from self-organizing teams. The teams that code the system also design the system because team is empowered to define, develop and deliver software. Build the simplest architecture that can possibly work. If non-functional requirement and prototype of system is not sufficient to take design decision then better to code to understand potential impact of the design. TDD and Refactoring helps is producing better design because design get tested during coding.

Reach to me on naveenhome@gmail.com or +91 9810547500 for corporate training.

We deliver training on Test Driven Development (#TDD), Behavior Driven Development (#BDD), Cucumber, #Selenium, #JiraAgile, S#crum, #Jenkins, #ScrumMaster, #ScrumDeveloper, #ProductOwner, agile estimation and planning, writing user stories etc.