Tag Archives: Agile Management

Managing self-organizing teams in an Agile Software Development practice is about encouraging and allowing developers to embody values of collaboration, creativity, quality, integrity, and individual initiative in an environment that provides sustainable pace and opportunities for personal development.

Hyperproductive? I don’t know but I’ll take it.

Posted on by

I’ve written about how our agile practice, particularly continuous improvement, has re-organized our product and development group into one, high performing team. How this has resulted in less code, less waste, higher quality and more value.

Jeff Sutherland talks about mature, agile teams achieving what he calls hyperproductivity. At this point, the team output accelerates and they outpace the organization around them.

annotated-burnup

Performing beyond even our own expectations allows us slack to help our product team and our sponsors define the work we do. As a matter of fact, last week, the dev team accounted for 9 of 15 stories in our backlog including 5 consumer facing additions or changes. Our sponsors have so much trust in both our ability to deliver work and our judgement that we have top down support behind the kinds of necessary efforts companies find hard to justify like platform and framework upgrades.

It is a virtuous circle, performance allows slack, slack allows time for reaching outside the immediate task to understand and optimize work for the next week, to keep up with our training and industry, to get out of the room and talk to the business, to imagine new features, to identify and solve problems.

Team members are allowed an opportunity to express their individual talents and interests: one developer can bring in a prototype of an entirely new implementation of our website, another can research and improve our search engine rank. All while working as a single collocated team that pair programs with daily pair rotation through a weekly iteration cycle and a shared backlog.

It is a synthesis of contradictions: deliver features and create less code, remove interruptions and make time out of the team room, strive for collective ownership and individual autonomy.

It results after years of dedicated practice in the techniques of Extreme Programming: pair programming, test driving, collective ownership, refactoring, iterative delivery — and determined Scrum project management: impediment removing, iterative delivery, retrospection, adapting our organization, earning trust, and protecting the team so that they could get their work done. A team is an organism that needs to close inwards, build strength and discipline before it can open up and expand outwards.

It’s the second time I’ve been a part of a team that’s reached this level of performance and both times it’s taken years to get there. I’ll take it.

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…

Agile software development and “value”

Posted on by

Release BurndownAs advocates of agile software development we focus on practices.

The hype on those practices is they produce software, “faster, cheaper, better.” And we sell our efforts with the promise of, “delivering value.”

We speak of value as if the definition is shared, self-evident, contained within our backlogs and measured by our burn ups.

At the same time we minimize the hard and long the struggle to achieve mastery, identify and address a material need, and sustain creativity and quality.

So, we win the opportunity to labor with our teams to incrementally deliver potentially shippable units of code to stated business priorities.

When those priorities are pointless, so is the software.

When those priorities are tactical and subjective, the values behind agile practice — sustainable effort, maintainable code, self-directed teams, collaboration and trust — become irrelevant.

The truth is there are definitions of “value” that sell us out whether or not material success accrues to someone as a result of the software development effort.

And so, an agile adoption that is true to its participants is an ongoing, perhaps excruciatingly gradual, but substantive conversation with the larger organization on the definition of value.

A set of practices is only companion to the human values that give our work meaning.

Oops… learning lessons over and over

Posted on by

Here are agile software development mistakes that kick my ass whenever I let them:

  • Know the assumptions in plans. Recognize when they change.
  • Don’t abuse time boxing. It is a toe hold for over-committing. When the time box ends, the work ends.
  • Doing Scrum means DOING SCRUM. Sloppy backlog. No Scrum. No Product Owner. No Scrum.
  • No iteration boundaries and no commitment doesn’t make me “lean”.