Scrum Master skills conversion from other roles

The roles of Product Owner (PO) and especially of Scrum Master (SM) can be quite difficult to define when you are first approaching Agile and assigning this position or searching someone for the role.

Notably many companies just tend to copy&paste the descriptions for classic PMs or even re-assigning people with these roles to the new Scrum titles.

Nothing is written in stone and of course every company can tailor its processes but if you are going to use Scrum as a framework to be agile, you need to be aware of the differences and nuances.

Especially converting Project Managers (PjM) to Scrum Masters is filled with problems. They are all different roles, are not even superficially similar and they all require different skills but notably different mindsets; as such any “automatic conversion” will not always work.

Moreover, SM is a role not a job title. A team member of a cross-functional team can have multiple roles, being sometime a developer, some time an architect and a tester and also acting as a SM. Not easy for a classically trained PjM to immerse in such a team.

Agile shift all responsibility from a project manager to a team, in such case many organisations ponder how best they can make their project managers useful enough.

Converting PjM to PO might be easier than PjM to SM, there is more overlap between the former two than between the latter two.
PjM can become PO if they have domain knowledge.

But if an organisation is Agile and still need a PjM with title “Agile PjM” then it is a big question mark on their Agile correct adoption and mindset.

The same reasoning applies to a Business Analyst (BA) or Product Manager (PdM) though that’s an easier transition.
Let’s first have a look at the Scrum Master transition and in the next post at the Product Owner transition. Continue reading “Scrum Master skills conversion from other roles”

Advertisements

Effective military corps are Agile

I never read it but I have been told that the Marine’s Corp “Warfighting” manual  contains several similarities with how Agile projects and teams should be.
If you also don’t feel to read the dense 100+ pages document here is my shorter take, inspired from what I learnt during my mandatory military service time (well, I was not in the Marine’s but still in a rapid response force).

Embrace changes

Traditionally you associate military to huge command-and-control structures but that is not always the case.

Continue reading “Effective military corps are Agile”

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”

cover

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.