Agile for managing a research data team


An interesting read: Lessons learned managing a research data science team on the ACMqueue magazine by Kate Matsudaira.

The author described how she managed a data science team in her role as VP engineering at a data mining startup.

When you have a team of people working on hard data science problems, the things that work in traditional software don’t always apply. When you are doing research and experiments, the work can be ambiguous, unpredictable, and the results can be hard to measure.

These are the changes that the team implemented in the process: Continue reading “Agile for managing a research data team”

Modern agile?

InfoQ recently posted an article about something called “Modern Agile” by Joshua Kerievsky which sparked my curiosity. It seems that there is also a website but did not find other references beside the author’s articles or keynote.

What is modern agile?

Modern Agile is ultra-light, the opposite of mainstream Agile, which is drowning in a bloated tangle of enterprise tools, scaling frameworks and questionable certificates that yield more bureaucracy than results.

Well, after reading it, seems to me that is nothing more than the principles already outlined in the original Agile Manifesto.
Not sure what Modern stays for …

Modern Agile has no roles, responsibilities or anointed practices. Instead, it is defined by four guiding principles

  1. Make People Awesome
  2. Deliver Value Continuously
  3. Make Safety a Prerequisite
  4. Experiment and Learn Rapidly

It goes then on to describe how these four guiding principles match one-to-one with the four Agile values from the manifesto … well, then why do we need them?

I fully agree that some interpretations (is this what is intended with “mainstream”?) of Agile (or better, Scrum …) are becoming over-engineered with all these frameworks but in its original concept was already a light process with only four values.

No need of new interpretations.
Let’s just go back to the roots of Agile mindset.

My new book: “from Zero to Agile”


I have just published on Amazon my new book about Agile.

Agile is on great advance, more and more organisations and teams adopting it. But what is it exactly? And how do you become agile?

In this book I want to show how is possible to introduce gradually a series of changes so that at the end your organisation will be agile (i.e., it has understood the Agile values and principles and know how to apply them), not only does some kind of Agile practices.

Through examples you can see how to introduce and tailor the Agile principles, week after week: in 8 weeks we took a team with no prior experience of Agile into changing its mentality and attitude.

I hope this journey can help your team (and further: the entire organisation) to do a similar one toward the same goal: being Agile.

The examples show which are the general principles and why / when they make sense, so you will be able to inspect your situation, adapt these principles (as needed) and adopt them, finally repeating this cycle continuously.

Build your method up, don’t tailor it down.

Finally, this book is about agility as values system, culture, mind-set, and not about a specific process or methodology. All the currently most used methodologies – Scrum, Lean and Kanban – will be described, each one with its advantages and disadvantages.

The book contains revised versions of the posts published here in the past plus several brand new chapters (about Kanban, how to scale Agile and many examples of retrospectives for each topic introduced every week).

[Link] Embracing Agile

The article “Embracing Agile” in the May 2016 of Harvard Business Review
by Darrell K. Rigby, Jeff Sutherland and Hirotaka Takeuchi is a landmark in the history of management, especially considering that is in an institution such as the HBR magazine that an article about Agile appears.

After a brief introduction and a brief history about its genesis, the article explains its manifesto, its principles and how Agile works goes using the three most used frameworks: Scrum, Kanban and Lean, but mostly Scrum.

Innovation is what agile is all about. Although the method is less useful in routine operations and processes, these days most companies operate in highly dynamic environments. They need not just new products and services but also innovation in functional processes, particularly given the rapid spread of new software tools. Companies that create an environment in which agile flourishes find that teams can churn out innovations faster in both those categories.

Following is a section about where Agile works better (authors use the terms “where it works and where not” …)

And finally a large section about how to introduce agile: start small, first learn then adapt, get top support, remove barriers.

Large companies typically launch change programs as massive efforts. But the most successful introductions of agile usually start small. They often begin in IT, where software developers are likely to be familiar with the principles. Then agile might spread to another function, with the original practitioners acting as coaches. Each success seems to create a group of passionate evangelists who can hardly wait to tell others in the organization how well agile works.

Bottom line, the final paragraph:

Agile innovation has revolutionized the software industry, which has arguably undergone more rapid and profound change than any other area of business over the past 30 years. Now it is poised to transform nearly every other function in every industry. At this point, the greatest impediment is not the need for better methodologies, empirical evidence of significant benefits, or proof that agile can work outside IT. It is the behavior of executives. Those who learn to lead agile’s extension into a broader range of business activities will accelerate profitable growth.

A great companion of this article is the review written by Steve Denning on Forbes.

It’s a generally positive review but Steve Denning highlights a couple of points which are missing or incorrect, primarily that Agile is a mindset and not a methodology, it’s a different culture and requires that the entire organisation embraces it.

For those who live and breathe and implement Agile on a daily basis, Agile is a mindset. Agile isn’t just a methodology to be implemented within the existing management framework. Agile is a dramatically different framework for management itself. In the community of Agile practitioners, which now numbers in hundreds of thousands, Agile begins with a different view of the goal of the organization. […]

Agile aligns with Peter Drucker’s 1954 foundational insight: “The only valid purpose of a firm is to create a customer.” It is the management basis for the emerging Creative Economy. It is the foundation for continuous innovation. […]

“The highest priority,” as the Agile Manifesto states, “is to satisfy the customer.”

This is a revolutionary declaration. In most public firms today, the highest priority is not to satisfy the customer. The highest priority is to maximize shareholder value as reflected in the stock price.

[Link] The five keys to a successful Google team

An interesting article from the NY Times  about a 2012 Google initiative— code-named Project Aristotle — to study hundreds of Google’s teams and figure out why some stumbled while others soared.

The article itself is a longer and more narrative recount of what has been posted earlier by one of the lead researchers, Rozovsky. Following is a summary and highlights, see the article for the entire text.

After months arranging and looking at the data, Rozovsky and her colleagues were not able to find any patterns or even an evidence that the composition of a team made any difference.

We were dead wrong. Who is on a team matters less than how the team members interact, structure their work, and view their contributions.

As they struggled to figure out what made a team successful,  they looked at what are known as ‘‘group norms’’: the traditions, behavioural standards and unwritten rules that govern how we function when we gather.

Team members may behave in certain ways as individuals but when they gather, the group’s norms typically override individual proclivities and encourage deference to the team.

Project Aristotle’s researchers began searching for instances when team members described a particular behaviour as an ‘‘unwritten rule’’ or when they explained certain things as part of the ‘‘team’s culture’’ and which norms mattered most.

There were other behaviors that seemed important as well — like making sure teams had clear goals and creating a culture of dependability. But Google’s data indicated that psychological safety, more than anything else, was critical to making a team work.

Psychological safety is ‘‘a sense of confidence that the team will not embarrass, reject or punish someone for speaking up,’’ Edmondson wrote in a study published in 1999. ‘‘It describes a team climate characterised by interpersonal trust and mutual respect in which people are comfortable being themselves.’’

However, establishing psychological safety is, by its very nature, somewhat messy and difficult to implement.

What Project Aristotle has taught people within Google is that no one wants to put on a ‘‘work face’’ when they get to the office. No one wants to leave part of their personality and inner life at home. We can’t be focused just on efficiency. Rather, when we start the morning by collaborating with a team of engineers and then send emails to our marketing colleagues and then jump on a conference call, we want to know that those people really hear us. We want to know that work is more than just labor.

Finally, Google created a 10-minute exercise that summarises how the team is doing on five key dynamics:

  1. Psychological safety: Can we take risks on this team without feeling insecure or embarrassed?
  2. Dependability: Can we count on each other to do high quality work on time?
  3. Structure & clarity: Are goals, roles, and execution plans on our team clear?
  4. Meaning of work: Are we working on something that is personally important for each of us?
  5. Impact of work: Do we fundamentally believe that the work we’re doing matters?