In the early 20th century, Alfred Kroeber wrote about patterns in Anthropology; the structures that make up our culture. Several years later, Christopher Alexander took those same concepts into Architecture and described the patterns we find that make beautiful cities, buildings, rooms. For the past several years, big names in Scrum have been coming together to talk about the patterns of Scrum; How Scrum works, why it works and how to implement it, using patterns. This group of people have several person-centuries of combined experience with Scrum.

The third wave of Agile is upon us. Check out my voyage to the Third Wave.

A couple of weeks ago, a friend of mine asked me to talk to his sister. This sister has her own company teaching Project Management (sorry, gross generalisation but bear with me). She mostly specialises in non-IT projects using information from Prince2, Lean and other platforms. A lot of the time, though, there are IT components in the projects and programs running in the companies she works for. And lately that means she meets Agile practices on her way. She wanted to know more about Agile in general and so we sat down for a talk. As some of you may know, my main life goal is Agile World Domination. Any time I can talk to any professional about Agile and what it can do for them, I take that opportunity to further my ominous life goal. The original intent was to see what we can do for each other. We talked about my work, her work, where those two touch and what we can add to each others understanding of the world. At one point she said “The biggest issue I face is with companies that use classic Portfolio Management. How does Agile fit there?”

Last week a friend of mine told me a story that I wanted to share with the rest of the world. A couple of years ago he was working as a line manager. Together with a colleague he managed a group of about 25 people, consisting of two teams. Each team was responsible for their own domain. Expectation planning forecast that one of the domains would be receiving less work in the future, whilst other domains were destined for a higher volume of work and would require a heightened focus. The team dynamics would need to change.

In the transformation process to a modern organisation, one of our managers finds it hard to let go of his tasks and responsibilities. He wants to, but he doesn't really know how to. His own transformation is that of the Operations Manager to Product Owner of our main product.

Lately I've seen SCRUM implementations where a project has a Project Manager, a Product Owner and a SCRUM team. In my opinion, SCRUM should never have a Project Manager. The role does not fit in the architecture of a SCRUM process. Not only because SCRUM is unsuitable for projects (SCRUM does not recognise projects, only products that are in a state of perpetual change) but also because all tasks attributed to the role are assigned already within SCRUM.

I've quoted Dan Pink before and I'll probably keep doing it often, his work: "Drive; the surprising truth about what motivates us" is a classic and a must-read for everyone that has anything to do with management. But how does one go about implementing these motivators? Let me tell you how I try to do this with Software Development teams.