Posts

Showing posts with the label learning

Your Transition Isn't Very Agile

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 ...

Bug Teams v. The Nature Of Defects

How it Happens You realize that you're not getting as much done as you expected to get done. It's troublesome because you have plans and promises and releases to deal with. You're likely to end up the scapegoat when your behind-ness snowballs into a large organization-wide issue. You also have quality problems. Your team leads estimate that the teams are spending 70% of their effort on defect-fixing activities.  It dawns on you that you can get back 70% of the productivity of your team if you can spin up a separate team to handle bugs! Now one team can be 100% dedicated to adding new functionality without being encumbered by bug-fixing work.  After months, you find that the defect density has not improved from your effort. You see a ramp-up in the number of defects fixed per month as the bug team's diagnostic and corrective skills improve, but they are still lucky to hold even against the tide of defect injection. Why doesn't this work? What has g...

The Interplay of Failure, Learning, and Options

We talk about failures a lot. Fail Fast! Safe to Fail! Learn from Failure! One would think that  people hire us to screw things up. Why the fascination with failures? Why not talk about successes? Admittedly, the dialog is off-base a bit. We're not really keen on failure at all. We don't like to be wrong, and would hesitate to ship a product if we knew it was the wrong thing to build, or it was built in the wrong way. There are problems that can be solved without error by one person who thinks about them for a little while and types in the code that solves the problem.  The term for this kind of problem is  uninteresting problems.  These problems are smaller than one brain, or else the solution is already well-known. We tend to either shuffle this problems off on the noobies, or else we scribble down the answer and move on without any real sense of accomplishment. Any problem that is interesting will involve experimentation and learning. Those problems cy...

The Power of an Agile Mindset

Image
Linda takes us from a negative to a positive affective style, from a posture of seeming or being to one of becoming.  There is just so much to know and understand here. If you don't already love Linda Rising, you surely will after this. Notice the tie-in to Seeming v. Being v. Becoming . Mine is derivative, of course.

Pairing, Competence, and Recognition

It's a common thread in agile transitions that people are not sure what pairing, teamwork, and self-organization will do to their status on the team. Will the team be so leveled that nobody will stand out? Will the weak be exposed and humiliated? I am going to write this as if there were two states, strong and weak. Before reading anything that follows, remember that everyone is good in some areas and weaker in others. I have seen javascript gurus who weren't very database-smart, and people who were great with requirements and product knowledge but had no sense of scalability or performance. Any human characteristics are spectra, not point measurements. With that in always in mind, read on: There is good news, more good news, and some hard and potentially sad news in all of this. The first bit of good news is that nobody who works in an agile team ever asks these questions. In reality, it's not a problem. Let's get down to cases. Rockstars If you are the rock s...