Monthly Archives: December 2014

Start With One

3d ManStanding Under Direction Board Stock Image

digitalart –

We all played at it when we were younger. “If you were stuck on a deserted island and could only bring one person/item/food what would it be? As we prepare to enter the new year I thought I would ask a similar question. If you has to start down the path of Agility with only one process what would it be? This isn’t about what one value pair or principle you would follow. As an Agilist I hope that your preferred process does line up with one, but that’s not the point. All change has to start with something. If you were only allowed to do one change at the outset, what would that change be?

Maybe you would start with iterations in hopes of rapidly delivering value to your customer. Perhaps your first order of business would be to change your teams so that developers, testers, and business representatives are working together on product teams instead of separately on functional teams. It may be time for you to bring your product team and your customer together for some direct interaction.

Whatever the single step you could take is you should move forward with it. Every team and situation is different, and as such there are multiple right answers for what one thing you should start with. As a coach or agile change agent you may have a favorite that you lean towards starting with. I’ll be back after the new year to talk about my preferred starting point and why. In the meantime, feel free to share your preferred starting point and why.


Working Team Celebrating Stock Photo

Ambro –

The Agile Manifesto has important things to say throughout for any time of year. As Agilists we should seek to embody it whenever we can. We should allow it to guide our thinking, decisions, and actions at work.

While the Values are at the core of the manifesto, the 12 principles are important to know as well. This time of year is a good time to focus on one part in particular, sustainable pace.

The actual text from is:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Because I believe Agile principles and practices can apply outside of software development I like to think of sustainable pace versus sustainable development. They should be thought of as having the same meaning.

Classic software development is thought of having a “death march” at the end. This has been true for some teams in the past, but is not a given. The idea of the march is that a large amount of stuff is butting up against a final deadline and has to be working no matter what. The causes are varied and not relevant to this post, but that it happens is.

In Agile we make small bits at a time. There can be no death march because there is no large deliverable to slowly creep to a long away deadline. There is a deadline coming soon, and a small amount of stuff to be done by then. Right after that will be another near-term deadline with a small amount of stuff to be done by then. If there is a “mini death march” as we come up on one deadline, less stuff is promised for the next deadline.

One advantage is sustainability. By eliminating the death march we save our people and allow them to perform better more often. Without a death march looming over them the people on the tea will have no problem continuing to deliver.

During the holidays that need for sustainability becomes stronger. People are under stress from outside influences. Their friends and family are demanding a little more time than they normally would. Their ability to commit at work may be impacted. An Agile mindset allows us to continually adjust our commitment and maintain sustainability for every member of the team.

Do you account for outside factors as you plan future iterations? How could you start?

Automation and Agile

Cogs Stock Photo

Michelle Meiklejohn –

Almost every time you hear about how to become more Agile automated testing comes up as a must do. The natural assumption might be that automated testing is required for a process to be Agile. If a team doesn’t use automation they feel they cannot be Agile, so why bother trying?

I have read the Agile Manifesto many times. Of course the value statements wouldn’t have anything this specific. I’ve read the 12 principles many times as well. I have never seen where the manifesto or the underlying principles require automation in any form. Continue reading