When the sound of the ship’s bell blared through the office, all employees immediately got together for a 10-minute celebration. Our people knew that the bell was often a signal for free cake or cookies, which probably contributed to the quick and easy gathering of the entire work force around the coffee machine.
This is the final issue of James Brett‘s 5 Questions. Issue 1 featured Ron Jefferies, Issue 2 featured Ken Schwaber, and Issue 3 featured Mike Cohn. In issue 4 of the five questions series we hear from Alistair Cockburn.
Even Phil, the Groundhog, screwed up with his estimate, and while the spring is already far in, it’s high time to come up with a very fitting narrative of what missed deadlines, and deadlines in general, are about.
If you’re interested in techniques for estimation, you should take a look at this pdf ebook. It contains half-a-dozen essays on estimating in agile projects, drawn from our experiences with a wide range of clients. We explain approaches based on story points and on story counting, which should give you a good overview for you to explore an approach that will work for you.
This is the third issue of James Brett‘s 5 Questions. Issue 1 featured Ron Jefferies, and Issue 2 featured Ken Schwaber. From the first issue of 5 Questions ”The ideas was to ask five specific questions to members of the Scrum community and post the their replies.”
Take a fresh look at problems, don’t go through your mental catalog of past problems. Each problem is unique and it has its own set of unique solutions. You might surprise yourself, with what you come up with.
In many working environments people’s focus is usually is on fixing problems. This makes sense, because continuous improvement allows organizations to survive and thrive.
If you look up Test First on Wikipedia you will be redirected to the Test Driven Development (TDD) page and I believe this to be incorrect. While TDD is one, arguably the most effective, form of Test First it is by no means the whole thing.
Out of all of the agile practices which have been adopted in recent years, few have proven more controversial than estimation. To estimate, or not to estimate? That is the question. In this article we look at the reasons for disagreement and the circumstances in which estimation can make sense.
I’m using my kanban to help me to get to done on my tasks, not to track my every piece of work. I’m using it to not forget work. I have a couple of phone calls this morning and a phone call this afternoon. I hope to complete one of the workshops today. Maybe.
People usually think of the pawns as the most disposable pieces, but great managers don’t use them as strategic sacrificial lambs for their own gain. Trying to keep all the pieces on the board becomes an unacknowledged and thankless part of the manager’s job.
The Oxford Dictionary defines an assumption as: “a thing that is accepted as true or as certain to happen, without proof”. We constantly make assumptions. Sometimes we are aware of them, often we’re not.
I’ve been busy crossing work off my list. And, as with all of us busy people, I’m adding more work to my list. I feel as if I’ve accomplished a lot this week.
The Dependency Inversion Principle (DIP) has been around since the early '90s, even so it seems easy to forget in the middle of solving a problem. After a few definitions, I'll present a number of applications of the DIP I've personally used on real projects so you'll have some examples from which to form your own conclusions.
The biggest waste in software is what we build and isn’t used. Since we can’t know in advance what will be a selling feature, we have to implement the feature, put it in the wild, and hope for the best.
I use a form of personal kanban inside one-week iterations to finish my work and notice what I am not doing. I do this to maintain a cadence of blogging and to finish work. Did you notice that word, finish?
UX-led development is where your User eXperience (UX) developers are active within a dev-team, pushing the experience, behaviors and interactions. Pushing in this context means rapid evolution of a working UI.
The average lifespan for a software engineering job is 4 years. Okay, I've never actually seen proof (or contradiction), but that's the general feeling in the groups I associate with. Perhaps that's selection bias - my employer has generally changed on year 3 or 4.
And, since I’m cheating on how to do a real personal kanban, I thought I would at least describe for you how to do real personal kanban over at Personal Kanban for Your Job Hunt.
The sales team made promises of technology the company wasn’t capable of delivering. Meanwhile the engineering team was sent scrambling to answer to those promises. This is why I started out hating sales in my early career.
It is to easy to get hung up on a mistake and become paralyzed by it in such a way that it prevents you from having future success. I seem to have an instinctual desire to throw away what I am doing or try to completely wipe the board clean, whenever I make a mistake.
The beginning of a Sprint provides a new opportunity for getting things right. Unfortunately, Sprint Plans are easily stomped on by operational concerns. Emergencies, defect fixes, new priorities that trump earlier ones...the list of potential spoilers for a Sprint Goal seems limitless. Is Sprint Planning really worthwhile, or is it a ticket to nowhere?
Scenarios and storyboards are great tools to describe how users interact with a product. They also complement user stories nicely: Scenarios and boards help explore risky stories, discover new user stories, and capture the relationship between stories.
A component test is a test that limits the scope of the exercised software to a portion of the system under test. It is in contrast to a Broad-Stack Test that's intended to exercise as much of the system as is reasonable.
A key decision in building and managing any development team is agreeing on how ownership of the code will be divided up: who is going to work on what code; how much work can be, and should be, shared across the team; and who will be responsible for code quality.