Tag Archives: collaboration

Our weekly rhythm (iterations)

Posted on by

clock

(Clock image by simpologist on Flickr)

Establishing a rhythm to our weeks and days has provided our team a sustainable pattern for predictably delivering work with quality. Our performance is an outcome of executing within this pattern repeatedly over time.

I learned the concept of a team rhythm from Jeff Sutherland and ours is a scrum and has the shape of a game: a short time frame (one week), an achievable goal that constitutes “winning”, alternating periods of focused team work with opportunities to regroup, strategize and rest.

Rolling Planning

Each day after stand up, as needed, the developers and product people have a 30-45 min. conversation to co-author, clarify, scope and estimate stories for next week. The narrative of the story is not as important as that we have discussed it as a group and that it has mutually understood acceptance criteria.

By Thursday, the product people have force ranked next week’s work reviewed the work and ranking with our sponsor, the Chief Digital Officer.

Do we need to estimate stories? That depends on whether the conversation over the estimate adds focus to the conversation over the scope and acceptance criteria of the story, surfaces risks, raises alternatives. It also depends on whether estimates affect when or whether a story is played or how it gets prioritized. It also depends on whether your team makes an iteration commitment.

We estimate.

Commitment

On Monday morning, the team is ready to decide how far down that list of work we are confident we will complete this week. We usually start and complete additional work during the week but this is the floor.

Is the commitment necessary? It is a definitional practice in Scrum but the answer depends on whether anyone considers achieving the commitment a meaningful measure of success. It also depends on whether the conversation over what is or is not in that commitment will affect what the team is asked to work on and what gets delivered at the end of the week.

For us, the fact of a commitment helps maintain trust with our sponsor, the product people like the ability to make commitments to others with assurance we have their back, it helps the team work opportunistically on the backlog — to self-organize around the work and pull stories in a way they believe will lead to the best outcome that week while still having a reminder of which stories need to get done. So, we have a commitment.

Showcase

As a department, we hold a a 30 min. showcase where the product team and two developers present the work we delivered the prior week. That bleeds into another 60 minutes of roadmap conversations which the developers are free to duck out of at their discretion depending on the relevance.

This showcase cycles in and out of being a meaningful exercise for the developers themselves but it continues to be a useful touchpoint with the rest of our department. Whether the developers find the following roadmap discussion useful is the degree to which they feel a need to get in sync with our department goals and how our work feeds into those goals. It also depends on how well that meeting addresses that need — which varies.

Retrospect

Having made our commitment for this week, we hold a 30 minute retrospective with the product people and developers. A developer usually facilitates.

This is one of the most important tasks in our week and yet it is also the one practice we control that needs most improvement. We need to do a better job and focusing in on root causes of both what is going well and what is not. We need to do a better job of identifying concrete things we should do in response. We need to do a better job of holding ourselves accountable for doing things and observing whether they actually help.

Deploy

We deploy on Mondays. We do more as needed. We have a theoretical one touch deploy but the reality of our environment is Zombie Unicorns that sometimes wont die and so we are not yet at a point where we deploy without hesitation. We are working on our environment with our hosting provider to get past this.

Though the reality is, we find a balance point between frequency of deploys and branch management. A single weekly deployment has the advantage of allowing us a 1-2 day lag between QA’d and signed off without requiring us to maintain a rolling production deploy branch. We usually can simply deploy master. More frequent deploys would require either a more just in time sign off or a disciplined practice that connects sign off to which features are merged into/turned on in the deploy branch.

Pairing

After Monday, each day follows a rhythm: morning standup with product (15 min.), the product planning time (30-45min.), morning pair session (2.5 hours), lunch and personal work time (1.5 hours), dev team check in (15min.), afternoon pair session (3.5 hours)

The afternoon check in is something the developers themselves started that functions as part standup, part opportunity to share something they learned that morning or a problem they ran into. It also is a second opportunity in the day to rotate pairs if it makes sense.

Kaizen

One of the downsides of a joint product/dev retro is that many of the issues the developers want to discuss aren’t relevant to the product team. So, the developers themselves started holding a Kaizen at the end of the week, while things are still fresh, to share and improve our development practices and code quality.

Because the Kaizen arose from the team itself and is more focused in scope, it tends to work better than our retros.

Conclusion

So, this is how our week falls out. It is what we as a group have arrived at over time and it is continually evolving. New obstacles or constraints may drive new practices. Practices that were a solution to a specific problem can remain like vestigial limbs long after the problem has ceased to exist and need to be discontinued.

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…

Negative perceptions about software development. Do you have a solution?

Posted on by

Feedback on my proposed session at Agile 2012 on whether principled Agile practice is capable of creating workplaces and an industry more inviting of women software developers…

I could not agree more. There are many negative perceptions about software development these day in the US (off-shoring, hostile env, long hours, …). As a result, my friends at North Carolina State University tell me that overall CS enrollment is down. There was a similar event in Japan with the creation of the “Software Factory” in early 80s. I believe that they almost decimated their software industry. But how do we solve this? It has to start early as the career begins way before their first job. Leadership? If we want to maintain the industry, you bet.

Agile thought leaders came together in the first place to challenge the rest of us to empower individual contributors, elevate the role of craft and quality, cultivate collaborative ways of working, and create better, more valuable software products.

Following their lead, principled Agile practice is a determined process of honest observation and incremental improvement. It is dedicated, courageous advocacy for removing obstacles — an effort supported by analytics and a track record of improved performance.

The ambitions of this change don’t stop at a team or a set of engineering practices (though those are hard enough to accomplish). It is a change program within an organization.

We should see our mission is aligned with creating a software workplace and definition of the software developer inviting to articulate people, with diverse interests and points of views, who reflect our actual end users, and who want careers that have meaning and purpose.

I’ve never participated an agile adoption that didn’t ultimately set its sites on the larger company, the products that organization is building and why it is building them. I’ve never been part of a prolonged and dedicated agile adoption that didn’t bring developers closer to creative people outside the team, that didn’t make work a more rewarding place to show up each day.

Agile practitioners need to battle workplace cultures that discourage women and other talented people from entering and remaining in our field one dysfunction, one bully, one obstacle at a time, in one workplace at a time, because they are obstacles to collaboration and trust, disempower and burn out talented individual contributors, and distance us from our customers and end users.

I’m not saying this happens everywhere or that the changes are permanent. Widespread adoption brings with it mixed and often disappointing results. But enough of us need to drive for this change in enough of our shops, enough of the time that Agile remains a path to excellence for those of us capable of striving after it.

And by doing this we will create enough change to influence the rest of the industry. Agile adoption itself is an example of this kind of change.

Does this effort provide a clear path to success? Clearly not.

But is this approach capable of driving large and dramatic changes in companies and our industry? Yes.

The existential joy of retrospection (agile practice)

Posted on by

Spiral JettyEvery two weeks as part of our Scrum practice my team holds a retrospective to ask:

  • what were our goals in the last two weeks,
  • what did we do that helped us achieve those goals,
  • what did we do that got in our way, and
  • what essential set of things we should we keep doing or do differently.

Retrospection is a process focused way of doing more and more of the things that are important and a less and less of the things that are not important.

And our efforts at inspecting and adapting are themselves a work in progress.

We need to rely on each others’ strengths to work past our own weaknesses.

We need to expect more of each other and to demand more of ourselves for each others’ sake.

We thread this path to trust and loyalty, to collaboration and self-knowledge, to craft and achievement.

Ruining it for the rest of us

Posted on by

A December episode of This American Life starts with an interview with Will Felps.

He placed college students on teams with an actor alternately playing a “jerk, slacker, and depressive”.

The “bad apple” not only wrecked the team’s performance, the other members began to think and act like him.

Here’s a Google book preview of Will Felps’ paper, How, When and Why Bad Apples Spoil the Barrel: Negative Group Members and Dysfunctional Groups