“When nothing seems to help, I go and look at a stonecutter hammering away at his rock, perhaps a hundred times without as much as a crack showing in it. Yet at the hundred and first blow it will split in two, and I know it was not that last blow that did it—but all that had gone before.”

― Jacob A. Riis

What we all see as a big transformation, is actually the sum total of all the little things that add up to such big events. Yet, how often, we ignore those little things, but instead keep trying to achieve the big transformation through large scale changes.

In this talk, I explore the value of building trust and human connection, the power of little habits, and how, even the best intentions of doing the right thing and doing the thing right, can fail miserably if we don't address the issues at the system level.

How keeping things simple can help build better products. There are simple, pragmatic and powerful ways that can help us to reduce the risk of starting new initiatives and get real feedback quickly. I will share experiences where simple techniques of using a pen and a paper to create a paper prototypes helped us answer complex problems and validate business ideas, quickly.

This approach helped in building an innovative and world-class product called Springer Nature Experiments, allowing researchers across life sciences to quickly find and evaluate protocols and methods across life sciences. Springer Nature Experiments combines portfolios across the Springer Nature resources which is the largest in the life sciences, to make searching for experiments easy and effective.

We talk about a journey of a product where as a team we made a conscious decision to incessantly strive to keep things simple and lean (by default).

I will share examples of companies like Muji, Braun, Bose, Leica, Apple, Google - that are trying hard to keep their product and UX designs simple. Getting inspired, we chose to use the philosophy of “Keeping it Simple” in building our teams, adopting Agile methodologies, choosing the right set of ceremonies, technical practices, UX design etc. In addition, having the voice of our target users in the development process, helped us build the right MVP and eventually churn out the product that delighted the business and users.

We kept asking the question “how can we make this simpler?” Answering this was important, for each aspect of the website design or the code being written for it. There were times when we wanted to pull our hair out, but hey, who said unbundling the complexities is simple. But then again, simple is harder than complex.

Try to get your head around the above paradox :).

While working with Agile projects, tracking and showcasing the progress of the project is an integral component that is of special interest to the account managers, product/ project managers, product owners and business stakeholders. A typical Agile project would be working with estimates, story points, velocities, burn-up or burn-down charts.

I have witnessed numerous sprint reviews and showcases where the business is only waiting to see those few slides of the presentation where there is the "actual" red worm, running against the "planned" green worm, trying to catch-up. If the red worm is ahead, I have seen a smile on the faces of the stakeholders. If it matches the green one, there is a sigh of relief. And as a development team you should just pray that the poor red guy is not falling behind the green one, lest it might lead to a lot of questions starting with why, how, what etc.

There have also been times where there have been some unfortunate heated discussions that last forever on why did the team end up not claiming a few points that they had committed. What gets lost is what the team accomplished in the sprint that adds good value to the product. There have also been times where the estimates are being questioned by the product owner or account managers. If you are working in a distributed setup where the product owner is working out of a different country, the problem is even bigger.

Let us think about a scenario where the project gets completed on time, budget and scope. Majority (or all) of estimates were correct. However, when the product went live to the market it failed big time. What is the use of building such a product? 

Are we focusing too much on numbers and points and overlooking the other important aspects of Agile software development such as producing software that delights the customers and looking for ways on how we can measure that? Are we measuring if we are creating a solid, robust and a scalable platform that is ready for future developments and enhancements? Are we measuring the outcomes of the time we are spending in the shoes of the people who will actually use the software?

The objective of this session is to promote the thinking of measuring what matters for your project. To measure the goals that your software development wants to achieve. I don't plan to showcase an exhaustive list of measurements that can solve all your problems, however, I instead want to highlight some samples that I have used in my projects with the help of my team, that helped us to measure things that add value to the business and development v/S simply creating burn down charts.

Majorly, I want to encourage the audience of this session think out of the box to identify what measurements will really matter for your projects. Perhaps from the eyes of the users and business and see what things if measured will add a lot more value than simply estimates, and will help in creating a valuable product that will truly delight the business and the users of the product.

A Project Manager plays multiple roles in the organization. He or she has a role towards the team, towards the project, towards the business stakeholders and towards the organization itself. 

The days of traditional project management evangelizing the concepts of "Command & Control" are long gone. Especially with Agile software development, the focus is more and more on building self managed teams. 

It is said that it is easy for a project manager to lose his or her mind :D. Especially if you are under constant pressures of reporting project financials, status reporting, managing your project staffing & recruitment, stakeholder management, distributed teams, risk management, project planning, inceptions, lift-offs, project governance and to top it all, leading a group of different psychological beings who may be responding differently in different situations. There is no one size fits all when it comes to working with human beings, and you have the onus to build a self managed team. Hence, probably it is more apt to call our breed as project leaders than managers, but let us leave that discussion to a different day.

So if you are a project manager and getting stressed due the above mentioned pressures, or if you are clinging to the past styles of project management or you like being "old school", you may not realize but you might have turned into a devil.

How to be sure? Well... this session will offer you a checklist to confirm how close you are to being a devil or already have become one.