Becoming agile

Agile, through the storms

Archive for the tag “elad sofer”

Group Relations Conferences and Agility

My first encounter with the Group Relations model took place more than ten years ago, in an International conference in February 2002. The conference, nicknamed The Tavistock after the organization that invented the concept, was a turning point in my professional life. It was then that my career path gradually started shifting from the engineering domain to human relations.


Statue of Sigmund Freud and Tavistcok main clinic in the background. Photo by Mike Peel, Source: Wikipedia

Last week, Elad Sofer and I, two of the three partners in Practical Agile, participated in Ofek’s Group Relations Conference, which took place in the Galilee in Israel.

Although I had no idea what will happen during the conference, I had two hypotheses on our participation in such a framework:

  • Early on during the conference, Elad will engage with the model of the conferences and the Tavistockian thinking (which was already familiar for me before)
  • Both Elad and I will have a different type of influence, that will be enhanced by our participation as a pair

Both these hypotheses stem from a belief that while the models of agile software development and of group relations are very different, they have similarities on how they perceive systems, and in what they set to achieve.

In addition, for me it was a first to participate in such a conference together with participants with whom I interact regularly, and I have had ideas on how this might affect our experience.

Here are a few of my observations – Read more…

Advertisements

Suggestion Box

How do you get your team to become innovative? To generate new ideas?

Our default intuition is to ask people what they would like to improve. Well, this is good, but the real question is – is it good enough?

Take this photo, for example. How effective would it be in generating good suggestions? How sustainable will it remain over time?


Photo by Sethoscope

Our intuition tells us that if we tell others to do something, they will do it. However, we rarely apply the same intuition on ourselves. Say someone else put the suggestion box – how inclined would we be to participate and contribute new suggestions?

A learning team needs to nurture a learning culture. Think of those two words: nurture, culture. This implies that we need to cultivate it, and provide the fertile grounds for it to sustain.

Recently Mark Levison provided us one example of how to overcome technical debt and to increase the team’s evolvement and evolution into a team that learns how to learn.

He has used Michael Feathers’ brillirant book, Working Effectively With Legacy Code, to try out techniques of carving out problematic areas of our code, and refactoring them into code that is more maintainable and sustainable.

The point is one of courage. Will you be the first to lead this change? If someone is already leading such a transition, or attempting to, will you be courageous enough to join the ride? Take Derek Sivers‘ short clip about the underestimated kind of leadership – being the first follower.

Courage, as I have found out, is something you realize in the aftermath. Looking back in retrospect you say to yourself – “Where did I find the courage to do this?”

The order “Be courageous” in that sense is about the same as saying – put your suggestions in the box. If you are looking for courageous people, think whether you, as a team, are cultivating the atmosphere for such behaviors to emerge.

Not sure how to start? Make the first courageous decision, and get educated on the values, principles, and practices that will get you there.

Taking a good SCRUM course may be a good starting point. My colleague Elad Sofer is running a SCRUM course at the end of April (as do several others in Israel, and many around the world).

Register to this course at the course website at http://www.practical-agile.com/training/scrum-training-menu/practical-scrum

If you feel courageous enough to improve your retrospective skills, try our one day workshop

Agile Practitioners 2012 – Less than a week to go!

I’ve been pretty quiet lately, and for a good reason too. Together with two of my mates, Elad and Lior, we’ve been busy creating the Agile Practitioners 2012 conference.

Before I tell you more about it, I want to let you on a little secret at the end of this post, so please read on!

Read more…

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?


Post Navigation