Month: January 2017

The agile triangle

I have seen and heard a lot of discussions regarding whether Agile-frameworks like SAFe, LeSS, DAD, Enterprise Scrum, etc is agile or not.

Some parts of the agile community tend to be very anal in their perception of these frameworks.

My interpretation of these peoples thoughts, is that they see the agile world almost like the traditional and terrible cost-time-scope triangle, but replacing it with a people-culture-<insert framework here> triangle.

And then saying that you can’t have a constant in that triangle, like the <framework>.

You should of course not see or refer to the frameworks as a constant, more as a good idea on how to do, or a smart quick-start with an out-of-the-box solution.

But of course, as Peter Drucker once famously said:

“Culture eats strategy for breakfast”

Learning and understanding the principles and core values of lean and agile, is of essence in an lean-agile implementation/transition.

A framework is not a silver bullet in any sense, or as my good friend and colleague Andreas Rowell once said:

“It is all about the context, context and context. There are no such thing as best practices – practices are good or bad depending on the context. Experience tells the difference.”

I agree that no framework in the the world will make you agile or lean, but they might give you a pretty good platform to evolve from.

Scrap your PMO?

There will be many line and project managers who are not happy with me saying that you should scrap your project management office (PMO), but please just hear me out.

When I worked at a major truck manufacturer in Södertälje, a very senior R&D manager said something like:

“The PMO is unnecessary, let the functional organization do what they know best instead”

I was at this time working as an independent consultant at this PMO, and was as usually the youngest project manager among my peers.

Me and some of my colleagues at the PMO obviously thought what he said was nonsense and that he spoke in his nightcap, not understanding the benefits of having use there. Reasoning together and coming to the conclusion that “nothing” would work without us.

Now a few years later when I am a little bit more experienced, loaded with new insights and have jumped off my high horse, I am willing to agree with the senior managers words.

A PMO often tries to dictate command and control, and instead of being proactive we always seemed to be one step behind. With the typical symptom of constantly updating our plans and asking steering committees for added funding or postponed start of production dates.

Don’t get me wrong, we did some great stuff as well, like planning exercises very much alike the Big Room planning of the Scaled Agile Framework, but instead of doing it for smaller increments we did them for a whole project, spanning a couple of years, thus making them very hard to grasp.

My interpretation of what the senior manager really meant was that we should let the development organization focus on the creation of real customer value and not make them attend to meaningless meetings and create status reports among other things.

Value itself should come from discussions with the an empowered and strong product management team.

Reading this you won’t make you scrap your PMO and you probably shouldn’t either.

But what I think you should do as line or project manager, is try to act as a servant leader and help to remove the impediments that limits the communication between product management and development teams.

But also to help them to decrease the size of increments, limit the number of projects in progress and embrace change both in scope and in workflow.

Do you agree?

Thoughts about responsibility

Way of working and personal development is important to everybody.

As a scrum master or project manager, is it not needed to have wast rules with your development or scrum team. In your effort to to increase productivity, do not tell them what or how to do. Instead respect them as independent sentient beings, who have the where with all to make conscious decisions for them selves, embrace and encourage that.

So I propose an agile mindset and not to bury yourself in the toll gate or strict scrum trenches.

So when you are in a context that has limitations like, code debt, other departments wow’s or legislation, I don’t tell them:

“You can’t do it like that!”

Instead I say:

“Have a great time and make the best possible choice for you”

But that doesn’t mean that they always make the best choices, but you are then empowering them and they continuously learn about what works and not.

I mean, waste is bad, but not learning is worse, and we probably have a long road ahead together, right?

So its all about getting your team to think consciously about their own choices; to become informed, educated and prepared. So that they are responsible stewardess of their product/system and company, and are responsible stewardess of their own roles and development.