www.thought-bubble.co.uk

This post is from jimhighsmith.com by Jim Highsmith.

In Agile Project Management, I wrote a short section on a performance metric called “shortening the tail.” I liked using the metric, tail length, because it is easy to calculate and tells a lot about an organization’s Agile implementation. It’s not a vanity metric, like the number of developers who have attended a refactoring seminar, but a true learning metric because it focuses on a key tenent of Agile development—running, tested software. It’s also a metric that can help an organization move closer to Continuous Delivery.

The tail is the time period from “code slush” (true code freezes are rare) or “feature freeze” to actual deployment. This is the time period when companies do some or all of the following: beta testing, regression testing, product integration, integration testing, documentation, defect fixing. The worst “tail” I’ve encountered was 18 months—18 months from feature freeze to product release, and most of that time was spent in QA. Routinely I find software companies whose tail is 4–6 months of a 12-month release cycle. Then, there are other companies, and a growing number of software companies, that have honed their processes to a zero tail length—they are truly doing Continuous Delivery and Continuous Deployment. Using the tail length metric, particularly in products or applications that have large legacy code bases , can help organizations monitor their progress towards CD.

Click here to see the full post.

This post is from leadingagile.com by Mike Cottmeyer.

A few weeks ago I agreed to help Brandon Carlson as a reviewer on his Adoption & Transformation stage. Last night I went through about 20 proposals and learned that I think about adoption and transformation significantly different from many of the aspiring speakers. The problem, like many things we talk about, is that these words are overloaded. It seems there is almost a tendency to use adoption and transformation interchangeably… somehow as if adopting agile practices necessarily results in transformation. The insight I had, getting out of bed this morning, is that our use of these words might actually be THE problem. We seem to have equated adoption and transformation when they are really two very different constructs.

Some of the proposals I read last night were about transforming yourself to be more agile. The sessions were about leadership and understanding yourself, letting go and empowering your team members. The supposition was that personal transformation was a necessary precursor to agile software development. Some of the talks were about transforming what we do in our jobs. One proposal was about helping the people doing business analysis learn how to do business analysis on an agile team. My session proposal reflects the perspective that transformation is focused on the larger organization. We need to align our business objectives, management structures, and practices to support agility.

Click here to see the full post.

This post is from allaboutagile.com by Kelly Waters.

I haven’t blogged much about lean development. I’m not an expert on lean, but agile development is a great example of lean thinking in action. So I thought it might be interesting to blog a bit about lean software development, and how I see it…

Before you can really put anything into practice, I think it’s important first to understand the key principles.

Click here to see the full post.

This post is from lassekoskela.com by Lasse Koskela

I’m sitting in the hallway in Limerick, Ireland, attending the XP2008 conference, downloading something from the company server to my laptop, eavesdropping on an open space session hosted by J.B.. He’s talking about user stories and roughly 4 minutes ago he mentioned he’s got a blog post up on his website that shows an example of four ways to split a story.

Since I’m so Web 2.0, I’m blogging about this while they’re having their open space session two meters from where I’m sitting. I tried to be Web 2.0 and blog this while they were running their open space session but I’m so darn slow and old school that it took me 2 days to get this written! Hardly enough to blog about it as it happens. I should’ve recorded a podcast, I guess.

Click  here to see the full post

This post is from allaboutagile.com by Kelly Waters.

In my series of posts “How to Implement Scrum in 10 Easy Steps“, I refer to two stages of estimating:

Click here to see the full post.

This post is from mountaingoatsoftware.com by Mike Cohn.

Agile teamwork can really help to minimize handoffs. Teams using a sequential development process have become accustomed to handoffs between specialists. Analysts hand their work to designers, who hand it to programmers, who pass it on to testers. Teams that are new to Scrum often do not go far enough in eliminating these handoffs, wrongly assuming, for instance, that the programmers should finish programming a product backlog item before handing it off to the testers or that analysts should work at least one sprint ahead of the rest of the team.

High-performing Scrum teams, however, have learned to do a little bit of everything all the time during a sprint, thereby eliminating large handoffs. To do this effectively, scrum teams must make three changes: favor talking over writing, make handoffs very small and very often, and mix the size of items that are brought into each sprint.

Click here to see the full post.

This post is from mountaingoatsoftware.com by Mike Cohn.

Self-organization is a fundamental concept in agile project management. The Agile Manifesto includes the principle, “The best architectures, requirements, and designs emerge from self-organizing teams.” Yet a common misconception about agile project management approaches is that because of this reliance on self-organizing teams, there is little or no role for leaders of agile teams. Nothing could be further from the truth. In The Biology of Business, Philip Anderson refutes this mistaken assumption:

Self-organization does not mean that workers instead of managers engineer an organization design. It does not mean letting people do whatever they want to do. It means that management commits to guiding the evolution of behaviors that emerge from the interaction of independent agents instead of specifying in advance what effective behavior is.

Self-organizing teams are not free from management control. Management chooses for them what product to build or often chooses who will work on their project, but they are nonetheless self-organizing. Neither are they free from influence. Early references to Scrum were clear about this. In“The New New Product Development Game” from 1986, Takeuchi and Nonaka write that “subtle control is also consistent with the self-organizing character of project teams.” An agile or Scrum team’s job is to self-organize around the challenges, and within the boundaries and constraints, put in place by management. Management’s job is to come up with appropriate challenges and remove impediments to self-organization. That being said, the fewer constraints or controls put on a team, the better. If leaders overly constrain how an agile team solves the challenge given to it, self-organization will not occur. The team will shut down; because it has already been told so much about the challenge and how to solve it, it will wait to hear the rest.

Click here to see the full post.