Software Estimation – the way that most of us do it – is broken. As an industry we’re bad at estimating, we've been bad at it for a long time, and there’s no evidence that we’re getting much better at it.
One problem with many (maybe most) software development organizations is that they inadvertently create perverse incentives, rewarding undesirable behavior and creating confusing and chaotic environments that, despite best efforts of all involved, seem to only on a hit or miss basis produce the desired result.
After working as a sales manager at two different Agile organizations I am often asked if sales can be Agile, and if so, how is it implemented?
Obviously some job titles appear to have more clout than others, and obviously some titles would be more desirable for a software writing professional to have, but a job title alone doesn’t convey any real information.
In case you didn’t know yet, I post plenty of interesting links to other people’s blog posts and magazine articles via the social network streamsof Management 3.0 on Twitter, Facebook, LinkedIn and Google+.
A Hudson Bay Company expedition would set out for months in the wilds of Canada—traveling mostly by canoe. To ensure nothing catastrophic had been forgotten, they would camp the first night or two within a short distance of their departure point.
I wrote earlier in the year about my use of pomodoros to track what I’m doing outside of work and having done this for 6 months I noticed that I’m now procrastinating over picking something off the list to work on.
You get tremendous benefits when you develop by component: high cohesion in the component and low coupling between components. Don’t underestimate the value of these. When you develop by feature, you get features. It’s hard to underestimate the value of working product.
There is none. Even the most agile of projects will have architectural concerns of some description and these things need to be thought about up front. Agile projects therefore need architecture.
Of course, the participants in this discussion are talking about a computer language. But what about being an expert in spoken language?
An awful lot of people at SyncConf worked for Aviva and during the day I spoke to many of them. Aviva are trying to be “Agile” but like every other big company are struggling.
There are many benefits to Agile, but arguably the most important one is the Silver Mirror. Agile forces companies to look within their own processes and it exposes troublesome areas. Before starting down the road of tackling technical debt, it must be properly tracked.
It’s much easier just to assume complexity everywhere. You can always reduce the universe to a few domains or categories later. When you have time, over a cup of coffee.
I’m not sure I ever got a chance to talk to the engineer who made the initial recommendation based on my blogpost, but I definitely got to talk to a bunch of great people and had massive fun.
The immediate benefit of the event is having it fresh in people’s minds when they’re talking about it, and we get an added benefit as well.
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.