Agile Otter Blog

What the heck does that mean? It's a simple statement of personal preferences, right?   "I like bananas more than lemons." "I think today I'd rather have tamales than gyros." What power could there possibly be in stating that you like some things more than other things? Heck, these things are not even opposites. Look at the first one -- don't processes and tools exist to help individuals interact? Try the second one -- what about "writing documentation" would keep software from working? Okay, the last two have some real conflict, but that's 1/2 of the preferences listed. What DOES it Mean? My reading of this document and interactions with some of the originators has long led me to believe that this is truly a powerful document.  It goes well beyond personal beliefs and preferences.  What I see listed in the four simple category statements is a powerful set of decision-making criteria. If left-side items and righ...

Ashok Singh, in a post on Linked In, spoke deep wisdom in these words ...when people are not able to solve organizational problems, they come down to tweaking the framework to accommodate the dysfunctions.  I dub it Singh's Inevitable Avoidance Principle. Let it be noted. A Little Context The forum question where Ashok Singh uttered the IAP was answering the question "Why do we have sprints instead of just working one story to completion at a time?" A great question. Why, indeed? Working on one item at a time requires teamwork, as indeed all Agile methods are intended to do. But working on groups of features is more palatable because people can divide up the work individually and defer learning how to deliver as a team. Giving up the "solo ninja programmer" is hard for some people, as frankly most of us are introverts and a few are genuinely anti-social. If your team is full of people who hate working together, they'll want at least one task ava...

I'm not the first to ask this, but here is a suggestion: Let's end the nonsense of straw man arguments in agile discussions. I heard it again today: "I don't see Agile as a silver bullet for all software development problems in the world."  Of course you don't. Nor do the people you're arguing with/against. Nobody believes that switching to XP or Scrum will make everything trivially easy and prevent every kind of design issue or organizational dynamic or schedule interruption possible. I think we can drop that rhetorical device now. Next steps when most people use that device tend to be: * reject the insufficient miracle ("if it doesn't do everything, we shouldn't use it") * take a piecemeal view ("if it is not everything, then integrity of the parts is unimportant") * use it to declare their superiority ("I am not the fool that you are") Let's not understate the depth and integrity and value of a ...

The Product Owner is responsible for maximizing the value of the work done. Check out this list of responsibilities from the Scrum Guide (2013) : Clearly expressing Product Backlog items; Ordering the items in the Product Backlog to best achieve goals and missions; Optimizing the value of the work the Development Team performs; Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and, Ensuring the Development Team understands items in the Product Backlog to the level needed.  Optimizing value is a funny thing to think about when does "value" even mean?   To an industrial-age mindset, "Value" correlates to "Output."  If I make seventeen yachts, I have more to sell, and then potentially make more money than if I have three.  If I have twenty features...

One of the tasks I gave out at my Bootcamp Track talk at Agile2015 was to design a workspace better than the one your team currently has. I received more than one answer, and thought I'd share them here. One list was about how to make a more productive space. The answer was this short list: All workstations in one room White boards and writing utensils Post-it Notes Videoconferencing Tools Proper & available hardware for testing and experimenting. These seem like very small things to ask. Well, the hardware might be tougher depending on the application, but a lot of organizations use cloud servers these days so it's more about budgeting than acquisition. Everyone sitting together is a topic I want to address in a separate post, but I want to call out that being located near the people you're actually working with is a great advantage, as is being located away from people you aren't actually sharing work with. 'Nuff said. A lot of us work in distr...

The things that pre-agile managers know about managing software mostly comes from contractors and consultants. In the old days, military/government contractors were the gods of management.  They had huge development staffs, rigorous procedures, colossal budgets. Those where the people to watch. Everyone wanted those staffs, those projects, those budgets. QA and Development were split. Development was owned by the contractor, and QA by the customer. Sometimes the contractor had their own QA people to help assure that their product would pass the customer QA process. The customer's QA was focused on proving that the contractor had not finished the project, and so they don't need to be paid yet. The goal was to PREVENT COMPLETION of the contract and delivery of the code. The contractor's developers and testers argued that they did indeed fulfill the terms of the contract and should be paid post-haste. Of course it was important that the contractor/developers did...

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

I would rather work with physical tools than online, but frankly my own team is highly distributed and so we sometimes need to be able to visualize and communicate our work. Rather than complain about how awful all the online tools are (and how badly wrong default configurations are) let me describe what I really want: Backlogs Backlogs are about 80% nonsense. I don't plan all the work I'm going to do. We have found that we are better off if we just do the most important slice of a thing today and get it live, rather than plan how long "the whole thing" would take. We are frugal with our time and investment, and frankly our features need to be validated in production or we don't know that they are really good ideas at all. Don't treat our backlogs as promises and commitments. They're just a waiting list of things that we might want to do sometime. It should be easy to add/remove. By the way, you should probably warn us if we have a lot of thing...