Becoming agile

Agile, through the storms

Archive for the tag “Boris Gloger”

#AP13 – A Big Thank You

Agile Practitioners 2013 conference is now over, and what a success is has turned out to be. And it is so tempting to think that this is about Practical Agile arranging this conference – well, it’s not.

On the other hand, in the “mania-depression” journey towards this conference, there are lows such as: “why would Boris GlogerDan NorthYves HanoulleMarcin Floryan and Markus Gärtner come to a conference organised by a tiny organisation in tiny Israel?”

Well, they did, as did eleven additional local speakers – and this is what it is about.

About 200 people came to see these magnificent experts talk, share their learning and expertise on agile, and influence the Israeli agile community.

Of course, this event would not be possible without help, financial and otherwise, and we are very grateful for the sponsors of this event: HPScrum AllianceExperisKanbanizeESL, and Bor!s Gloger. Also who produced this event.

We have received great feedback on the conference, some insightful and some overwhelmingly positive. Presentations of all the talks will be uploaded to the conference website in the coming days.

Some of the speakers have already started talking about their talks, so follow their blogs to find out what they thought. Here are three posts I found by Markus Gärtner,  Eilon Reshef and by Gil Zilberfeld

And finally a Big Thank You for all of you who took one or two days off work to be in the conference. Your participation is what makes it work. We will begin working on #AP14 pretty soon – if you have ideas on what will make it more relevant for you; if you didn’t come because something was missing from the program; if you had a A-Ha! moment on what you would like to see next – please let me/us know. This event was a success because of You – as will the next one be.

That’s the Waze, a-ha, a-ha

On virtually any trip I make by car, I open my GPS APP, Waze. I do this for a number of reasons: It’s social, it’s a learning experience, it is a good investment and, yes, it also helps me get there effectively and on time.

Such investments and learning opportunities are relevant for organization life as well. If you don’t make these opportunities, they will not happen on their own. Just the same way that if you don’t open Waze on every trip (longer than driving to the corner shop) you will not know if you are getting into heavy traffic or heavenly clear roads.

For those of you who are not familiar with Waze, it is a GPS mobile application that provides near-real-time data on traffic. The way it works, is that is collects data from active Wazers on the road, and uses it to calculate traffic speed. It also enables users to report on important events, such as obstacles on or near the road, weather alerts, police presence, and more.

So it is quite clear why it is social. It is also clear why it helps me get to places. The question remains what makes it a learning experience, and what makes it a good investment.

The learning comes from improving my ability to plan things ahead. I learn what routes are better at what days of the week and times of the day. Yes, I can also do it by recording the data myself. But by having some preliminary data at the start of the trip, and validating it as the trip unfolds, helps me make better judgments on the same trip and on subsequent trips. It also helps me realize ahead of time whether I need to make a decision – for example to call a client that I am going to be late or early.

The investment is in contributing continually to improving this near-real-time data. When I open-up Waze I provide this data to others, not only to myself. Likewise, other Wazers help me by merely using the service. In fact, one of the main reasons that I acquired a smart phone in the first place, is to be able to use Waze. That was an investment too.

As it turns out, not surprisingly, the closer I am to the target, the better the accuracy becomes. As someone once told me about product development: The longer it is, the harder it gets.

A long trip is not quite as predictable as a long trip:

Different routes have different speed characteristics and different slowdowns:

Indeed, these kinds of investments are true for other aspects of life, not only for using your smartphones.

It takes a lot of learning to understand that planning is not a one-off activity per release or per product version. It is something that takes place continually. The more planning you do, the more you understand whether you are going to meet your interim milestones (call them iterations, if you like).

It requires making investments in order to build the framework to gather data as you go in order to be able to do your planning: the short, and medium, and the long term.

When driving somewhere, it does not make much sense to look at the map, divide it leg by leg, and extrapolate how long it is going to take based on logic and common sense alone. It requires hard data, even inaccurate, but hard data, to do that.

In order to be able to create such a framework, you will need to learn how to start the project in the first place. How to create a contract with the customer that is not stifling into rigid plans. Such are agile contracts – a framework that helps two companies inspire one another, and not bind into unchangeable scope.

Alongside the contract with the client, you will need to learn which walls that exist within your own organization divert you from increasing the pace of making software. Where do you have ‘traffic jams’ that could be avoided by using another, simpler, route?

In order to do planning continually and effectively you want to be able to collect data about what the road looks like ahead? Where are the technical ‘traffic jams’ that you will meet along the way, and that maybe you can resolve before you get there? How do you measure them? Collecting data about your application’s complexity, and testing it continually provides such data, and provides early feedback, and to fix them before they become complete roadblocks.

The way you architect your product may also need to change. By looking at the map and guessing which parts will be slower you don’t get real data to make good decisions. You have to be out on the road in order to figure out whether your car can make it or not; whether the road is good enough or not. Good architectures are unfolding as you get more data collaboratively, and not by hoping for the best and then starting the journey too late.

And finally, I am sorry to break this to you – it is all about you. If you change, your organization will also change. If you provide others with tools that you can use on your own, maybe they will also change. Ultimately, whatever your role is, developer, tester, architect or CEO, you are responsible to make the change.

Are you the kind of person who waits for other to make all the changes on your behalf? Or are you holding the wheel of the car which is your own professional or personal life?

Agile Practitioners 2013 is a great opportunity to make such investments. Join us for the fantastic star cast we have gathered to make this investment a real learning experience for you and your organization.

Post Navigation