Creating a Mini-Waterfall

Some people refer to sprints as mini-waterfalls. Well that’s a mistake, sprint are not that.  But a mistake or not, doing a Mini-Waterfalls still seem to be a natural step for some people when they start with their Agile transformation.
So how do you create a mini-waterfall?
well its not very hard like anything else when you create a mini-X you start by taking the X for example:


and then you make the same thing just smaller. like this:

see where this is going?

I encountered several contexts in which a companies, after getting some basic knowledge about Agile, seem to think that they are already mostly Agile, and what left for them to do is just start working in short cycles. So in order to become “Agile”, they take their regular process as is and shrink it down to fit inside short time boxes (anywhere between a couple of weeks to a couple of months) and wait for all problems to disappear (well they just become agile didn’t they?)

Is this bad?

Well actually by itself no. Doing a mini-waterfall isn’t necessarily a bad idea.
on the Pros side we can say the following:

1. Mini-Waterfalls is some kind of an iterative process so you will get more feedback.
2. When you work in a short time boxed iterations you will be forced to work in smaller batches.
3. To support working in small batches you will need to get used to cut and slice the work into small things.
4. and when you work in smaller batches, all kind of things will become visible. For example, your one week manual regression cycle is going to be a real problem. The fact that you only manage building a working version of your product once every three days might also be an issue…

So basically when you start doing a mini-waterfall you are taking one big step in the right direction
However, On the Cons side we should probably say that:

1. Mini-Waterfalls is some kind of an iterative cycle so you will get more feedback.
2. Working in short iterations is just different than working in long cycles.
3. If you don’t do the needed mind shift, working in mini waterfall is going to be very hard
4. And if it gets hard enough , most likely you will stop doing it.

So basically doing a Mini-Waterfall process is not a steady state. Keeping it for long is extremely hard. When you a team starts working in short iterations things that were comfortably hidden become  visible and painful.  and the natural reaction to pain is to make it go sway. You can either fix the problems – maybe becoming more agile as you do, or you make sure to hide them again by reverting back to the older process for example.

So when is it bad?

Mini Waterfalls become bad when organizations confuses them with an agile processes. The difficulties of sustaining a mini waterfall along with this confusion, causes some companies to revert back and claim that Agile is bad. In fact I’ve participated in several emotional discussion with people that experienced exactly that. (BTW trying to go down the this was not agile road only seem to fuel the fire).

Can it be good?

Well I don’t know. However, I’m not sure that’s even an interesting question. Personally I would avoid a mini waterfall. If you try to become agile you should probably try doing something different. There are easier and less risky ways to start. trying Kanban might be a good alternative if you want to start at a familiar place.

But we already are in a Mini Waterfall. Now What?

First realize that by understanding the problem your are half way there.  Best option at this stage is to face reality heads on. Stop pretending you are Agile. You are not and its really not important at all. Accept the fact that the problems you see are naturally caused by trying to take a lengthy process (designed for long cycles) and squeeze it into  a very short time period (iterations). What’s actually crucial at this stage is to examine the pains and learn rom them.  Each and every pain is a place in which something new can be learnt, about your process, about your team about the context or maybe personally about yourself.  If you manage to locate the actual root cause there’s a good chance you can make real progress. Design small experiments with the goal of finding out what may be the cause of those pains. Try to test different things and see how they effect you team. Collaborate with other parties in the organization and see what they have to say. And always remember that a new process (yes even a mini waterfall) require a new way of thinking to make it work. Most likely old solutions wont solve these new problems.

Read more »

Posted in: Agile Management

“Introduction to Agile Process Management” Slides

Had great fun last week at the ALM user group meeting. Great audience with great questions and feedback, as well as meeting old and new faces.
For those who missed my presentation, and those who want to refresh their memory, here are the slides:

Read more »

Posted in: Agile Management,Events

Agile Practitioners IL– Group meeting #11

On Monday we met again at Kontera offices to hear Guy Nachimson talk about “How to help others take more responsibility”.
In the talk guy explained about a Christopher Avery's Responsibility process. this model deals with how people react and behave when they encounter a problem they need to solve. The model deal with various states that describes how a person reacts:

1. Denial – First reaction is to ignore the problem. it didn’t really happen.
2. Blame – when we cant ignore the problem we look for someone else to blame. “it wasn’t me it was XXX”
3. Justify – when we finish blaming, we then start to look for justification on why this happens. (the situation forced us to do this, things just didn’t let us do something different,…)
4. Shame – after we finish to justify our actions, we understand that it something we did and then we are a shamed that we did this and that
5. Obligation – here we understand that something needs to be done, however we don’t do what we want to do but something we feel we must do.
6. Responsibility – this is the state we want to be. here we take ownership of the problem and use our ability to deal with it and make things better
7. QUIT – sometimes, before we assume responsibility  we choose to give up and just let go.

According to Christopher, this model is quite universal and there is no way skipping this stages, the trick is to recognize where you are and try as much as possible to pass through these stages as fast as possible in order to reach “Responsibility”.

What did occur to me while hearing Guy describe the model, is that this model is not only applicable to individual, but can also describe organization culture. Personally, going over some of the companies I encountered, this model can be used to better describe how the organization as a whole is behaving. The easiest one to spot of course is the Blaming culture.

We finished off the session by doing a nice exercise in which guy used a friendly competition to show how one can better spot where a person might be located in this model by listening to what people are saying. things like:

• “but our group is only 3 people so we need more time” – justification,
• “We should have done XXX” – shame.
• “But we must do YYY” – obligation

All and all a very interesting session, I cant wait for December 17th to hear Christopher Avery himself going in depth into the subject. Two hours is not long enough to really cover this subject

Read more »

Posted in: Agile Management,Agile Practitioners IL,Events

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

The Role of Management

One of the talk I really enjoyed at XP2012 was: The Manager's Dilemma by Ola Sundin. In this talk Ola tried to answer a simple question that always rises when an organization is starting to adopt Scrum: What is the management role?

Manager as the developers of the Organization

It was lighting talk (15 minutes), so there was not a lot of content there, but there was a single excellent idea. The managers are the people which are responsible for making the organization better.
while the team, the SM & the PO  are in charge of developing a product making it better. Managers are there in order to improve the organization in order for it to become more valuable to its customers (share holders).
Using this basic idea Ola showed how he managed to bring all the managers into a single “scrum” team and use the basic scrum framework to manage their work. The had a daily they had a nice visible board, they created their own backlog of items etc.
And it all started by making the managers do a Gemba walk each day. That is the managers made themselves truly available for the team, by walking around and communicating to people each day.
The rest of the details can be found in his slides
Remember:

Managers are people too, Ola Sundin, XP2012 Malmo.

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

Read more »

Posted in: Agile Management

Agile Practitioner IL - 3rd Meeting

Sunday evening we met for the 3rd time. This time Roy Osherove discussed 10 mistakes team leaders make an updated version of the slides can also be found here.
During the talk Roy mentioned several books, out of those I really recommend Johanna Rothman & Eshter Derby, Behind Closed Doors: Secrets of Great Management. For me that book was a career changer. I recall reading it as a team leader and for the first time I felt someone actually wrote a book that explained to me what a team leader job is all about. Also the book is filled with practical techniques that can be applied as is. from planning to conducting one on ones. Just the sort of advice I needed at that time.

Scrum Master vs. Team Leader

Towards the end of the session a discussion rose regarding the place of the scrum master and about the amount of authority he as over the team.
On one hand we all know that a scrum master is not the team leader. and it is considered a bad practice to make the team leader into one. However, it is also clear that the Scrum Master as defined by his roles and responsibilities, should lead the team helping them to become better at what they do. and in fact in most cases the natural candidates for becoming the scrum masters are the team leaders.
So where does the line from leader to manager is drawn?
Actually I don’t have a good answer for that. My gut feeling tells me that a “good” team leader, will fit the role of a scrum master very easily. Yes there are some traps and pitfalls that he should avoid, but if he is “good” that should not be a problem. However, many team leaders are not “good” and there is a real danger making them scrum masters. While as a team leaders they might manage to still function, as scrum masters they are not equipped to handle an agile transition which by itself is hard enough. In most cases they just ruin any attempt at any kind of an agile process. In my eyes the job of a scrum master is so much harder and it take a more experienced person with the “right” state of mind to do a good job. Leading a team is much harder then managing it.

The “Good” team leader

the million dollar question is of course how to sort the “good” team leaders from the rest?

• Are they the team leaders which demonstrate the best productivity in their teams?
• Are the the one most liked by their teams?
• are they the ones most appreciated by their managers?
• or is it something completely different?

don’t really know.
The only thing I did found along the way, is that there is a strong correlation between team leaders exert minimal authority over the team to those who becomes great scrum masters. So when I see a team leader which doesn’t “tell” his team what to do, and instead asked them many questions I know that there is a good candidate for becoming a Scrum Master.

Read more »

Posted in: Agile Management,Scrum

Making your team manage their own work

I really think that team leader should stop being the ones which split the work into tasks and decide who does what.

I’ve written more about this subject and it was published here at the 5whys blog. (which is an excellent reading materials for team leaders)

Read more »

Posted in: Agile Management,Agile Principles