Monthly Archives: January 2015

Agile In A Small Team

Scrum states that the right size for a development team is 3-9 people. I have seen that when teams are larger than this they tend to break themselves to smaller sub-teams. This lowers the risk of attempting Agile with large teams, and if managed properly can make it easier by effectively replacing the larger team with the sub-teams officially.

Two Men In The Office Stock Photo

patrisyu –

When teams are smaller than this it may seem nearly impossible to properly “Do Agile.” An important thing to remember right off the bat is that Agile Is Not Scrum. It’s also worth remembering that Agile is a journey.

Take Pair Programming for example. It either is or is not happening. There are different ways of doing it. It can be tweaked a little over time. At the end of the day though, you either are or aren’t Pair Programming and if your process doesn’t change neither does that fact.

Agile is not like that. There is no end state where you can say you are Agile. If you think you’re at such an end state you have succeeded in no longer being Agile. Being Agile, or working with Agility as it were, requires the ability to change. Being Agile means one will constantly be open to inspection and adaptation. A static end state is completely at odds with this concept. Continue reading

Agile Requires Change

Change Ahead Sign Stock Photo

mrpuen –

I spend a decent amount of time pointing out that every Agile Journey will look at least a little different. I appreciate frameworks such as Scrum. Having a defined process to follow generally makes the initial start of a transition much easier.

In the last post I pointed out that change has to start somewhere. In fact, I would state there is no Agile Journey without change. Being Agile is deeply rooted in responding to change. It’s one of the main values from the value pairs. An Agile journey with no change is as useful as a cancelled cruise is fun.  Continue reading