Tag Archives: Team

Continuous Process Improvement – Doing Less

Posted on by

burn-up2

I’m wary of the cliche’, “doing more with less.”

When I started in my current role, my team consisted a development manager, a product manager, a business analyst, three developers, an outsource/offshore arrangement of 6-18 developers with its own full-time relationship manager and me, a non-individual contributor tech executive. We worked with a product team of three. We built our main US and six other variations over the course of 12-16 months – which was a great success in the eyes of our sponsors.

Five years later, my team consists six developers and me. I have all the same responsibilities but get to code half-time. We still work with a product team of three. When we want to flex, we co-locate two or four contract developers onsite. These contractors rotate through pairing with staff and perform as part of our team.

To characterize this as “doing more” is profoundly mistaken. If you dive into each effort, you’d see we built less and wasted less. Less production code to change and maintain, less beloved but little used features, less idiosyncratic and unnecessarily difficult implementations, less waste in the process of defining and delivering work. Our newer codebase consists of roughly half 65%* of the production code of our old site.

You accomplish more by doing less. I know this sounds very affirmational and non-specific. I’ll describe how we accomplished this in future posts…

Hiring a ruby on rails developer

Posted on by

One of our team is moving on. So we’re looking to hire one full-time, experienced developer.

At Simon & Schuster, we’ve created a small, collaborative team where people can do their best, learn in a collegial environment and get home at a reasonable hour. We work at a sustainable pace because after five years as a Ruby on Rails team we know the value of staying current, refactoring our codebase, and cleaning up tech debt.

We pair, we test drive, we retrospect, and we work as a single team with our product owners. If you want to work on a team that really does these things, contact us.

Scrum/XP/Agile team in midtown Manhattan looking for an experienced Rubyist or experienced Java/C# developer interested in learning Ruby. We are an established, six developer Scrum/XP team. We have a dedicated scrum master and we collaborate closely with our product team…

Apply via StackOverflow

No recruiters, please.

Dear agile consultant – hiring criteria for coaches and mentors

Posted on by

play at your own riskDear consultant who uses “agile” as part of your brand,

I am a possible customer who embraces agile principles, practices agile techniques and has done so for years.

I admire the tenacity and talent it takes to build a business in consulting.

The best of you offer your clients techniques, language and a way of thinking that can better lives and turn around companies: advising them in ways to change their own organizations, bolstering their courage to experiment, helping them learn to iteratively learn, inspiring them to foster teams, empower individual contributors, incrementally improve, and helping them grow past dependency on your services.

Here’s how I judge whether a thought leader is a worthy mentor:

  • Your reputation among those of your peers I know and respect.
  • Do you provide context/share credit: “This is where it originated, this is who popularized or researched it, this is who’s written well on it. This is my version of it.”
  • Do you espouse principles: “This is about defining work that builds equity because it offers real benefit to end users and a way of working that entrusts individual contributors of diverse talents to collaborate within teams to deliver that benefit.”
  • Are you frank: “Most companies who try this fail. Most managers who try this will not change their own behavior enough to allow their teams to succeed for them.”
  • Do you embody the principles: “It is about your team(s). Not me. I do not have right answers only experience, a willingness to listen, and techniques to help us figure out what you need to do to help yourselves.”

Conversely, these are the bad smells:

  • Celebrating the widespread adoption of “Agile” without acknowledging most “agile” adoptions are crap.
  • Celebrating scale not individual team excellence.
  • Focusing on techniques not principles as if “stories” and “iterations” were magic.
  • Talking about software tools before disciplined engineering practice.
  • Talking about “value” and “productivity” as if a leader’s understanding of these terms were not a/the major obstacle to their workers ability to perform.
  • Jamming agile practices into a contradictory way of thinking: “Agile process manager” anyone?
  • Coining new jargon for a slight spin on existing practices: It looks like a timebox, smells like a timebox, tastes like a timebox. “I call it creato-inno-rations™.”
  • Putting yourself above the problem: Just because you were really good when you practiced doesn’t mean you are a brilliant coach. Just because you’re a brilliant coach doesn’t mean you can do my job better than me. Just because you can do my job better than me doesn’t mean paying you to not do my job provides my company value.
  • Overheated claims of personal invention/Not giving credit to others. Sorry guys (and I mean guys), Mary Poppendieck was talking kanban and software development fifteen years ago. You’ve advanced the craft, you’re changing minds, and you may be very good at what you do but you are not Archimedes.

As a potential customer, I need your honest criticism, I am impressed by your ability to learn from others. I respect determination and humility more than bravado.

Give credit where credit is due and do exceptionally well.

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.

The existential joys of agile practice: angel on your shoulder

Posted on by

At Agile NYC I presented a pecha kucha. 20 slides. 20 seconds per slide. This is the fourth and final part.

Angel on your shoulder

play at your own riskAgile values call for honesty and trust. A shared ambition to do better and be better while causing each other less unnecessary pain.

I try to remember this in one on ones, retrospectives, coaching and in reflecting on my own decisions and actions.

The great thing about these values is that even as you strive towards them your co-workers will give you permission to demand more of them.

Just as they will demand more of you.

AngelThis demand gives you an angel on your shoulder. Watching you as you work. It inspires even as it shames you into substantial actions that go against your nature. And you do this because your team needs you to.

You invest in the hard daily work of adjusting your own bad habits one behavior at a time in the interests of the people you work with and the work you do together.

This isn’t easy. It’s mortifying. It’s scary.

TeamBut the reward is that you get to be the same person with your boss that you are with your peers that you are with your staff.

The reward is that you get to work at your best with other people working at their best.

And you carry that potential with you as you move on to other projects and other teams.

Building blocksUltimately, I want more than success on a project or in a particular job. I want a career.

I want to be proud of my accomplishments and I want to be proud of who I was as I attained them.

I want to spend my life loving what I do.

And I want to build things that are useful and delightful to people.

My pecha kucha topic was inspired by Samuel Florman’s book, The Existential Pleasures of Engineering

The main goal has always been to understand the stuff of the universe, to consider problems based on human solution, and to follow through to a finished product.

Existential delight has been the reward every step of the way…

— Samuel C. Florman

The existential joys of agile practice

  1. A family tradition of care and craft
  2. I want to live in our imperfect reality
  3. People over process
  4. Angel on your shoulder