Dedicated Scrum Master or Full-time Scrum Master?

Scenario 1 - She is a full-time scrum master for a team and gives all her time to the team, and attends all scrum events.

Scenario 2 - A dedicated scrum master for a team, not full-time, may work as a developer.

Arguments in favor of full-time Scrum Master

• If not full-time, what will happen to impediments to those needing immediate attention?
• She has to attend all events to ensure people practice the proper scrum.

The argument in support of not having a full-time Scrum Master

• But most of the time, impediments are not impediments but intra-team dependencies that the team has to manage, not scrum master.
• Scrum master is not needed in all events, and she has to only ensure those are getting done by the team.

Done with Certified ScrumMaster (CSM) so what next? Agile Coach?

Nowadays everyone wanted to become agile coach after clearing Certified ScrumMaster (CSM). And why not there are already so many scrum masters and we have to stand out of the crowd. There is nothing wrong in this because we all have passion and desire to become something.

People consider CSP (certified scrum professional) as 1^st step in order to become agile coach. I don’t know how true is that but I know people start collecting SEUs. This SEUs business is not bad either especially for community building because many started coming to conferences and meetup to collect SEUs.

But there is some challenges? Nowadays companies are looking for specific kind of coach like Process Coach, Flow Coach, Scrum Coach, Kanban Coach, Technical Coach and Developer Coach etc. This is creating another level of confusion for people wanting to become coach. In fact I am waiting to see if someone post LeSS Coach so I can apply :) In fact training business flourish when market create confusion and now I can see many people wanted to attend Scrum Developer workshop in order to become technical coach or developer coach etc.

Don’t know where this industry is heading but so far everything looks lucrative. Also all certification bodies like scrum alliance keep launching new certifications to tap market opportunity like enterprise coach, team coach and now leadership program so be ready to spend more in order to be in race.

I still believe Scrum Master is true coach provide he or she is good facilitator and servant leader. If Scrum Master has exposure on technical practices such TDD, ATDD, CI and Pair Programming etc then nothing like it. But this is what I believe. 

Everyone is developer in development team and not just a coder, a tester etc. Are you kidding?

Scrum is very simple framework to develop complex software product in complex environment but hard to practice. But why? I am not going in details of why but wanted to highlight one problem about development team as per my understanding.

Development team means cross-functional and self-organizing team of developers. But who is developer? Isn’t it everyone who contribute to develop software? A coder, tester, dba, UI designer, content writer or business analyst? Now look at your team. Is it cross-functional? Yes you have because you have technician for all skills but are those technician developers? May not be. There are just a coder, a tester, a dba, a ui designer and waiting for their skill related task. They are not working as developers with goal to develop software but they are just doing their task as per their skills.

Some of the key things that will help you to understand about development team. Think about L&D organizing few training is going to announce it.

1st announcement “we are planning to have workshop for Scrum Developer so send your nomination”. You will find that only coder has subscribed for this workshop.

Another announcement “we are organizing Agile Testing workshop so send your nomination”. This time only tester will subscribe.

What reflect above? Team is still divided in coder and tester. Tester feels everything related to testing is their domain and similarly coders feel all coding work is part of their work.

But reality is tester has to write code in order to test production code and coder has to write test to perform unit and integration test of code.

Another way of looking at it.

During sprint planning team prepared sprint backlog. Below is sprint backlog and now what it reflects? There are tasks but those tasks are skills based and not component. Isn’t it bad way of creating task? No? Then look below situation.

Assume there are 2 people Alex (coder) and Martha (tester) working on these 3 stories.

Alex done with coding part of story 1 after 2 days and Martha has started testing so what Alex will do next?

Most likely Alex will start working on coding part of story 2. Is it good? Why can’t Alex picks up other work from same story? Or why Martha was waiting for Alex to complete coding in order to start testing? Why can’t she pair with Alex to test in parallel or at least started testing APIs?

Many people asked me what’s wrong if Alex start working on coding part of story 2. Let’s see below situation.

Alex completed coding of 1st story and started coding 2nd story. Martha still testing 1st story found a bug so what she has to do? She reached out to Alex and wanted to discuss about bug but Alex is busy and asked her to come later on.

What do you think Martha will do next? Most likely she will open a bug tracking tool and log newly found bug over there. Is it good? No but why Not? I will write about bug logging challenges sometime later on but let's focus on other aspect of it for now.

After a day Alex is done with coding of Story 2 and started looking into bugs those were logged by Martha. He identified route cause of a bug that requires to change some framework level code. But that will also impact 2nd Story code that he has just completed.

What Alex will do? It is good if he go change whatever needed in order to fix at route but it will generate rework and will delay delivery. Other option is shortcut to fix bug (patch work) that will not have much impact on Story 2 code.

Majority of the time coder choose 2^nd option because coders are very emotional about their code but result of shortcut will be “Technical Debt”.

What can be done in order to avoid such scenario? Yes. 1^st don’t break story like above but try to divide in component. Best is not to divide but still dividing then divide in component. Work in pairing. Team should focus on finishing one that already in progress rather than starting new story.

Something wrong with software engineer designation

Why we don't feel proud in saying "I am a software engineer"? We all want to move away from this designation as fast as possible but why or this is not true?

May be we don't get equal values what other stream engineers get like mechanical engineer, electrical engineer or automobile engineer?

I am saying based on my conversations with various people during my workshop. Since I facilitate Scrum Developer workshop so mainly developers (Software Engineers and QA Engineers) come to attend.  

1st conversation

Developers - I am a software developer with 5 years experience and looking for role of Tech Lead or Architect etc.

Me - But there is no such roles in Scrum and you will have tough time going forward if you opt for meaningless designation and roles.

Developers - That I have heard but I can't even get attention of my company as developer so what's the use of being called Software Developer.

2nd conversation

Tech Lead - I am planning to be Scrum Master and I am already leading a team of 6 developers. What do you suggest? Can I go for CSM workshop?

Me - If you are still technical and contributing as development team then why moving to Scrum Master role? How much you know about Scrum?

Tech Lead - I don't know about Scrum and that's the reason I am here but I don't want to become developer. Scrum Master sounds more commanding and anyway I should not looking backward because I was developer for 6 years before becoming Tech Lead this year. Now you are saying there is no role like Tech Lead in Scrum so better to try for Scrum Master than becoming developer again.

3rd conversation

Future Agile Coach - I saw your post about how to earn 70 SEUs and I am running short by 15 SEUs. Can you help my getting those and please don't suggest to attend Scrum Developer workshop. No offence because I am planning for Scrum Professional so there is no point to know what Developer do.

Me - Still thinking how to reply

We often see engineers from other stream carry engineer as title till retirement like Assistance Engineer, Executive Engineer or Chief Engineer whereas Software Engineers move to some confusing roles like Tech Lead, Project Lead, Sr. Project Lead and some time even "Senior Assistant Vice President".     

We should start respecting ourselves as Software Developer/Engineers rather than moving into a trap of rat race.

How to earn 70 SEUs for FREE to become CSP (Certified Scrum Professional) in shortest possible time

Here is details about free SEUs for CSP (Certified Scrum Professional)

Category ‘A’ – Category A has a maximum limit of 45 SEUs, you can earn these by attending Scrum Alliance events. These events can be Scrum Global Gathering, Regional Gathering, Scrum Alliance Sponsored event and User Group event.

Scrum Bangalore organize full day event in Bangalore every quarter and now have started in Gurgaon, Discuss Agile regularly organize meetup in all cities, PlayScrum also organize meetup in Pune, Chennai, Delhi and Bangalore.

Basically, if you plan well then you can earn 20-30 SEUs in 3 months easily. I believe that’s good enough for this category.

Category ‘B’ – You can earn unlimited SEUs in this Category. But those will be paid. In any case, you need at least on Certification from this category to apply for CSP. Certified Scrum Master (CSM) gives you 16 SEUs, Certified Scrum Product Owner (CSPO) gives you 16 as well and Certified Scrum Developer (CSD) gives you 40. Ideally if you complete all these 3 roles based certifications then you get 56 from this category itself and don’t need anything else. I strongly suggest everyone to attend all 3 workshops before becoming CSP. Because you are planning for next level so it does matter that you know every roles and respective responsibilities in details.

But I said free SEUs for CSP so assuming you will only have 16 SEUs from this category either for CSM/CSPO or CSD.   

Category ‘C’ – You can claim 15 SEUs under Category C by attending any agile/scrum program such as PMI-ACP, Kanban, SAFe Agilist, Advance Scrum Master, SAFe Scrum Master, DevOps, Test Driven Development, Behavior Driven Development, and Specification by Examples. Again these will not come for free. So look for either DevOps meetup in your city or meetup on product management or lean management. You should be able to earn 15 in 3 months easily. If need help then write to me.

Category ‘D’ – Through voluntary work you can earn 15 category ‘D’ SEUs. Help ME in organizing next meetup in your company and you can claim 15 for same. If that’s not possible then check with local user group community in your city and extend your help in spreading agile/scrum knowledge by working with community leader and you can claim 15 in next 3 months.

Category ‘E’ – Read 3 books (my favorites) 1^st – 5 dysfunctions of team, 2^nd – The Phoenix Project and 3^rd Scrum – A Pocket Guide and claim 15 SEUs for free in this category.

Category ‘F’ – Up to 15 SEUs may be earned through a variety of other collaborative learning activities engaged in with other Scrum practitioners. Best example attending webinar organized by us. Now every month we are facilitating 3 hours live online session on advance topic for free. Join our sessions for free to learn and earn SEUs.  

So here you are in 2 months:-

Category “A” – 14 (1 full day, 2 meetup)

Category “B” – 32/40 (Either CSM+CSPO or CSM+CSD)

Category “C”– 06 (2 meetup on DevOps/Docker/Lean)

Category “E” – 15 (Reading my 3 favorite books) 

Category “F” – 15 (Attend either Atlasssian hangout or join our online live session)

Total SEUs is 82-90 in next 2-3 months :)

Write to me on naveenhome@gmail.com in case you have any query.

Yes, empirical process control helps but what is empirical process control?

I was talking to my friend last night about a meetup that she hosted yesterday. I asked what was expected outcome from there? Her reply was not clear to me so I was worried and tried to dig it deeper and found meaning of DONE is not clearly defined. Meaning process as well outcome is not transparent enough to see through what's going on. Is it OK to say that setting expectation from each and everything what we do is not good? I believe NO because if we don't set expectation and measure result then may not be motivated to do it again or improve it further.

Transparency is key for empirical process control and defining DONE helps in making outcome transparent. Since DONE is not defined so it will also become difficult to inspect outcome. If we cannot inspect then will not change plan and adapt it. 

If we are doing something then we should know why we are doing? What is expected outcome? Can I measure outcome? If not then is it worth doing? What is opportunity cost? Good to struggle with these questions rather than just executing something that can't be measured.

Last year we sponsored an event and we were expecting to have 300 people attending but there was only 50 people so we decided to stop sponsoring such events in future and figure out other way of promoting it. Spent same amount this year to host an event rather than sponsoring. Result is better than last year but still have to review as team to identify improvement areas or may be totally new things.

Yes it is very much important to set DONE criteria for what we do in order to improve ourselves. Things will not improve until we review and retrospect. Hoping it will improve automatically over the period sound very adventurous but talk to people those are on adventurous journey, they review outcome much frequent than others. 

Agile and Scrum Workshop for Business Analyst and Product Owner

Course Overview

Course will cover the Scrum framework but more importantly, what it means to function as the business analyst, or customer, for a scrum team. Participant will learn about managing stakeholders, creating and refining the Product Backlog, emerging detail with Product Backlog Items and User Stories including Acceptance Criteria and the Definition of Done and Definition of Ready. Course will have many exercises, in-depth discussion, case studies and techniques to help illustrate practices and principles. This workshop is for project managers, business analyst (BA), product owner, product manager and member of product management team.

Learning Outcome  

Understanding of Agile and Scrum

Practical knowledge of Scrum Framework and role of business analyst in Scrum

How to capture product ideas in a Product Vision Statement

How to write appropriate Product Backlog Items, which outline deliverable value for the

product

How to define Product Roadmap and Releases to aid in Product Lifecycle planning

Product and project budgeting in Scrum

Techniques for collaborating and interacting with the Development Team to ensure better

understanding of requirement.

Day -1

Scrum Basics

Understand the Scrum Framework, the core components of the Scrum framework, Roles,

Ceremonies, Agreements and Artifacts

Understand the principles of empirical process control and how to practice it through

simulation

Create work culture that helps in maximizing business value

Roles & Responsibilities

Understand the role of the Product Owner, proxy product owner and business analyst in detail

Understand why product mindset and not project mindset

Product Vision

Understand the importance of having the product vision as an overarching goal galvanizing the

entire Scrum team

Develop Product Vision using real case study

Understand the desirable qualities of the vision and how it can be shaped

Understand the importance of carrying out just enough prep work

Practice Impact Mapping to define product vision and roadmap

Understand the relationship between vision and product roadmap

Day -2

Product Backlog

Understand what the product backlog  and PBIs

Understand product backlog Refinement

Writing effective PBIs

Slicing PBIs using best practices like INVEST

Identification of MVP (minimum viable product)

Keeping product backlog in DEEP status

Prioritization

Understand the importance and benefits of prioritizing the product backlog

Understand the implications of saying everything is mandatory

Understand who should have input into prioritization decisions

Learn prioritization techniques such as MoSCoW and Kano

Understand how much latitude to give a team in adjusting the sequence of work

Estimating

Understand the different estimation levels in Scrum

Practice estimation techniques

Understand that estimates of size and duration can be done separately

Understand the difference between estimating and committing

Day -3

Release Management

Understand the goals and how to of release planning

Understand that planning is adaptive, iterative and collaborative

Understand why software should be released early and frequently

Understand and measure velocity to forecast

Understand release burndown charts

Understand how a release plan can help predict the future

Acceptance Test Driven Development/Behavior Driven Development

Understand how to write testable acceptance criteria

Understand the importance of automation in scrum

How to automate acceptance test

Learn Gherkin language to write feature file

Why and how to become Certified Scrum Professional (CSP)

Almost 200 professional become either Certified Scrum Master (CSM), Certified Scrum Product Owner (CSPO) or Certified Scrum Developer (CSD) through Leanpitch every month. We strongly advise every participant to focus on continuous learning and share your learning with others as often as possible. If you are learning and have required experience then also become certified scrum professional (CSP). Certified Scrum Professional (CSP) is not only a certificate but a milestone that demonstrate your skills and experience. If you are planning to become coach or already working as coach and wanted to earn Certified Scrum Coach (CSC) certification then CSP is 1st step towards it. Same apply for Certified Scrum Trainer (CST) as well. CSP doesn't required any training like CSM, CSPO or CSD but needed 70 SEUs (Scrum Education Units) that shows how much you are investing on continuous learning. These SEUs can be earn through various way and same mentioned below:-

Category "A" - Unlimited SEUs through Scrum Gathering and User group meetup. You can join Playscrum user group and attend monthly meetup in your cities. Playscrum user group available in 5 cities. -Playscrum-Pune, Playscrum-Bangalore, Playscrum-Chennai,Playscrum-Delhi and Playscrum-Hyderabad. Playscum also facilitated one day playscrum meet in Chennai and planning to keep facilitating same in other cities as well.

Category "B" - Unlimited SEUs through Scrum alliance training program like CSM, CSPO and CSD. You can also earn these Scrum Education Units (SEUs) through other courses like Test Driven Development (TDD), Behavior Driven Development (BDD), User story and agile estimation etc. Leanpitch deliver corporate training on TDD, BDD and User story development in New Delhi, Mumbai, Chennai, Pune, Bangalore and Hyderabad.

Category "C" - 15 SEUs under this category and same can be earn through attending any agile workshop like Kanban, LeSS practitioner, DevOps and PMI-ACP workshop. Leanpitch regularly conduct Kanban training in Bangalore, Pune, Chennai and Hyderabad.

Category "D" - 15 SEUs under this category through volunteer service for Scrum Gathering or User group meetup. You can reach out to playscrum  community.

Category "E" - 15 SEUs through self learning like reading few books. I would recommend reading below books. One hour of reading is equal to one SEU.

1. Agile Estimating and Planning: Mike Cohn

2. Professional Agile Project Management: Creating Innovative Products: Jim Highsmith 

3. Professional Agile Retrospectives: Esther Derby, Diana Larsen, Ken Schwaber 

4. Agile Software Development: The Cooperative Game Author: Alistair Cockburn

5. Coaching Agile Teams: Lyssa Adkins 

6. Effective Project Management: Traditional, Agile Extreme: Robert K. Wysocki

7. Exploring Scrum: The Fundamentals: Dan Rawsthorne with Doug Shimp 

8. Kanban In Action: Marcus Hammarberg, Joakim Sunden

9. Kanban: Successful Evolutionary Change for your Technology Business: David J. Anderson 

10. Lean-Agile Software Development: Alan Shalloway, Guy Beaver, James R. Trott  

11. The Software Project Manager’s Bridge to Agility: Michele Sliger, Stacia Broderick

12. User Stories Applied: For Agile Software Development: Mike Cohn 

13. Agile Product Management with Scrum: Roman Pichler

Category "F" - 15 SEUs through co-training or live webinar 

Leanpitch has brought below program for you to learn and earn SEUs in your city.

Certified Scrum Product Owner (CSPO) - 16 SEUs under Category "B" - For product owner, product manager, project manager, business analyst and leaders to maximize product business value. Leanpitch conduct Certified Scrum Product Owner (CSPO) training in Bangalore, Pune, Chennai, Mumbai, New Delhi and Hyderabad.

Certified Scrum Developer (CSD) - 24 SEUs under category "B" - This will give you opportunity to learn agile engineering practices and most suitable for scrum master, developers, testers, agile coaches and as well as for managers to build value and focus on outcome. Leanpitch conduct Certified Scrum Developer (CSD) training in Bangalore, Pune, Chennai, Mumbai, New Delhi and Hyderabad.

Certified Kanban Management Professional - 15 SEUs under Category "C" - For practicing scrum professional including scrum master, agile coaches and senior management to maximize value. Leanpitch conduct Certified Kanban Management Professional training in Bangalore, Pune, Chennai, Mumbai, New Delhi and Hyderabad.

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.