Tag Archives: agile adoption

The limits of advice – outside experts and your agile adoption

Posted on by

It takes something near wisdom to pinpoint the obstacles in your workplace.

By achieving this, you evidence rare concern to improve the work life of peers and improve their work products in ways your organization may not yet appreciate.

But having articulated a problem, you will often find no clear solution or an answer that is obvious but painful.

So you look to others for advice: peers, coaches, and thought leaders.

Don’t be surprised if the advice is unsatisfying. But this is no surprise.

Your challenges may look like a thousand examples but they are uniquely your own. At their root, they source from the people who make up your organization. People with a unique set of preconceptions, decisions, and values systems.

More essentially, you are a unique set of experiences, relationships, strengths and weaknesses and you are the essential agent for tackling this problem.

Be wary of any advice that doesn’t acknowledge this — that fails a test of respect and humility. No outside expert truly understands your situation or is deeply invested in solving it for you.

The best you can come away with is things to try, things to research, new questions to ask, analogies, fellowship and most importantly hope to persevere.

A worthy coach or advisor must approach your situation with patience and empathy. Listen and question as much as advise. Not fill the void of an answer with tangential descriptions of practice. Not pretend an answer that celebrates their abilities more than embraces your circumstances, “What you need to do…”

If you get the sense the coach or advisor is failing to listen or speaking more out of their own needs. Gleen what you can. Thank them. Move on.

But keep trying.

Don’t let the failings of the people in our community discourage you or diminish you. They are just peers with a different context. They are human too. And they are not you.

Agile, Scrum and 4DX

Posted on by

Our company is adopting a practice called “The 4 Disciplines of Execution” (4DX). Superficially, it’s goals and techniques are very Scrum-like with a focus on rallying self-directed teams toward a single, important company goal.

Team Scoreboard

Layout of our combined Scrum/4DX team scoreboard

Like Agile, it champions practices but emphasizes values that give those practices reasons for being. 4DX is more focused on outcomes than specifics of performance – which is a nice puzzle piece to slot along side into a lean or XP discipline.

I’m fascinated to watch the course of a top down process change. I’m also wary of what happens when groups that don’t feel an urgent need for change or share the values of team, collaboration, and focus bang their heads into this particular demand.

Still, I am hopeful and excited. After a few years at my company once again championing a team-up Agile adoption, I feel tremors as the rest of the company shifts to meet us.

Part of being lucky is being ready.

An outlier to the outliers, observations of an agile practitioner at an academic conference

Posted on by

Molokini viewed from the Grand Wailea HotelI presented my paper “Agile Values, Innovation, and the Shortage of Women Developers” at the Hawaii International Conference on System Sciences #45 (HICSS) on Thursday, January 5th. I’ll publish out my presentation notes in this blog over the next week. I’ll also link to the published paper when it is available on the IEEE website.

A puzzling experience

I’ve presented papers at HICSS before. Mostly in the Agile track chaired by Jeff Sutherland. I did present once in a more purely academic Ethics track.

In this case, HICSS had two “Agile” tracks. And the one I submitted to was actually not Jeff’s track. Kind of amusing. But also kind of NOT as the real reward of this conference has been the mix of educators and practitioners. By having two tracks, HICSS split the audience. I was in an academic track with an academic audience.

I am a digression

As the whole topic of Agile is a minor footnote at this conference, I found myself an outlier to the outliers. Or as the chair of my mini-track at this conference called my paper, “a digression”.

I will admit it. My paper is a digression. It was off topic here. It would be off topic at a professional Agile conference. That doesn’t make it irrelevant and I’m grateful for the reviewers who allowed it into the conference and the people who attended my talk.

It is about what our industry and our peers do to discourage and drive away women from software development and how Agile values can help practitioners find the courage and focus to fight this. Like I said, I’ll start publishing out my notes this week.

Just another process

I should have realized I wasn’t proposing into Jeff’s mini-track just based on the title: “Agile Software Engineering“.

Just the use of the word Engineering will inflame the passions of many very good Agile practitioners. I am not one of them. I understand “craftsperson” and “engineer” are freighted concepts. But I am the son of an Engineer and spent over ten years working in theater while becoming a paid software developer. I know that both terms imply a love of disciplined execution, a dedication to excellence, a sense of personal responsibility, and a society of peers.

However, in this case the phrase Agile Software Engineering spoke to an overall tone of the day I’d summarize as, “Really, agile isn’t so different from everything else. It’s just a process framework. Just some practices that apply in some cases and don’t apply in others. A good developer will do good work in spite of the process they use.”

The heart of my concern

This is entirely true if you focus on the practices but this characterization of the Agile movement gets to the heart of my concerns about widespread Agile adoption. Agile adoption isn’t about the practices. It’s about the principles behind the practices.

If you don’t have those values instilled into your team and aren’t working incrementally to install those values into your organization. You can call yourself agile but don’t characterize your understanding of what that means as the sum total of what Agile practice represents.

I don’t claim “Agile” is the one answer

It is clearly possible to build a team oriented, collaborative organization without calling your values, Agile.

It is also possible to get through life without wanting to work on a team or to collaborate with anyone. Not every software professional can or wants to embrace these values or would be successful if they tried. And you can build decent software in such a work place.

I also know there are now a plethora of shops that promote their “agile” process that wouldn’t acknowledge an Agile principle if it stood in front of them naked. They don’t give a rat’s ass about their coders — they consider team formation an org chart decision and wouldn’t tolerate self-organization for a second.

My path

But I know after years of hard won experience that Agile principles are my path to an empowered, humane workplace capable of producing work I am proud of that delivers for the business and addresses the needs of end users without exploiting and disposing of talented individual contributors along the way.

So, yes, some agile practices may be a prescription that can be applied selectively. But “Agile” as in the set of values I go to work with each day and come home with each night? That is me. Not my toolbox.

Earning trust (agile adoption)

Posted on by

yellow rope with knotIn order to adopt agile practices in any meaningful way, you have to change your organization.

This includes the members of the team, the people who describe and prioritize work, and the executives who hold everyone accountable for the outcome.

In order to drive that kind of change, you need authority commensurate with your responsibilities.

But you also need influence with people over whom you have no authority. Who may, in fact, have authority over you.

The best path to this is integrity. Be the same person in all contexts. Accomplish things for people. Keep your word.

Never assume you’re entitled to trust. Earn it. Work toward a shared definition of success and continue to earn trust as you progress through your change program.

Focus on cross-organizational dynamics, pathologies and development (agile adoption)

Posted on by

I agree with the conclusion of israelgat’s post on Agile Manager, Persona of the Agile Team:

If the spread of Agile in your company has stalled, providing qualitative and quantitative data on the benefits of Agile might not be the best way to win over support for broader adoption. Instead of hard sell of Agile benefits, focus on cross-organizational dynamics, pathologies and development.