Agile Otter Blog

The question asked was "how do we know we need a coach?" The more general question is "how do we know if we need help?" The question seems to assume that the goal of coaching and training are rescue; that the team is in trouble or incapable of success. That's horsefeathers. I think that the more valid question is "are we working as well as we can?" Here are my criteria for teams that don't need anything: We deliver Delivering software keeps getting easier We are always learning We have fun If all four of those are true for a team, then that team probably doesn't need help. Of course if those are true, then the team is poised to provide a lot of help to other teams by describing how they work.

Agile's teaching of "thin, vertical slices" doesn't apply just to features. Organizations move forward in thin vertical slices too. Story mapping teaches us to do incremental, value-first programming and integrate the "threads of functions" all the time from end-to-end.  CI teaches us that integrating thin slices frequently avoids pre-release integration nightmares (and post-release nightmares).  Likewise, we leave room for learning and growing, because what we learn in iteration N may give us different options and opportunities in iteration N+1 and onward. We have an idea of where we want to go, but we are always seeking best value. However, too few agile transitions are done in an agile way. It's only reasonable that a pre-agile company would want a waterfall, Big-Design-Up-Front plan with staffing and milestones for an agile transition. But we, as post-transition coaches and consultants know better and are supposed to be ...

Here is Christopher Avery shows us a mental model that will help us to become more responsible. I found it concise and helpful. I hope you may also.

This is not a manifesto. It looks a lot like a rather famous manifesto (the middle of it anyway) but it is not a manifesto. This is just a set of principles that I've successfully applied in numerous personal and professional settings, always with good effect. Pull  is a better flow than Push Continuous is more competent than Batch Agreements are more negotiable than Orders Brains per Task  is more efficient than Tasks per Person Improvement is a better goal than Compliance Fail Now is cheaper than Fail Later Simplicity works better than Discipline Safety is best May they serve you as well as they have served me so far. Peace.

Note: this was originally all plain text and a little shorter.  As more people have joined the conversation, and other supportive materials have come to mind, it is growing links and a little verbiage but this is only to support the idea: we don't have to settle for expediently cranking out horrible work between pointless meetings. We can do better.  Are we getting tired of the kind of "agile" where you don't really have any particular technical practices, change (and improvement) is entirely optional, and you pretty much do waterfall with additional overhead of meetings? Are we tired of seeing "sprints" and "iterations" used as ways to pressure people into working harder and longer (" pushing velocity "), with no training or learning or even autonomy? Are n-week death marches the ultimate expression of our values? Are we tired of the kind of "agile" that's all about buzzword compliance and rituals and motivationa...