Product Owners and others responsible for creating and maintaining the Product Backlog often focus on functional items.

With good engagement in the Backlog Management process from the Development Team and Architects, technical and architectural items also find their way into the Product Backlog.

But what about the human-centric items related to accessibility, inclusivity, internationalization and sustainability?

Through the talk and with the help of several supporting examples and a short exercise, I would like to highlight the importance of addressing these aspects in the Product Backlog. The examples will include examples of good and bad backlog items and design decisions.

I will also share some tips on how Product Owners and supporting roles can work these aspects into the Backlog Management process. These will include some ideas from Design Thinking but will not be limited to that.

ScrumMaster who take their role seriously are beset with difficulties. As a process Owner and problem solver, the issues are many and systemic fixes needed. So what can/should they do? As with many other competencies, problem solving needs practice. Here we confront a fictitious case-study (based on two real projects) with help from India's first Scrum coach. As he takes you through the thicket of a complex situation (aren't all real situations complex, and not just "complicated"?) you will get a series of in-depth example SM situations. Further a moderated discussion on how to handle them. Some will be your own. This will be different from a Certified Advanced ScrumMaster class, this doesn't have much coaching content, but a strong problem solving slant.

NOTE: Case study here is of a "cummulative" type, which allows drawing wider lessons based on familiar common experience. The situation is meant to illustrate common (and one or two not so common) problems and their treatment.

Background

A variety of branching strategies exist in the delivery universe as of date. Having worked with multiple of these, in my personal experience, I have explored the pains and gains that each of these strategies have to offer. While there are certain situations or delivery patterns that might make a certain strategy a better fit, in my experience, Trunk Based development usually is the most sane way of writing, maintaining and delivering production code.

Approach

Trunk Based development is a source-control branching model where developers push code ( of all possible features that are in development ) on to a single remote branch, referred to as the trunk. Developers at all costs try and resist the urge to create other long-lived development branches. This is important because developers, including myself, are mostly lazy. So if there is something that can ease their lives off today, they would rather do that knowing that they are up for a hard day in the future. This is mostly the paradigm of not developing on the trunk. Branching by features makes it easy for development teams in the shorter run. However a developer is well aware that he is going to stay up late in office the moment his project manager says that the code he has written on the trunk has to be released. What follows is merge hells, integration nightmares, bugs, angry developers and divorces.

Findings

In my career, I have worked with a bunch of branching strategies up and until now. While it is indeed easier in the shorter run to create feature or team-specific branches, it is almost always a painful and tedious job to bring things back into the master in order to release. Also in my opinion, other branching strategies defeat the entire purpose of Continuous integration since not ALL the code that is being written is being tested in unison.

Almost all products in this world are not entirely tested only because -

• They can not wait for exhaustive tests to happen
• They do not know how to get the 100 exhaustive test suits.

Combinatorial Array is the new breakthrough in the Testing Algorithm. It reduces your test suit by 10 times or more. This Presentation will take you deep in to what Orthogonal Array based Testing is , its limitations, the solutions by CT.

This is one way you can make your testing Agile and also makes your test coverage 100%

The org culture mantra is usually considered a silicon valley mumbo jumbo. Although many companies and teams rant about culture, very few in my opinion take it seriously. In this talk I would like to discuss the importance of Org culture and how it makes or breaks businesses and teams. I will lay out some key pointers that will help the influencers in the audience make decisions about their org or team culture. The talk will be in the context of culture in tech companies.

Agile isn't just for software, it's for your thing, whatever that is. In my keynote talk, Agile for Everything, I introduced six fundamental patterns that comprise Agility. They apply not just to software, but to virtually any situation where rapid adaptation can improve success.

In this workshop, I'll teach and coach you to apply those six principles to your thing. "Your thing" might be marketing, UX design, software, finance, hardware, business development, product management, your company, your family, your career, a classroom, your education, your kids' education, an art project, or building a house. Or it might be something else.

You gain two ways attending this workshop: First, you will get coaching help in achieving "your thing," whatever that is. Second, you will gain an intuitive, visceral understanding of agility—its strengths and limitations, its nuances and quirks. That understanding will help you rapidly assess agile opportunities and dangers, and will help you teach and coach in more fruitful ways.