Becoming agile

Agile, through the storms

Archive for the category “Agile”

20 Dec 2011
4 Comments

Agile Architect – What is it?

The Software Craftsmanship in Israel 9th group meeting was held today at SAP offices in Raanana. The format of the meeting was a panel, discussing the merits of the software architect.

Three thought leaders participated in the panel:

The host was Uri Lavi, who skillfully led the discussion.

There was interesting debate on what is an architect, the difference between design and architecture (no one really knows… but I share my view at the end of the post), how to identify a potent software architect, feature teams, and much more. It was educational, refreshing, thought provoking.

During the discussion it hit me – the role of the software architect. To be more precise, the role of the agile software architect.


Photo by Joone Hur, source: http://www.flickr.com/photos/joone/3050331298/

The architect is the person most suitable to translate the business/product language into engineering terms, and the one most suitable to translate engineering terms between various groups.

In contrast, the traditional architect’s role that is to author the high level design, as detailed and accurate as possible. Thinking as an agilist, this more than just waste; Such approach keeps architects on their Olympus, others having to understand what the architect meant to say. Not good.

Instead, the architect should work with the product manager, defining a solid Definition of Done, in order to create the requirements with solution in mind (thank you Eshed)

The architect should work with designers, developers and testers, to talk in their native language, in relevant engineering terms, describing the business needs of the customers, so they can produce the right software.

The architect should view the software, in various stages of being produced, in order to highlight quality issues, refine requirements, adjust the architecture – in other words, respond to feedback early.

In order to achieve the above, the software architect could be the one writing the high level design, creating solution overviews and diagrams, etc. Could be, but does not have to be. The organization might gain more if the architect assists the above mentioned to product all these documents.

One option that worked very well for me is pairing. Very similar to pair-programming, the architect sits together with the product manager to author the requirements; and with the development team to author design and testing artifacts.

In order to achieve that, the good architect will be fluent in the business lingo, as well as a highly skilled engineer.

More importantly, the architect should be a people’s person; someone who is able to work in pairs and in teams; someone who can drive and navigate (a-la pairing) without prejudice.

Regarding the difference between design and architecture – here is my view. Design is an engineering skill. In design we take a requirement and turn it into a blueprint, that will be used later to create the product.

In architecture, we use engineering terms to describe the requirements, without losing the business context.

It so emerges, that in an agile framework the span of the architecture is wider than before. Since we want to keep the business context until as late as possible – and to continue using the business notion in the development team (As a <WHO> I want to <WHAT> so that <WHY> – remember?), the architect is a key for success.

Some will say that it sounds like the product owner. I think that you will be right. A good agile architect will also be a good product owner (not always vice versa).

How do you experience the architect’s role? Do you see the agile architect different to the traditional architect? In what sense?


Posted in Agile and tagged , , , , ,
09 Dec 2011
5 Comments

Built for Endurance

You just need to take a look at a crocodile, to see that this species goes back to prehistoric times. Same goes for the Komodo Dragon.

Source: http://en.wikipedia.org/wiki/Komodo_dragon

How come these creatures have endured so many thousands of generations? This will be part of the talk I will lecture on at the Agile Practitioners 2012 conference. I believe that the reason for the success of these creatures is that they are built (so to speak) for endurance. The single value, if you can call it that, that unconsciously guides these lizards to propagate, is to create successive generations that will succeed to produce further successive generations. A pretty Darwinist view, no doubt.

What has this to do with software organizations and agile, you might ask?

Many organizations declare mission statements, and values, and vision. This may come as a paragraph of text, a few bullets, or words:

“Our goal is to dominate the <Paste-Your-Business-Here> market”

“Provide superb customer experience”

“Low prices always”

What would be an adequate value for a software organization? In my view, Built for Endurance” is a worthy goal. Something that can permeate throughout the company.

A few examples:

What would be the effect of adding a 4th question to the SCRUM daily standup: “Is this sprint Built for Endurance”? What would that do to the team’s quality targets? Will surrendering to external pressure to deliver bring the team closer or farther from this value?

What would requirements look like, if the Definition of Done will include the statement: “Built for Endurance”? Will this guide the Product Manager/Owner to require better tests in the criteria?

What would the sales organization sell to customers, if they sell solutions that are “Built for Endurance?”

How about Human Resources? What would attrition rate be, if HR is called to support a work force that is “Built for Endurance”?

In my view, quality is very much about endurance, and very little about testing. If your quality organization relies on testing, you are probably trying to prove where your product and process is not endurable. If, however, you wish your products to be endurable, try thinking about the earliest point in the process to take this into consideration.

Where would you start? I will share some more insight about my talk in the coming few weeks. I will also be happy to hear from you about your ideas.

Posted in Agile and tagged , , , , , , ,
28 Nov 2011

What has NATO got to do with agile practices?

In one of the most influential articles I have read on the values behind agile, Alistair Cockburn refers to the 1968 NATO conference.

The Science Committee that brought forward the task of assessing the field of computer science, and its recommendation in 1967 to hold a working conference on Software Engineering. The term Software Engineering did not publicly exist until then. It was chosen as being provocative deliberately, checking the boundaries between practicing computer programming and other established branches of engineering.

I have read this article several times, and keep coming back to it. To me, it explains quite a lot of what has happened in the 40 odd years following the conference.

Interestingly, in 1970 Dr. Winston Royce introduced the paper
“Managing the Development of Large Software Systems”, commonly known as the Waterfall process. This pseudo engineering form was described by Dr Royce himself as being flawed. Yet, it was, and largely still is, the most practiced methodology for software development for decades.

If you, like me, want to learn a little more on the history that led us to where we are today, you are more than welcome to the 5th meeting of Agile Practitioners IL.

Meet Gil Zilberfeld, and hear on the fascinating ten year history since the Agile Manifesto:

The Agile tribe war – A 10-year history lesson

In the beginning there was the Agile Manifesto, and everything looked peachy. And then the universe exploded.

10 years later, we’re in the (post?) agile era, where different tribes are off to win the “we were right” cup. There are the craftsmen, scrum people, lean people, the post-agilists, and everyone else in the middle trying to make sense of this thing called Agile, what really works and how much it really costs.

How come the agile principles that were supposed to be the Great Unifying Theory of software, opened a tribal war we’ve been seeing the last few years? Is agile the real answer, or simply a filler between the waterfall and the next hotness? 

Join me in a travel through time, to piece together a puzzle of politics, money, intrigue, and yes, even software, and come up with a better understanding of what the hell really happened here and where we’re going from here..

The meeting will take place at Amdocs offices in Raanana, Israel, on Sunday December 4th. Gathering and mingling starts at 17:30, and the talk starts at 18:00.

Hope to see you there!

And a quick reminder:

Agile Practitioners 2012 conference is offered at special Early Bird prices.

To view the program and to register, visit our website at http://www.agilepractitioners2012.com/conference-program

Posted in Agile and tagged , , , , , | Leave a comment
17 Nov 2011
2 Comments

Fostnope – A new blog is born

I’ve been toying with the idea of having an agile-only blog for a while. My regular readers know that I write on a wide array of subjects: from agile to zombies, from birth to death, and everything in between. All posts, however, in Hebrew.

The conflict is between Ilan the professional agile practitioner, and Ilan the person. So I’ve decided to try to separate the two, and see how it goes.

In this blog I will post on agile issues – occasionally I will still translate the odd post to Hebrew in my ‘general purpose’ blog and from time to time I will translate to English some of my older agile posts to here.

But first things first. Right – the name. What the heck is Fostnope?

Well, it is the essence of becoming an agile teammate: It is an acronym of Forming, Storming, Norming, and Performing. We are finding ourselves in these stages all the time.

When we enter a new group, or when there are changes to our group – dramatic changes or otherwise – we return to Forming. We learn each other; we try not to steps on each other’s toes; we learn the turf.

After a while, we start to test the boundaries. We want to challenge ourselves and the others. We don’t want to be polite all the time – we do want to rock the boat. A storm is imminent – and that is a good thing.

Because when the storm subsides, we begin the real learning of one another. We develop norms according to which we behave in this group. Change the fabric, and you’re forming again. Maintain group stability, and you allow the members to develop conjointly.

If we are lucky, we get to be in a group – team I should say now, long enough to automatically behave within our norms. Rather than developing norms – they evolve naturally, without facilitation or artificial interferences – or almost without.

At any moment we may act in multiple groups and teams – as we always do. It is a good practice to observe, from time to time where am I, and where we are?

Are we forming? How long have we been doing this? Maybe it is time to provoke a storm?

Are we storming? Have we reached rock bottom yet? What’s stopping us from dealing with the core and painful issues?

Are we norming? Is it normal? How long will it take us to be there (hmmm, a long, long while, actually)

Are we changing? Do accept that we are forming again. Or storming. Or lucky enough to be norming.

So, happy fostnoping. I hope you will enjoy this blog J

Posted in Agile

Post Navigation

Newer Entries →