Agile Otter Blog

I was speaking with my friend Bryan who, like myself, does a lot of work with very large organizations. Many of them are great places and have sincere interest in being wonderful places to work with wonderful people. Sometimes, though, they struggle. In considering the nature of their struggles, I realized that I've collected or formed some observations of dynamics and I've not really vetted them all publically. I'd like to take this moment to think out loud and, with kindness and curiosity and empathy, see if we can develop and refine these observations -- or possibly strike them entirely if they seem utterly false. Please join me via comments or emails (tottinge@gmail.com or tottinge@industriallogic.com) to let me know what you think about these observations, what I'm missing, and what I can do to fill out the set better. Just remember, this is about curiosity and systems -- I'm not here to tear anyone down. Dunbar's Number Researcher Dunbar notic...

Consider that everyone has in their mind a fuzzy line: On the left side of the line is what we like to call "the real work" (abbreviation: RW). It's what we get to do . It's the value we provide to the world. It is usually about 30-40% of the work we do, which pays homage to Gall's observation about the inefficiency of human systems. The stuff to the right of the line is what we call "bureaucratic silliness" (abbreviation: BS).  It is the stuff we have to do.  These are things we do out of obligation (when reminded), or to satisfy the internal "process police." These things feel like nonsense that we have to deal with because that's the price of being a developer, tester, manager, whatever we consider ourselves to be. The Difference We tend to take on Real Work happily and go right to it. It allows us to practice and pursue the skills that define who we are in the workplace. They further the goals of the company, the customer, a...

My friend and colleague Curtis Cooley recently blogged " You Might Have Too Many Developers ." Overall, I agree that smaller teams move more quickly and swarm more effectively on task than large ones seem to, and that there is definite overhead with large groups. You already know some developers are more effective than others.   What if you could find 1000 within the 2000 that collectively are twice as effective as the other 1000? Joel Spolsky has claimed the best programmers can be as much as 10 times more effective than the worst programmers. The argument continues describing how many developers are much better than others, and are better in a smaller group than they can be when they are encumbered by less competent programmers. I also agree that smaller teams of more expert programmers make sense on many levels and represent a savings in frustration, cost, and time.   As Red Adair would say : "If you think it's expensive to hire a professional ...

The story says "attach an e-commerce server." Well, maybe it says "As a product manager I want my system to incorporate an ecommerce server so that I can collect money." Can you get that done this iteration? It sounds like a three-story-point effort to me, right? Hold On A Second This story doesn't have a plot. It is a state of being. I don't think that  saying "once upon a time there was a little girl" would qualify me as a story teller.  Right away I'm nervous. What the heck does it mean? What do we want to do here?  Let's not throw this into the sprint backlog with (of all things) a story point number on it. Let's certainly not stick somebody's name on it. Let's think a little.  We're not aligned on what this "story" means.  The New Preplanning Poker You already know about planning poker , and the benefits of silently estimating first, then comparing results. You know that it helps av...

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

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.

I'm not a big scrum promoter, but I am VERY familiar with scrum and have coached many teams and always been able to improve their success with the method to some extent. I've taught scrum. I don't have to love scrum (not more than XP for certain!) to see that it's getting a bad rap. Ignoring advice to "never blog angry" I'm going to let the grumpy old man out for a minute, in hopes you'll hear what he has to say.  Suggestion:  Before railing on how scrum doesn't work  you should be sure that what you're doing is scrum. Some people say they're doing scrum because they have planning meetings, morning status meetings, and sometimes have reviews or retrospectives. But they're not sure why they're doing them, and these meetings just take time away from what would otherwise be potentially productive programming and testing time. So, let's get back to the basics here. Scrum is entirely based on transparency , inspection , a...