Some rifts are occurring in AgileLand - a world supposedly driven by cooperation, trust and appreciative inquiry! Debate is arising about first generation agile methods (XP, Scrum) and newer upstarts like Kanban and the Scaled Agile Framework (SAFe). Perhaps because market shifts carry training and consulting revenue with them, but a few people don’t seem very happy, as evidenced by some recent blog posts.

Ken Schwaber’s UnSAFe at Any Speed article describe SAFe as a RUP based dinosaur focussing on processes and tools rather than individuals and Interactions. Ian Mitchel summarises the Scrum vs SAFe debate well in his piece Method Wars and speaks to his own SAFe experiences.

David Anderson wrote a post on how Kanban is Anti SAFe in the way the two methods approach adaptation for an organization. He describes SAFe as a collection of (somewhat outdated) software development best practices that you engage an expert or team of experts to tailor for your organization. Kanban on the other hand is based on the idea that knowledge workers know more about their domain than their supervisors or outside experts do and should therefore be the people selecting and tailoring the approach.  So, instead of using experts to select and tailor process, the team does this work as part of the innovation culture fostered by Kanban.

Alan Shalloway describes Why Net Objectives Supports SAFe; they are a SAFe Silver partner organization, and believe it offers a proven, documented approach to scaling agility that is underpinned by sound lean and agile principles.

When I read these different accounts I find myself agreeing up to a point with each perspective. I don’t go quite as far in my beliefs as each author, but if I was talking to the authors I’d probably just nod and bite my tongue for the small portion I feel they are pushing too far. So does that make me a hypocrite, or an easily persuaded novice?

Feeling a little uncomfortable, but not caring enough to worry about it too much since I’d rather be solving business problems rather than debating religious wars that rarely deliver much value, I found an explanation from an unlikely source. A friend had sent me a link to a DiSC Leadership profile tool, it asks a series of questions about your preferences in a leadership role and generates a nice report on your Leadership style.

My assessment indicated a “D” Dominance preference for Getting Results, Taking Action and Offering Challenge.

 The tool lists some good tendencies of having a strong drive to:

• Achieve results
• Overcome  obstacles
• Get things moving
• Work towards challenging goals
• Convincing others

The assessment also pointed out some potential negative traits including:

• Problems following strict rules and protocols
• Performing routine tasks
• Getting bogged down in inefficient procedure or meetings
• Things that slow down your pace
• Dealing with people who don’t meet your standards

Generally I am not a big fan of personality profiles, perhaps I hope to be not as stereotyped or easy to categorize as they suggest. I like to think people are unique and multifaceted, but this DiSC Leadership assessment summarized my tendencies very well and helped me understand why I feel the way I do about agile, Kanban, SAFe and even the PMBOK Guide.

Basically I am more results driven and will employ and adapt whatever tools and processes I think will help me achieve those results. As I have said before, if abandoning agile principles and instead wearing silly hats got my projects done better, I would be all for it. Instead however building motivated, empowered teams and championing smart behaviour from all stakeholders through servant leadership and savvy project management is the best I have so far.

So, when I look at the SAFe framework I don’t see too many problems, but instead tend to employ the elements I think suitable to solve my current project’s issues. Due to my “Problems following strict rules and protocols” I probably would not engage SAFe consultants to guide its implementation, but instead discuss the framework with the team and gain consensus for elements to incrementally trial. Being told “That’s not how we do it” or “The PMO has a different standard” tend to fall into my blind spot of “Getting bogged down in inefficient procedure or meetings”, “Things that slow down your pace”, and “Dealing with people who don’t meet your standards” etc.

I do see that these are weaknesses I should work on, but I am hired to get results and deliver value. When this occurs without breaking too many rules or upsetting too many people I call it a good day. I see bending rules and flexible interpretations of process as an enabler of value delivery. For example, in the recent upgrade from the PMBOK v4 Guide to the PMBOK v5 Guide some new “Subsidiary Management Plans” were introduced, but I see this as a boost for adaptability not more control or rigor to follow.

The new PMBOK v5 Guide processes:

• 5.1 Plan Scope Management
• 6.1 Plan Schedule Management
• 7.1 Plan Cost Management
• 13.2 Plan Stakeholder Management

These could be interpreted as more Draconian control of how we manage scope, schedule, etc. However I see them as my opportunity to tailor the process and define a more lightweight, adaptive approach.

Since the goal of “5.1 Plan Scope Management” is to “… describe how the project scope will be defined, developed, monitored, controlled, and verified” here is my opportunity to explain that we will be using  a vision statement and prioritized feature list instead of a WBS to better support reprioritization and accommodate changes.

Likewise, the new process “6.1 Plan Schedule Management” is a great place to explain the use of release plans, iteration plans and story maps. In my half-full world, these new processes are there to help us be more agile or whatever we need to be (perhaps more structured for your project) in order to be successful - they support tailoring and specialization.

So, where does this all leave us? Well, I found a way to justify my methodology indifference and explain my disregard for rules or process. Maybe your DiSC profile can help explain your feelings towards these recent methodology debates. Likely if you are more of a DiSC "CS" style you would have a different view and very strong opinions about their importance.  Please let me know what you think.