One of the most common discussion that always seem to pop up again an again, is whether Scrum /Agile is good or bad. I don’t know why but in most cases it’s starts with a claim that Scrum is not  good since it … and then state a reason. (or with the claim that Agile is dead),for example

Scrum is not a good process cause its not complete, it doesn’t define everything you need in order to succeed.

or

Scrum is not a good process. Team members are equal, each has his own set of skills and ability and treating them as equals will not work.

And although in many cases those argument make some sort of logic, what most of them are missing is that scrum is NOT a process. Scrum is a framework.
Don’t get me wrong, I don’t believe in silver bullets, I don’t think that there is one solution (process) that fits them all. Each project context is different. The people involved are different, the technology varies, the business domain changes. While there are common patterns of issues and behaviors that we can look for, at the end each project is a unique, and therefore will need a different way of doing things in order to succeeds. That’s what I love about Scrum (and Kanban and XP), they are flexible enough to handle most of the diversity you can find.

Scrum as a Framework

Scrum is just a tool. But a tool for what?
Many people consider scrum as a process for software development. That is, Scrum is a tool used in project management that will help you t create a product at th end. but that’s not exactly right.
Scrum is actually a tool for creating other tools, more specifically Scrum is the tool which you use to create a your development process. The process that you end up with after you “applied” the Scrum tool, is the “tool” you use to build your product.
Confusing? Yes? lets try again.
Normally this means, that in the process of using Scrum you take the company, the people/team, the technology and the product. those are things you feed into the Scrum Machine (along with many other things) and at the end after some time you get one new development process. that process is what you use in order to manage you project.

Scrum is not a Process

so what’s the actual difference? why the fact that scrum is a framework important?
When I see teams taking Scrum as a process, what many of them fails to realize that that there a lot of hard work involved. They start with using Scrum and expect that all of there problems will go away. They read the book follow everything that is written there to the best of there ability and they expect that everything will be fine. What then happens is that Scrum does what it was meant to do, it starts by surfacing all the underlying dysfunctions that have been will hidden there. That’s what Scrum does best.
In order for a team to create a good working process, it must resolve its dysfunctions. The Scrum framework was designed with the sole purpose of exposing them in order for the team to face them and find a working solution.
In fact, this is exactly the stage in which many Scrum adoptions fails. Its seem to be really hard, When a team starts using Scrum all kind of problems starts. So clearly if Scrum is causing all these problems it might not be such a good idea.
In some case the team will try to stick a little longer with the Scrum book. that usually doesn’t help. in other cases the Team will revert back to old habits that seem to have worked in the past. that doesn’t work as well. they either ends up in their old process (and then the claim that Scrum has failed) or they end end up somewhere else that technically looks likes a scrum based process, but in essence is not (a mini waterfall is one example)
Scrum book has no solution for dealing with bad coding, it state nothing about how to create a good flexible architecture. it doesn’t give you an idea how to handle two team members that simply cant work together,….

Knowing your tool

There’s a reason why most scrum implementation fails. Like any tool, one need to learn and practice using it. No one expects that his holes will be perfect the first time he picks up a power drill. right?
Managing a software project is a little bit more complex then that, and still people read the scrum book which seems to be simple enough and expects everything to work. It doesn’t, Especially if you confuse your tools. Especially if you think that Scrum has all the answers, Especially if you think that since defines three roles those are the only roles that you ever need on a project. Especially if you think that the 4 ceremonies are all the meetings you will ever need. Especially if you think that a daily meeting is just a daily status report, Especially if you think that you can continue writing the software like you ever did and still deliver something every two or three weeks, and I can continue for ever like this.
Especially if you fail to realize that when using Scrum you will need to work hard in order to create a working process for your team.
so one more time

SCRUM IS NOT A PROCESS

Are you also

• Feeling you can do a lot better?
• Thinking there’s much more to Scrum and Agile?
• Having a hard time Finding your place with the team?
• Doing things you are not sure you fully understand?

Then come join our Product owner workshop on April the 30th.

Read more »

Posted in: Random Thoughts,Scrum

So what is the Product Backlog?

Trying to define what is a product backlog is always a tricky business. One definition I use from time to time is:

The product backlog is just another way of describing the system requirements and serves to describe the work needed to be done

Which is a good way to simplify it to death. I had reasonable success using this definition with agile beginners, but clearly it doesn’t start to capture its entire meaning.
The more official definition taken from the Scrum guide at Scrum.org is:

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product.

Which is more complete, but still raises quite a few questions. for example:

• What is everything? (new features? bugs? technical enhancements?…)
• If it’s a single source does it contains all the details? (i.e. the requirement docs)
• what is actually written inside it (how do we write those requirements? use cases? stories? plain English?)
• Is it a business facing document (i.e. read by clients and user) or is it a technical document (i.e. serves the team who needs to understand what to build)

So what is the Product Backlog

when trying to answer this I go back to my first initial encounter with  agile. At that time what I actually read and first saw was the work done by Ron Jefferies and Kent beck on eXtreme Programming. and what I still recall today is the simple statement in which Kent Beck explained that the whole purpose of agile is to bring all involved parties to one table and make them work together in order to create great products. (unfortunately I cant seem to locate the exact quote). At that time I didn’t know what a Backlog was and I was just starting to understand all the various agile techniques. but that statement just stuck and for me it’s the best way to describe what is the main goal of the Product backlog.
Forget about stories, requirements prioritization, acceptance criteria and all other technicalities which are associated with the product backlog.
In essence, when done right, the product backlog is the one “thing” that makes all involved parties converge communicate and cooperate in order to make the product a success.

The interface between the problem space and the solution space

To take it down into more specific terms what I think that the product backlog main role in the project is to serve as an interface between the business facing aspect of the product AKA the Problem space and the technical sides AKA the Solution space. On one side the Problem space is using the backlog in order to help it define the problem and describe on his terms WHAT its need to be done in order to help with the problem and on the other hand the Solution space uses the backlog in order to sort out the actual work. the team need the backlog in order to understand what is actually expected from him, what exactly he should build, what needs to be developed first. and most important use it to create a shared language he can use to talk to the business people and create a shared understanding.
And I’m guessing that this dual nature of the product backlog is what sometimes causes all these misunderstandings we see. here are some examples:

1. Every team occasionally needs to do things which are very technical in nature and involves a significant amount of effort. Being the single source of incoming work its not unreasonable that they will want to add it to the product backlog. However, these kind of things tends to be less understood by the business side, and suddenly there’s a conflict: “why do you add theses things that has no value to me?” asks the PO. “you know what, if you need it lets keep it there but please reduce the priority of it” which practically means ok I will let you put it there, but lets make sure that you actually wont work on it.
2. Being the single source of work, a reasonable team working in short iterations will expect backlog items to be of a certain size (typically a few days worth of effort). However, splitting requirements in a sensible manner is really hard work. The “Problem space” natural tendency is keeping the items size much bigger. I’m guessing it makes things easier to manage on their side (and of course avoid the extra work of splitting those into small chunks) and again we have a conflict
3. Not only that the Solution Space demands the things to be small, it also needs them to be FULLY prioritized. Even more hard work for the “Problem” side.

Now don’t get me wrong, there is no right and wrong here. All sides in all these situations are “right”. IF you look at it from there side. 

Treating the Product backlog as an interface

The moment all sides respect the fact that the product backlog is not only there to serve their needs alone, things tends to become much easier. When Technical people understands that the product backlog is the place in which business side describes the “Problem” and respect that. They find it much easier to keep it in a way which is understandable by the business side (avoiding the regular technical language they tend to use internally). When the business side respect the fact that the backlog is used to manage the actual work done. they find it reasonable to invest the effort needed in splitting, prioritization and other activities needed.
So don’t forget the Product Backlog is an interface. it’s the one thing that can be used to establish effective and productive communication by all sides of the business. Take advantage of it.


if you are also

• Having a hard time splitting user stories to shippable items?
• Struggling with predicting when will we reach the deadline?
• Having a hard time with prioritization of requirements?
• Does it seem that the team never understands what you mean?

Then come join our Product owner workshop.

Read more »

Posted in: Agile practices,Scrum

Agile Practitioner IL – Fourth Meeting

I had much fun at yesterday meeting. I really liked the amount of questions and interest people showed. While they didn’t make my life easy, I really enjoyed the conversation and discussion.
for those who missed here are the slides

Agile in unfriendly territories

View more presentations from liorf

Hope to see you all again net month and of course at the Agile Practitioners 2012 conference

Read more »

Posted in: Agile Practitioners IL,Scrum

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

Agile Planning is just Enough

Actually Agile planning is based upon two main principles:

• Just enough
• Just in time

that is, at each stage we plan just enough to get us going and answer the important questions at that stage and than we stop.

In this post Gil talks about agile planning how it mainly focused on short term. Well Gil you missed some important staff about what you call Agile planning.

lets start by saying that talking about agile planning as a concrete thing is basically misleading, agile planning is just a set of very basic principles (which I tried summarizing above). One need to refer to concrete planning practices in order to udge them.Planning is scrum does not look like planning in Kanban which does not look like planning in XP…

The example used is taken from a medical field, in which the stake holders

“needed to know everything would be ready in time, three years in advance.”.

Well sorry there is no such magic in our field. NO one can know what will happen three years in advance.

when you claim to be able to do that you are simply lying, both to your sponsor and probably to yourself as well. You can estimate, you can guess or you can extrapolate based on prior knowledge.

you will never KNOW.

Even when you sign a contract with millions of dollars in fines for being late, you cant know. you are just doing an educated guessing taking all the buffers and safeties you need in order to hopefully meet you goals in the given time. And BTW in most case you don’t (just check out Chaos report if you don’t believe me)

Long Term Planning

Gil is right about one important thing, almost every project need a long term plan. Question is and always will be is just how long do we need our plan and how detailed do we need it to be.

In scrum for example, there are 3 levels of planning:

1. the daily planning (done in each daily meeting) – we plan in extreme details what will be done in the next day
2. the sprint planning – we plan in details which tasks will be done during a sprint ( a few week ahead)
3. the Release planning – we plan the list of stories which we will deliver in the next release (typically 3-6 months)

And here Scrum stops.

That doesn’t mean there are no longer term planning, just that the longer term is “out of scope” for the basic Scrum process. u will still need a product roadmap, you will still need a strategic planning. and maybe just maybe (like in the example Gil gave) you will need to give a list of expected features for the next “big” version. However this kind of planning will always be more vague, will deal in general capabilities we would like our product to have and at the end will always be open to interpretation. it would never be concrete enough to actually start working on.

The nice thing that at the end my recommendations and Gil are the same (well we do basically believe in the same things):

do a release plan (3-6 months ahead) make sure you are working on the highest priority features and make your best to develop them as fast as you can, and always keep your progress visible top your customer.

So lets do a reality check, planning is nice and important, but “responding to change over following a plan” is what makes agile processes works. The longer the time frame you are planning chances are higher that this change will be bigger and come sooner.

Read more »

Posted in: Planning,Scrum

5 Reasons for Doing Scrum

A while back ago I gave a talk about what are the main benefits any organization should expect when changing its process into an agile (Scrum) process.

Here is the recording of that session. Its about 50 minutes long and its in Hebrew.

Hope you enjoy it

Read more »

Posted in: Agile Principles,Conferences,Scrum

Video of my talk at “QA & Development In Agile” conference

Last month I spoke at “QA & Development in Agile” gathering. SELA were kind enough to video my talk and to make it avail;able online.

Details about the talk (with the actual slides) can be found here.

and if you want to tune in and listen to the actual talk (about 30 minutes in Hebrew) you can do it here.

Also I would appreciate any feedback you can share. So feel free to add your comments.

Read more »

Posted in: Conferences,Events,Scrum

My Presentation at “QA and Development in Agile”

This is the presentation I gave last week over at the “QA and Development in Agile” conference (including some extra slides the I didn’t have the time to go over). Unlike other presentation this one was solely process related and not about any tool so I hope everyone enjoyed it.

The main pint o the talk was that its more important to optimize the team feature throughput than the team utilization and I hope I managed to get it across.

Scrum Project Management

Would you like hear me present? Contact me!

and in any case would love to get your feedback on the experience.

Read more »

Posted in: Conferences,Scrum

Moving from Fix price to Agile Contracts

One of the major roadblocks in an agile transition is the fact that when adopting an agile approach fixed price, fixed content contract does not make much sense anymore.

sure, some organizations are succeeding in doing agile under such contracts but one of the promises of Scrum is to be able to easily cope with changing requirements, and change the work plan to contain the most valuable features seen at that time.

On the other side, after so many years working under fixed price,fixed content contract its really hard to change especially since much of the time the other side (the one paying) is not really involved in the decision to adopt agile.

Its all about risk

a couple of weeks ago I had the chance to talk Giora Morein during a conference, after a while we started talking pricing schemes at which point Giora pointed out that when working under a fixed price contract, the risk involved is mostly placed on the side providing the services, while when using an hourly/daily rate most of the risk is taken by the paying side.

I believe that this fact is part of the problem we face when trying to adopt to an agile contract. The problem is how to convince a customer that is used to having the risk placed at the supplier to accept the risks involved in committing to a project under a flexible budget and content.

Moving Into an agile Contract

The first thing I found useful when I try to switch to a flexible more agile contract, is to start by acknowledging this fact. I than counter to with the benefits of such a move, focusing on the benefits the client will see.

In many cases this is not enough and the customer will still choose to use the same fixed price, fixed content agreement and in this situation I found the following steps to be very useful to establish a level of trust needed to actually change the working contract.

In order to actually change anything the first order of business is to sort all requested features by order of importance. In most cases this is grasped by the client as a reasonable request and it opens several channels of communication whiled doing so. its very important that the client will be involved in this as much as we can since this phase build the basic understanding both parties can build upon later on.

Second I try to add the following key points to the contract

(since all this points are actually controlled by the client most have no real objection to include them in the agreement):

1) Scope can be changed - The client can swap any requirement/feature by a new one of similar size, as long as it conforms to the basic priority scheme.

2) Priorities can change - by the client at any point of time. These changes will be reflected to the work plan (excluding things which are currently under way).

3) The client can take a working version of the work so far. In fact he is encouraged to do so and provide any feedback he can n it.

4) Termination - at any point of time (subject to a reasonable fee – I use 25-30% of the remaining cost) the client can terminate the project taking all the work done so far.

I have tried this scheme on a couple of occasions and found that after a few times the client actually invoke any of this clauses. He usually see the benefits involved in such an agreement and the next time he actually insist on this ability and is much more open to a working under an “agile contract”.

Read more »

Posted in: Agile practices,Scrum

On Agile Misconceptions

Here’s a short paragraph I encountered in an article talking about development models and how testers fit into them:

Agile models and scrum as a lead process changes the classical concept of development phases. Furthermore, due to short time frames there is very little documentation produced.

To us as testers, this means that there is no time to write test plans or detailed test scenarios and there is no time for to perform extensive regression tests. In these models the testers are part of the mission team and responsibility to the quality of the product is of the entire team and not only of the testers.

At first glance this seems a fairly accurate description of an agile process. However there are two big Buts here.

Agile = No Documentation

This is a wide spread misconception. Agile does not means that there are no documents. On the contrary the agile Agile Manifesto specifically list documents as a valuable thing (Working software over comprehensive documentation). The only thing is that most documents undergo a radical change making them appear less like old fashion word documents and more like charts and diagrams. What does happen in many agile teams is that since there is a clear emphasis on ROI many documents fails to demonstrate their positive ROI and tends to be discarded in favor of more efficient methods of doing things.

Agile = No Time to fully test

After so many years of working with scrum it still a wonder for me that people get this one wrong. For me the biggest change that Scrum gave me is the notion of Definition Of Done. That is, that a feature is not finished until all related work is complete. And the exact scope of the needed work not only need to be declared, it should (and this is the important part) should encompass ALL things that needs to be done in order to have a fully deliverable quality software.

What do you mean that you don’t have enough time to test the feature?

if you haven’t finished testing its NOT done. The same as if you haven’t finished integrating or you haven’t finished coding or you haven’t finished documenting…

Its only Done when its DONE. The fact that the sprint has finished and the team committed to this feature does not make the feature done.

Read more »

Posted in: Scrum

Tracking Actual Hours On Tasks

Oren Ellenbogen has posted a couple of weeks ago “Why tracking actual hours is so imperative?”.

Earlier this week I had a discussion with a VP R&D on exactly the same issues..

For me tracking hours on task is well useless.

But here are some of the things they said on why it is important:

• When people know they are being tracked they become more committed and dedicated to their tasks.
• We need to report on people performance to higher management and this kind of information is crucial to understand how people perform.
• We track times in order to verify how much is done on sprint related tasks and how much time is invested on other things.
• We track time in order to make sure that people are working enough time.
• its important to correlate story points/ideal days to calendar time
• In order to improve our estimation we need to track how good they were.
• We can use this data to approach the sprint planning in a more formal/mathematical way, resulting in better sprint planning.

All this are great reasons but here are some things to remember:

• Tracking this information takes time and effort – in fact the discussion all started with the VP saying he want to tweak hi ALM system in order to support a specific related scenario. which to me served as a warning they might investing too much time in this.
• Tracking this data sometime switch the discussion from what was finished, to discussing how much time it took to finish it. the difference between the two might seem minor, however for me become a more productive team is all about focusing on finishing more things.
• Agile and Scrum is all about the Team , we would like to establish a performing team and in order to do that we must focus on the team as a whole. Breaking down the team and tracking on the individual level is counter productive to this. At the company it was becoming quite visible that it everyone were really careful that everyone they worked on was credited to them. while this is not wrong,its more important that the entire team finish more things then a specific person having a “higher score”
• Estimation is not an exact science. To this date we have not managed to nail it. I’ve seen many teams become better at sprint planning when they opted to forsake the exact math and started planning in a more flexible. It still amazes me, but almost every time I see people get hung on the math, they just get it wrong. I believe that most people have a great grasp of what they can actually do once you take the numbers out of the equation.

but this in itself is not a reason not to track actual hours. still the benefits are really important. right?

well yes they are however in a Scrum process all the benefits are there. you just need to know where to look for them:

• one of the things i here many times is when doing scrum people get the feeling they are micromanaged. The daily meeting in which you tell the entire team what you have done feels a little too much. I agree. daily meeting is all the supervision people needs you don’t need to count actual hours in order to let people know that everything they do is monitored. if you really want to motivate your team just hand the sprint burn down chart above their heads. That’s more then enough to most people.
• Do we really needs to report on a personal level? do your CEO really cares who did what and how much time he invested in everything? in most cases the answer is no. You (as the team manager) might feel you need this information. Higher management just want to know you trust your team and that the team is doing well. Don’t let them meddle with your people nothing good will come out of it.
• this one is a little tricky, you really wants to know how much effort is invested in not related things, right? again wrong. in most cases ( and in this specific one) you have nothing to do about those things. those things had to be done and you just needed to do them no matter what. what you do want to know is how much time and capacity you had for the related things. and that can usually be judged quite accurately by just looking at what the team did accomplish. in fact, the specific team did try to extrapolate from this data how much time to allocate to “none sprint’ related but found out they really just couldn’t do it.
• making sure people worked enough? is that really an actual goal anymore? if that really important to you just use your place clock system and extract the exact time people were at work.
• Relating estimation units to calendar units is quite important, however that is achieved by tracking the team velocity. no need to duplicate the effort.
• Trying to improve the estimation is the only thing I think might be worth doing. However, i think that just tracking the tasks that significantly got a wrong estimation should be enough. and i expect a team to be able to do that in a sprint retrospect without the need to actually track this formally.
• don’t use Math when you plan, as i said its just doesn’t work as well.

Summary

I see too much emphasis is put on post mortem in a process. It is important to inspect and adapt, but for most team especially for teams which are new to agile and Scrum, The things that you need to improve are much much bigger then this. this is just sticking to old habits and old process, in which since planning was done on a personally level this kind of information was really important. channel your energy on how to get more things done instead of why haven’t we done well last time. finding productive ways to improve is more important then understanding why we were wrong in the past

When you transition to agile, just take a leap of faith and see if you can do without this.

Trust me you can.

Read more »

Posted in: Agile Principles,Scrum,tips

Managing a one man project

Ken Egozi asked me to put an answer I gave on the Alt.Net mailing list so here goes.

the thread started by someone asking for an online Gantt service and later evolved on how to manage a project without the use of a Gantt. the specific project is quite small - about 2 months total and will be done by a single person. however the client is pressured and want to be sure that it can be done by the specified target date.

Here's what I wrote:

If I were you I would start by:

write down in a list all the things need to be done (from the point of view of the client). not the technical 'how', just a list of things that define "what' needs to be done.

after you have your list, sort it by priority and roughly estimate how long each item is going to take you.

when you finish, take a step back and look if everything make sense, i.e. you can complete it in the given time.

Next step is taking the first month or so, and dive into details. plan out your next 4 weeks in details trying to figure out exactly what are the technical steps needed in order to complete every item on your list. (in most cases this kind of details does not interest the client, it is used by you to track progress and verify that you are on the right track). When you finish define your first milestone to contain all the items from the initial list you know you'll be able to finish in the first 2 weeks. (make sure not to over commit).

at this point you should notice that everything adds up, i.e. if for some reason after going into details things looks they are going to take longer make sure to reflect that back on the content of your project.

Now you can go to your client and:

1. agree with him on a delivery point/milestone every 2 weeks.
2. show him your commitment for the first 2 weeks.
3. show him a rough layout for the rest of the plan
4. agree with him that after 2 weeks you will review progress and update the plan as needed.

if you want I can email you an excel backlog template I'm using to track and manage my pet projects. It's build for this kind of management and might help you to put things in context.

Lior

What I actually described here is a very simplified Scrum process. In my opinion it will work in this context as is mainly due to the fact that this is a one man project (and a relatively short one). This simple version will most likely not be great for a bigger team.

I was also asked to put somewhere excel template that I would use for such thing. So here's a link to a zipped file containing simple templates for both a product backlog and an iteration backlog (which either of them can be used for this specific context).

Read more »

Posted in: ALT .NET,Planning,Scrum,tips

What Have we Learnt Today?

As usual during the Practical Scrum Course I’m giving. At the end of the first day I gather some feedback in the form of two questions I ask:

1. What was the most surprising thing you have heard today?
2. What is the most controversial thing you have heard today?

here are the (unedited) answers I've got this time:

The Most Surprising

1. How much client expectation can effect estimations
2. That in some projects a client can get a new version every couple of weeks
3. New approach to estimations.
4. That in 4 weeks we should finish X features (development, testing and documentation) and make them ready to be shipped.
5. Its important to leave room for “exciters” features.

The most controversial

1. Less documentation if at all.
2. Priority Poker technique
3. Everyone using a waterfall approach is following a “flawed" model
4. That “loaded” requirements document can cause estimation to increase
5. There is not enough consideration for the unexpected.

Read more »

Posted in: Feedback,Scrum

Open House – Estimations&Planning – Take 2

It appears that many have found this topic interesting, therefore we shall be conducting this open house one more time. it will take place on Monday, February the first at Sela offices. This event requires registration so if you are interested just leave me a comment.

If you wish to review the slides they can be found here.

Read more »

Posted in: Agile practices. Planning,Events,Scrum

What have we learnt today (last day)

At the end of the last day of the course I've asked two different questions:

1. What will be the easiest thing to implement at your company?
2. What is probably the hardest thing to implement at your company?

Here are the answers I've got (as is):

The easiest thing

1. Pair Programming
2. usage of Task Board (General purpose)
3. Stand up meetings
4. Creation of product backlog
5. Agile estimation Techniques
6. using Pair Programming to help bring a new team member up to speed

The Hardest thing

1. Automated unit tests/TDD
2. Division into Sprints (especially short sprints)
3. Locating people for scrum roles and creating a self contained team
4. XP
5. Building a true self contained team.
6. Pair Programming

Again almost no overlap of the answers (other then a few saying TDD /AUT is hard). I really enjoyed this cycle of the course, the people attending were really great and I would like to thank them for their feedback.

If anyone is interested in attending, next time will be toward the end of December. Just leave a comment.

Read more »

Posted in: Course,Feedback,Scrum

What have we learnt today/ (day 2)

On the second day I’ve added two more questions to the list:

1. What will be the be the most valuable thing to you?
2. What is the most useless thing you have heard so far?

Here are the answers I've got (again not edited):

The Most Surprising

1. A typical programmer manages 4-5 hours of ideal work per day.
2. The actual Scrum Master role in a Scrum process.
3. No hard delivery target (just an estimation), we commit
4. Priority Poker.
5. using Agile has brought companies to a defect rate of 1 per quarter.
6. that sprints can be 1 week long including planning.
7. that people can be involved/do tasks which are not in their main expertise area. (a QA helping a developer to estimate).

The most controversial

1. the SM doesn’t need to be a team leader.
2. The option for terminating a sprint.
3. a team which managed himself for a long period of time.
4. Vertical planning Vs Horizontal Planning.
5. a team leader should not be the Scrum Master.
6. sprint planning should take into consideration expertise of the various team members.
7. that the team allocate its own tasks.
8. no defined time for system analysis. no allocated time between sprints for turning the story into a requirement document.
9. That SM has no authority over the team.

The Most valuable

1. Techniques for estimations, task allocation within the team.
2. splitting the work into very short tasks.
3. Priority Poker
4. Vertical Planning
5. Group estimations
6. not using buffers.
7. the fixed sprint content that need to be formally approved at the end of the sprint.

The Most Useless

1. A manager should “keep” a private buffer and should be completely transparent with his team.
2. not allow people to multitask.
3. too much QA in the process (i don’t have enough QA people)
4. The Claim that “The Plan is worthless, Planning is important”
5. Team leader as the SM of a different team.
6. picking SM’s which are not team leaders.
7. that the team leader is not involved in the process of estimations which should be left to the team only.

What amazes me time and again that there is almost no overlapping between the different answers.

Read more »

Posted in: Course,Feedback,Scrum

Is Scrum good for me?

The second question i get form most people (after "Does it actually work?") is does the Scrum process good for me?

Mike Cohn has showed a great technique for evaluation which of the processes out there is most suitable for your project. you can find the details here.

Read more »

Posted in: Scrum,tips

What have we learnt today?

I've started today another round of the Practical Scrum Course. At the end of the first day I search for some feedback in the form of two questions I ask:

1) What was the most surprising thing you have heard today?

2) What is the most controversial thing you have heard today?

here are the answers I've got (not edited):

The Most Surprising

1. No true need for comprehensive documentation.
2. Estimations are done in units which does not represent time.
3. "Done" should be defined, sounds trivial but when one think of it ...
4. Agile can works for large groups.
5. Waterfall was presented as an example for a flawed process.
6. Scrum can be an appropriate process for most projects (90%)
7. Agile and Scrum, are established and well defined methodologies.
8. No Clear definition of who is the PO

The most controversial

1. Scrum can work for "Real Time" projects.
2. One of the goal of an Agile Process is to have Fun.
3. Velocity can't be compared between different teams.
4. Short iterations results in intensive management, in which we repeat many steps which lead to big overheads. (this is in response to the idea that short iterations are the bets way to develop software)
5. Stories should/can be represented by one sentence in the "customer language".
6. a process can work without "Requirements Documents"
7. Documentation is not needed.

Clearly there are some things I need to go over and refine again. However I also think that we are making progress.

Read more »

Posted in: Course,Feedback,Scrum

Practical Scrum Course

At the end of the first day in my Practical Scrum course I've asked 2 questions at the end of the day:

1) What was the most surprising thing you have heard today?

2) What is the most controversial thing you have heard today?

here's what I've got:

The most surprising

1) That even for the simplest "project" it takes 2-3 tries to reach a good way of doing things. (In response to an exercise we conducted)

2) That the waterfall methodology is an example of a flawed model. (taken from wikipedia: Royce was presenting this model as an example of a flawed, non-working model (Royce 1970).)

3) That so far the Scrum process is not that far from what we are actually doing.

4) That plans don't have to be too detailed, and paperwork may actually be less important then we think.

The most controversial

1) The claim that we are not good at estimations.

2) That we can start development without planning everything initially

3) That we can work (most of the times) in cycles of 3-4 weeks and give real business value to the customer at the end of each cycle.

Read more »

Posted in: Random Thoughts,Scrum

Scaling the PO team

Second session was planned to be another session with Alistair Cockburn however, he choose to ignore the official session title and instead he conducted an interactive activity demonstrating the power of iterative development and effectiveness of an adaptive process.

after that Ive joined a session focusing on the role of the PO in a scrum process and how to scale this position without damaging the entire process.

The role of the PO in a scrum team is to represent the client. the PO is responsible of maximizing the ROI, i.e. he’s the one responsible for generating $$$. Specifically the PO is in charge of grooming the product backlog, which includes among other, writing user stories, prioritizing them and keeping track on what is getting build. The important thing to remember is that this is an active role, stories are not invented from thin air, they are discovered by talking with users, customers and sometime even the developers. A good PO will actively manage the backlog, he will keep priorities straight, refine stories as new knowledge is gained, remove less important stories and add new ones.

The key point of being a PO which is sometimes missed is that the PO should consider himself as part of the team. When a PO works in disconnection from the team, things will usually not go smoothly optimal. For example while in the Scrum “rule book” the PO approves stories during the demo at the end of the sprint, effective PO’s do not wait for it. they actively review and approve progress during the sprint work. after all why wait?

Scaling the PO

But sometime one person is not enough to effectively cover all the responsibilities of the PO role. and the big question is how to scale that role. Like anything else there is not a single answer on how to correctly scale the PO role, each method has its own strengths and its own risks. the key for success like anything else in life is to always manage the risks and be on the lookout when things are not going as they should.

One way of scaling the Po is to divide the by area of responsibility. i.e. one person (or more will work closely with the customer) and one (or more) will work closely with the team. Another option is to split the work more naturally according to the product technical components. but no matter how the work is split its crucial to first achieve good communications channels between the people functioning as PO’s. Normally a PO team will much higher level of cooperation than other teams to succeed.

another tip for scaling the PO role is to adhere to agile values, i.e. always inspect how the team of PO function and to improve. It is also possible to use a modified scrum process in order to manage the work inside the PO’s team.

When not to Scale

but the most important tip of this session was when to chose not to scale. Sometime organizations are scaling the PO not because they actually need to, but because there's an underlying dysfunction which was not recognized. for example I've seen a PO which spent so much time in customer relations, that he didn’t have time to help the development team. naturally the team complained, and suggested to add more personal to the PO. Only after sitting with the PO and raising the team issues, did we realize that the PO did have time but he didn’t fully understands what was required of him.

So before scaling, take a good look, maybe scaling i not the answer. maybe just maybe there’s a better alternative.

Read more »

Posted in: Events,Scrum,Team System