A few months ago Markus Gartner introduced me to the Testing Triangle, or Testing Pyramid. It looks like this...
One of the teams I work on recently started a test of Asana, a product touted as “…the next big step in productivity”. We were looking for tools to help us manage the work we do on a regular basis. I’ll put our work in two categories:
Some commonly accepted ideas and best practices aren’t important: if you don’t follow them, nothing bad will happen to you and your project will still succeed, but there are a couple that you are better off not following at all.
I have tried to contribute to the agile community, chairing the Agile 2009 conference, speaking at user groups, writing for a number of outlets, working with my clients. I do those things because I love my work. I don’t do them because I’m female. I provide a type of diversity, more because of my age and experience than my gender.
In the classic personal growth book, 7 Habits of Highly Effective People, Stephen Covey states that private victory precedes public victory. We need to look after ourselves before we can effectively help others.
Employing a collaborative workshop, and following the process described in this article creates an initial Product Canvas that allows you to focus on solution validation – building the product with the right user experience and features.
Do you know what a Sprint Review is for, and how it differs from a Retrospective? In this article we look at what a Sprint Review is meant to be, why it is important, how it differs from a Retrospective, and what you can do to make sure one actually happens.
A simple thank you can make a difference; appreciation builds good will, and reminds people that they are valued as human beings, not just as CPUs (Code Producing Units) or FTEs (Full Time Equivalents).
A Triathlon requires diverse skills, you not only have to run, but to swim and to bike, and, as we know, good software developers need diverse skills, too. By the way, quite a few IT guys I know, they do triathlon as a hobby, so there really must be something to it.
When I was project manager at Typemock, did I learn anything about becoming the product owner in an agile company? Let me give you five hints I learned.
I’ve been asking around on email and on the social networks what makes a conference memorable, special, or amazing. This topic has my special interest, not only because I attend between 20-25 conferences per year, but also because I’m trying to help make the DARE 2013 a great experience.
I gave a talk at Devs in the ‘Ditch last week when I was in London. I posted the slides on slideshare: Overcoming Three Pitfalls of Transitioning to Agile.
Our behavior is always a reaction to the system around us. Let us take an example of an Agile team working on a project, and as we know its behavior would be determined by the stakeholders, leaders, enterprise culture around them.
It’s easy to be critical of managers. A few things to remember. Point 0 - Most people in management roles want to do a good job, but may not know what to do or how to do it...
If you take anything away from this cautionary tale it is to constantly be on the look out for those that adhere to the status quo. It takes a certain combination of this quality with an opportunistic personality to cause this sort of organization-wide damage but it does happen.
When creating something of value, the first people we care about are those who will get value from the product we create. I call these Consumers. These are the users and those who are affected by the work of the users.
Files can be added, committed and removed from git repositories using one or more of the following commands:
I’m at the Much Ado About Agile conference this week, in beautiful Vancouver. During lunch one day, one of the conference participants started talking about premature optimization of code.
Joel Cochran experiments with a few standing desk strategies and settles on a desk that moves up and down. You should check out the pics. It's pretty cool.
Measuring something meaningful is hard, so let’s measure something that is meaningless but easy. Like your hours at work!
If you really want to learn something, write a book about it. It doesn’t take long. After two months of plomping my arse down repeatedly I finally finished my d3.js book. Or rather, I finished the first drafts.
After reading Tao of Twitter and Return on Influence written by Mark, and Stanford’s reputation, my expectations were high.
None of us would be very good developers if we never had arguments about The Best Way to Do Things. But I've had enough silly arguments about tabs-versus-spaces to last me the rest of my life. When should we stop arguing and start writing code?
I’ve started work on some new videos and this time it’s all about Agile Estimating, Planning and Contracts. This is the obvious next step having completed Scrum101, and I’m apply some of the lesson that I learned.
Large-scale software and systems development involves a complex mix of people, teams, technologies, skills, architectures, and organizational structures that must all interact for projects to reach their goals. However, many organizations struggle to scale up agile approaches for their various programs, products, and services.