Agile Otter Blog

Bridging two worlds is not easy. See if you can spot the non-agile assumptions in all of these questions: You find one team is only meeting schedules and pleasing customers because they have been padding schedules and cutting scope. How can you get them to plan and execute more aggressively?  One of your teams is hogging some of the QA resources full-time, and have been since the start of the project. How do you ensure you'll have a full complement of testers for your other team's testing phase?  One of your teams has stopped turning in estimates and long-range plans. They seem to be producing well enough, but how do you reign in their manager without hurting productivity?  Of your two teams, one group works overtime and weekends but the other refuses to stay late even during mid-week days. You have many projects in the pipeline. How do motivate those clock-watchers?  Your team has severe technical problems, but instead of keeping their nose to the grindstone,...

We all have a convenient form of Parkinson's law. "Work expands so as to fill the time available for its completion." People have suggested many reasons for this: People with long schedules are less careful and have more errors to fix. Work seldom is given half-enough time, so it expands rather readily. The longer a project goes on, the more new ideas/features get incorporated into it. If a project goes on long enough, it is punished and slowed by having people added to it. People are lazy and will always slow their pace if not held to task. People are creative enough that they can always find a way to achieve a task faster when required to do so. People will continue polishing and improving the product indefinitely. "Art is never finished; only abandoned." - Da Vinci Of these, the one most commonly heard is the one about people being lazy.  I suppose it might possibly be true if you're painting walls and are being paid by-the-hour, or if...

State of Practice: Scrum I participate in a number of forums where I am happy to help people understand agile methods and practices. I see dozens of question s every week asked (and often answered!) by people who are operating in a system they simply don't understand. For instance, one very well-intended manager called a meeting with HR and consultants and leaders of teams to decide what a scrum master's duties are, and what a PO's duties are. Only the consultant had ever read t he scrum guide ; the rest were going to invent roles to match their current job titles. Not understanding that people can rotate roles (and roles can even evaporate), the HR wanted to make the roles have specific meaning benefit-wise and hire specifically for some of those roles. In an online forum, a manager asked "since release schedules are fixed, how do you make up for slippages in sprints." This belies that the project plan was a big-project plan (BDUF-style) divided into sprint...

The basics are well-known: Everyone knows the basic cycle of TDD. You should also know the improved Industrial Logic version of the TDD cycle . You have heard Uncle Bob's three rules . But there is so much more to know. I have been gathering little sound bites for you which may help you build your skills and knowledge. Please feel free to drop additional factoids or questions. I'm happy to explain any of these at length if you like. Here is my list: Your code has two parts: the part you have covered with TDD, and the part that requires you to use a debugger. Microtests are F.I.R.S.T.   (you cannot TDD after writing the code) Only microtests are appropriate for TDD; other tests are useful, but not for TDD. Microtests are not all your tests - you need other levels of test still.  TDD does not validate your system; it only speeds development and improves quality. TDD without a pair programming partner is like programming while wearing only one shoe. ...

I've gotten into the idea of tech safety when it comes to testing and coding. I get it as a value for deployment, setting up work environments, or practicing. When it comes to TDD-ing, a good editor and a repl and an autotester are like a warm peach cobbler with a dollop of ice cream -- nothing else is quite like it in comfort or enjoyment. But now the game gets serious. Tim starts taking safety seriously now.  I've been photographing and pricing ergo equipment for my home work space. And chairs. I need to be healthier in how I sit and how much I stand. I'm getting some exercise. I'm getting some 'safer' eating habits -- no less adventurous or spicy, but fixing my ratio of veg to starch to meat, which has been somewhat upside down for a while. I need a diet that keeps the brain working, and doesn't damage the body. A stroke would end my career more easily than missing a deadline. I'm intending to monitor my hours of work v. family v. personal ...

Within my company, we're talking about agreements and expectations a lot. Safety in decision-making and action-taking is all caught up in expectations and working agreements, and many of ours have been unspoken, unwritten, and un-negotiated. As a result, it is easy to drop things, expecting others to pick them up when they don't know to do it. It's also to do things that seem to step on your colleague's toes or which work at cross-purposes.  I was doing some work for a very dear client of ours, and I needed to revisit the Debian New Package Maintainer's guide . What appears on page one? A set of working agreements. We all are volunteers. You cannot impose on others what to do. You should be motivated to do things by yourself. Friendly cooperation is the driving force. Your contribution should not overstrain others. Your contribution is valuable only when others appreciate it. Debian is not your school where you get automatic attention of...

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