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