Last month InfoQ carried an update on the use of retrospective dialogue sheets. The use of these sheets continues to grow and I continue to receive good feedback.
User-journey tests are a form of BusinessFacingTest, designed to simulate a typical user's "journey" through the system. Such a test will typically cover a user's entire interaction the system in order to achieve some goal. They act as one path in a use case.
I previously wrote about my Sublime Text setup. Well, Tuts+ has published a quite nice Sublime Text tutorial showing most of Sublime’s features. Regardless of whether you’re a Sublime Text enthusiast or not, you should definitely take a look at the tutorial.
Mythbusters is enormously popular with technical types, and it's fair to say that it has earned something of a hallowed position in nerd culture. It's certainly a common topic at the water cooler for many in the IT business. So is there something in their approach to busting myths that resonates with modern software development practice?
The post is about how one can create a bubble of a new culture inside of an existing organization. For example, this may be used by a group interested in developing an innovation and learning culture inside a typical bureaucratic organization. This post is a continuation of my earlier post on how to Build Culture Adapters to Avoid Agile Failure.
I'm a big fan of using silent brainstorming in order to generate ideas as individuals before processing those ideas as a group. "Priming" is yet another reason why using silence is important.
Story tests are Business Facing Tests used to describe and verify the software delivered as part of a User Story.
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.