In the last decade or so we've seen a number of new ideas added to the mix to help us effectively design our software. Patterns help us capture the solutions and rationale for using them. Refactoring allows us to alter the design of a system after the code is written. Agile methods, in particular Extreme Programming, give us a highly iterative and evolutionary approach which is particularly well suited to changing requirements and environments. Martin Fowler has been a leading voice in these techniques and will give a suite of short talks featuring various aspects about his recent thinking about how these and other developments affect our software development.

A common theme runs through conferences, whether focused on MicroServices, DevOps, Lean Startup, or a myriad of other popular topics: Enabling an organization to Go Faster . I explore the need to go faster (which is hardly new), and three areas inhibitors arise: Technology choices, staid business Processes, and traditional Organization structures and roles. For each, I cite personal experiences in overcoming each.

Your app is a unique snowflake. Your tests are too… but they shouldn't be!

You know the person on every project team who cares just a little bit more about testing than everyone else? This talk is a distillation of the lessons learned I've learned from being that guy on dozens of projects.

This is a rapid-fire session that covers 15 systemic problems that plague most teams' test suites, presented form an angle you probably haven't considered before. Best of all, it'll equip you with preventative measures to avoid or mitigate each of them.

On Agile teams, collaboration is the way of life. Our leaders want their team members to work closely with each other, have shared goals and even think as one entity. Why? Because we believe that collaboration leads to happier, more productive teams that can build innovative products/services.

It's strange that companies use the word collaboration very tightly with innovation. Collaboration is based on consensus building, which rarely leads to visionary or revolutionary products/services. Innovative/disruptive concepts require people to independently test out divergent ideas without getting caught up in collaborative boardroom meetings.

In this presentation, Naresh Jain explores the scary, unspoken side of collaboration and explains in what context, collaboration can be extremely important; and when it can get in the way or be a total waste of time.

Do you want to know the latest on what really drives IT and business outcomes when you're trying to rollout DevOps? This is the talk for you. Here, you'll find out that the best IT performers have the highest throughput and reliability while contributing to their organizations' profitability, productivity, and market share goals. You'll also find out what the industry is doing in things like security and containers, and a deeper look into continuous delivery and lean management practices, and how these relate IT performance and quality. You’ll love the results. This talk is great for executives and business directors because it will help you understand the value proposition of DevOps and how to achieve the best outcomes. This talk is also great for practitioners because we help you understand the practices that predict high IT performance – and arm you with the data you need to make your case to the executive suite for DevOps and resources.

Cultural change is hard and in big organizations, it is even tougher to effect.

When it happens, it happens gradually.

As change agents and coaches, who are working on the ground everyday, sometimes it feels like there is no change happening at all.

The trick is to take a step back, move away from the bits and bytes, and take a look at the longer, broader picture.

So we did just that and the results are heartening.

We would like to share the cultural evolution in Amdocs Delivery and how being Agile is gradually being built into the fabric of our organization.

And we would like to share it through images, info-diagrams, pictures - we like to think of it as a time-lapse representation of the change we are undergoing.

We like who we are becoming - and we would like to share our story with you!

___________________________________________________________________

Who are we?

Amdocs is a leader in Customer Experience Systems and Services. We are more than 20,000 professionals across the globe, serving customers in more than 70 countries.

Many software delivery teams struggle to have a common understanding of "why" a product or feature is being built. The documents such as Project Charter, vision document etc. tries to solve this problem, but it’s common to see such documents exist in the repository, hardly known or read by anyone in the team. And this document rarely gets updated too. Ask your team members what is the goal of the project? You may be surprised to know how many actually know about it.

This is where Impact Mapping comes into the picture. It is a "Strategic planning technique", defined by Gojko Azdic, explained in the book Impact Mapping. It is a very simple technique based on the idea of "asking the right questions" which are:

• Why are we building what we are building? 
• Who are the actors who gets impacted?
• How do we expect to change the actors’ behavior?
• What should we do to create the impacts? 

Fundamental of Impact Mapping is that Impact means a change in behavior of an actor which usually results in a positive impact either by Reduction in the Cost or Improvement in ROI for the business.

The above questions need to be answered by the entire team [the IT team, the business people and any other stakeholders, if any], and avoids the common anti-patterns:

• Ad-hoc planning
• Wrong Assumptions
• Pet features

There are programmers... and then there are great programmers..The ones that are 10x.

10x development is not only about speed. It is much more - its about creating 10x value.

As one blog author puts it beautifully "A 10x developer will have insights and find solutions that would never occur to an average programmer; they will avoid entire categories of problems that eat up enormous amounts of time amongst average programmers. 10 engineers writing the wrong code could definitely be out performed by a single engineer writing the right code."

Their behaviors and practices are visible. We see them in action. This excellence is rarely a matter of only skill. It's coming from deep within. The things that drive them, the values and principles that guide them essentially result into the 10x performance that we see.

In this session, we will see what going on in the minds of these 10x programmers. What is the stuff that makes them 10x.

Feature branching has been popular for long, but everyone knows about the “merge hell”, a common issue because of long lived branches or infrequent integration. How do you continuously merge, test and release software with great confidence without spending too much time on merging and fixing conflict issues. That is where Mainline development, one of the key practices of Continuous Delivery, comes into picture and Feature Toggle works in conjunction with the same. Feature Toggle [also referred as Feature Flip, Feature Switch, Feature flag] is a technique which allows you to turn on or off a feature through configuration. Feature toggles gives you the flexibility to toggle features in specific environments i.e. turn on a feature in pre-production environments and turn it off the same in production. This also helps to rollback features, as rolling back is as simple as turning off the feature and deploying.

You have a great idea and you want to get it to existence. How do you proceed?

You know that the key to successful product startup is:
1. Building the right product
2. Moving fast

Here’s what usually happens:

• You’ll spend a few weeks getting a better understanding of the Idea.
• Decide a list of features that needs to go into the product.
• Visualise the idea by drawing a few sketches and spend few weeks trying get feedback from your expert friends. (Let’s meet at Starbucks… Dinner’s on me!)
• If you get a good signal, you then are challenged with finding someone to design and build it for you.
• After a month of searching, you find a friend/agency/freelancer/intern/new-hire.
• You have a team and an office. You spend the next 3-4 months building the MVP. The product is coming around nicely and you are making sure all details are taken care of… And of course, event tracking! Measure everything.
• You then release the product into the wild! (Party!)

It’s now been up to 6 months to a year since you first come up with the idea. Your analytics just doesn’t have enough traffic yet to tell you what’s working and what’s not! You struggle to have a good picture.

Consider this:
If we met 6 moths ago, and if I told you, I have a time capsule wherein you can travel through time, to the end of the product development and know how your users will react to your product. Would you take it?
Of course, you would!

The time capsule I’m talking about is called the Google Venture’s Design Sprint. It’s a 5-day process to validate critical business assumptions. It uses design thinking and lean startup methods to de-risk your product by better solutions and testing it with 5 real users. At the end of the design sprint, you’ll know what connected with your users and what just didn’t make sense to them.

This process will save you months and months of time spent in meetings, research, design, coding, marketing.
5 Days. Monday to Friday. That's it!

The most common objection people have against User Research is, "People don't know what they want" and they go ahead and quote:

“If I had asked people what they wanted, they would have said faster horses.” ― Henry Ford

He's right! But, that's the wrong question to ask your users!

What if you ask instead, "What do you want to get done with your horses?" or just followed it up with a simple "Why?".
Then people might have told you, "I want to reach the other town faster", "I want to be able to carry more people or more goods", "I want to feel the thrill of speed",...

Then it's your job to figure out "How Might We move more people faster with minimum maintenance and cost?"

Let's take another example,
Bad question:
You: "Will you brush your teeth at night from tomorrow?"
User: "Of course, twice a day!"

People are incredibly optimistic about doing things in the future. A good question would be:
You: "What does your night routine look like?"
User: "I have dinner, clean the kitchen, make the bed, Turn on Netflix, switch night lamp on and fall asleep watching House of Cards"

In this talk, I'll share with you, my learning and experience doing user research.