About Visibility

A couple of years ago I had the luck to attend a course given by Ken Swchaber. during that course Ken pointed that the main role of the Scrum Master in a scrum process is to ensure visibility. On all Levels.
But why is visibility so important?
There are many answers to that. Probably too many for me to do justice to them all. for example, you need visibility to understand exactly where you are in order for you to make the right decisions based on real hard facts.
Today, I happened to tune in into a TED session about Four principles for the open world, by Don Tapscott. In that session Don talks about Transparency and what that may cause organizations. He explains that since today the world is so transparent organizations must really adopt good values as part of they backbone. those values are what creates trust which later on enable real collaboration.
So here you have it, we want to create a high level of Visibility in order us to gain the needed trust which will enable us to truly collaborate, with our customers, with our managers with our peers and with ourselves. Visibility is the key to get there.

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: Agile Principles,Agile Values

Iltam Meeting – Being Agile

on Sunday 1/7 Iltam is going to conduct an interesting meeting that will cover some very interesting agile subject. Specifically what I really like about this meeting that after a very long time I see some content that will mention my old and favorite Extreme Programming process. For some reason the XP methodology is no longer discussed in the Israeli community.

Anyways, there will be three parts to this session in the first part my partner Elad Sofer is going to talk about agile tools, Afterwards Danko will do a scan of various process models which are bundled under the Agile umbrella and I will do the last part in which ill talk about the experience I had in managing an R&D group using the XP process, if you are interested the complete details can be found Here.

hope to see you there.

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: Events

Taking design out of the requirements

One of the biggest mistake you can make as a product person is to include in the product requirements technical design decisions.
I picked up this lesson about 4 years ago at a session given by Tom Gilb at the first Agile Testing Days conference. I think this lesson is applicable in all types of development processes but is crucial when you are trying to use an agile process

The Mistake

Here’s an example I recently encountered at a backlog grooming meeting:

We need to have a pipeline of processing stages in order to …

It was the word pipeline was got me going. when you mention a pipeline in a user story. no matter how you turn this around you just decided not only what you want but how you want it built. there is no sane user (that I know) that actually care about pipelines. in fact I would assert that most sane user has no idea what a pipeline is, unless they come from the oil business.

So why is this wrong

First lets be clear there is nothing wrong about doing design. In fact it’s a very crucial step in developing software. The thing is that you don’t want to mix between technical design: how we are going to create this, and the business needs (requirements): what we are going to build. and there are two main reason why you don’t want to mix this:

1. when you use the solution in order to describe the requirements you actually hide the business need. instead of discussing the need you start to discuss how you implement it. this makes business decision like prioritization, exact behavior much more difficult. its especially true if the solution is for some reason marked as an “infrastructure” that will be needed. as a product person how can you give low prioritization to something the technical department just claimed to be an infrastructure? even if that infrastructure was just created to solve a less important business need?
2. you don’t want to kill the team creativity – the moment someone put the solution - pipeline in the story was the moment the team stopped thinking about is this the best they can do. Is pipeline the best way to achieve the need? maybe it is maybe its not. putting a pipeline in the solution will discourage any team from thinking about alternative. After all, they were not asked to solve a problem, they were asked to implement a pipeline. so that’s what they will do.

When you are at the phase in which you design your product translating it into requirements for the development team, try always stay in the problem domain. Let the technical people worry about the solution. Technical design is the exact thing they are trained to do. the minute you start giving them the solution you just wasted a highly priced team and probably took one decision much too early.

Read more »

Posted in: stories,tips

Push vs. Pull Management

Over the last decade or so I encounter quite a few managers, while each of them was unique in its own way, I roughly found that I can divide them into two main groups according to their strategy.

Pull Managers

On one hand there were managers who were very into what went on always walking around asking question showing interest in everything going on and putting their nose into all places including those it didn’t belong in.

Push managers

in the other group there were those who considered themselves the focal point of their team, they usually got their info by using all kinds of report, they did attend meeting when needed, and naturally they did talk to their team, but most of the time they were minding their own business using their own room to manage the work. and popping from time to time to ask something/direct the work.

While I do have my own preference on how I would like to see managers behave. I do think that you can be successful using either way. I do however feel that there are contexts in which “Pull managers” have a higher chances to succeed.

Pull vs. Push Systems

No I’m not going the Kanban road. I do want to talk about systems design.

question: if you have a system in which a single component needs to keep track of the overall system state how would you design it?

Will you have the various parts of the system “send” their events to this main component (Push) ? or would you have that main component pull the needed information whenever he needs it?

like always the correct answer is: it depends. If you have a very high rate of changes in your system (lets say thousands of events per second) or/and you have a relatively small number of parts. you would most likely prefer a pull mechanism. if however you have a relatively small rate of change or/and a large number of parts you would probably prefer a push mechanism.

Now lets take it into management. I’m used to work in an agile environment. in such an environment that amount of data which is gathered on a daily basis is large. the entire process is created in order to handle changes. and if you do it right most likely there will be a lot of change. and in such an environment if you want to succeed I believe that going the pull way will server you better as a manager.

Trying to sit in your office and expecting the information to come to you will means that you most likely will:

1. annoy your team – demanding them to bring the information to you whether on a daily basis or via and electronic management tool.


2. Miss a lot of the info – since an agile process will focus on verbal communication, there’s a lot going on which is not captured in any written way

Trust me if your managing an agile team you will need to do the Gemba each day

Read more »

Posted in: Agile Management,Agile Values

And Sometimes You Lose

Here’s a story of TDD adoption failure:


about Two years of effort becoming insignificant in about 6 months.
Shame

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: TDD