Technical Debt – Will hit you 3 times

“Look, it’s critical that we meet our deadline, and I know that we are already running behind. So please, we need you to push faster no matter the costs. And I don’t care if you need to cut some corners on the way. I’m totally aware of the costs, we just need to meet the goals for the deadline and after that we will have more time, to go back and fix what’s needed”

Sounds familiar?

Funny enough this kind of conversation have been happening to me on many of the projects I’ve worked on, usually on several occasions. And to be frank, I totally understand where this is coming from, and I’m also aware there are times in the life of a product that this is exactly what needs to be done.

What I did find is that, even if stated otherwise, many seem to be quite unaware of the real costs involved in such a move. So let’s try clearing those up a little.

Technical Debt – Will hit you 3 times

The first time you get hit by technical debt relates to the subtle fact that organizations usually like the reckless speed a technical team can go at. Once the team stop doing many of the things that needs doing, suddenly, everything seems to be going much faster. And after a few weeks of showing an increased productivity, everyone starts believing that this what we should expect.

Wrong – what actually happens while we are working in such a way is that we are digging holes, and when you find yourself in a hole, first thing to do is to stop digging. That is, the first thing the team needs to do is get back to working the way it should and do everything that needs doing. Still, from the outside, the perception is that suddenly everything is slower. Even though we are just back to normal pace.

Try it next time you watch a talk on YouTube. Increase the speed to x2 for 30 seconds. Revert the speed to normal. It now feels that the speaker has some speech impediment. But the impediment is actually with the viewer, who needs to readjust to normal speed.

Technical Debt – will hit you 3 times

The second cost involved, is the one that many grasps as the only cost. The cost of going back and fixing what needs to be fixed. You took a loan by skipping out on a few things, you need to pay it back and do them, it’s as simple as that. If, for example, you didn’t write test automation for new code, you need to go back and write it.

Technical Debt – will hit you 3 times

And last, but not least, is the “interest” involved. Like any type of loan, a technical debt also incurs an “interest”. Yes, once you start cutting corners and compromising technical standards, more mistakes tend to creep in and over time the need for dealing/fixing those things will also take an extra cost. For example, let’s say, that for the sake of speed, a piece of logic was duplicated instead of properly refactored to a single shared place.  Now, every bug or change in that logic needs twice the effort to get done. Not to mention the chance that someone may forget to fix both places and now you get another new bug to deal with.

The Numbers

Ok – so 3 times, what’s the issue with that? It’s just going to cost me a little more, I probably won’t be able to notice it anyways.

Let’s try looking at some numbers. Let’s assume that for a period of 8 cycles (weeks, sprints, months or whatever) the team has decided to take a loan of 10 “units of work” which allows them to go 10% faster (again it can be days, hours whatever). And let’s take the number of 10% as our interest rate.

Side note – Some may argue that 10% interest number is too high a rate. Personally I think its quite a conservative number.

Here’s the table showing the loan performance over these 8 cycles:

Cycle 1 2 3 4 5 6 7 8
Total Debt . 11 23 36 51 67 85 104 126

Note – after just 8 cycles, the interest alone (46 units), is going to cost about half of the base loan amount (80 units – 10 units per cycle).

Ok now what? Now comes the hard part of deciding how to pay back this debt.

One strategy is to just stop everything and pay the debt. In our example, it will take about a cycle and a third. Since the overall capability is 100, in one cycle the debt will drop to 25, add the interest to that, and we need almost a third of the next cycle to pay the rest.

However, in most contexts, that’s not something an organization will do. Stopping everything is not an option and there’s a need to repay the loan gradually over time (like most other types of loans). The underlying logic usually goes like this: If we got a 10% increase in speed over these 8 cycles, let’s go 10% slower and after 8 cycles the debt will be paid.

Sadly, it’s not that simple. First, 10% slower from the current state just bring you back to normal pace (first hit). So actually, in you want to pay 10% of the debt, from the organization perspective, it will feel about 20% slower than current state. Second, since now the overall debt is 125, the interest alone (third hit) is more than the payment itself of 10 units.

Actually, in order to close the original debt (second hit) in about 8 cycles, you need to pay 20 units per cycle (30% slower from organizational perspective, compared to current speed) and then the debt left will look like this:

Cycle 1 2 3 4 5 6 7 8
Total Debt . 116 106 95 82 68 53 36 18

What does it all mean?

Not much. Mainly it means that taking a technical loan is a risky business, and it helps to be fully aware of the implications of doing that. Be aware that a 10% speed increase, implies that you will need to go ~30% slower for about the same amount of time. Be aware even that is assuming you don’t do it for a very long time, otherwise interest tends to explode:

After 11 cycles in our example the overall debt reaches over 200 and going 30% slower pays off just the accumulated interest alone.

And finally, while crunching numbers is always fun, in a real context, you usually don’t have the ability to control or even quantify the debt you are actually taking. In addition, in contrast to a loan from the bank, with technical debt you don’t get a balance sheet, or a forecast of the accumulated debt. You don’t get to see the real interest rate either.

When the team is told to run, they run as fast as they can. It doesn’t take that long time reach the point in which just paying “interest” causes a reasonable team to feel like it’s going in circles. Whenever you can give your team enough slack to prevent unintentional debt from creeping in. and pay your debt as early as possible.

Do You Need a Scrum Master?

“A good Scrum master can serve a few teams. A great Scrum Master will serve only one”.
rephrasing Michael James

There’s an ongoing debate on whether a team needs a full time Scrum master for the long run or not. Many teams feels that the duties of SM only fills a part of his day, and therefore he can do more than “just be a Scrum Master”.  In some cases the expectation from the SM was to pick up tasks like any team member, in other cases the SM was working with 2 or 3 teams in parallel, and in other teams spread the roles of the SM between various team members (and not having a dedicated person as the SM).  And there are of course many more options.
and honestly speaking, all are valid solutions that can be really effective. What I did learn over the years though, is that no matter how you approach this, you should always keep in mind the following when you decide on how to approach this:

Every team need to dedicate time and invest effort in deliberate improvement

No team is perfect, that is the underlying assumption. Therefore, every team can and should improve over time. And while at the start it tends to be easy (well, relatively), as time goes by, it will become harder and consume time. When a new team starts its learning journey  the challenges and issues the team faces are usually easy to spot (given the team is not in denial). In fact, in many cases those are the elephants in the room.  As the team learns to deal with those issues, (which will take some time), new things will rise and hold the team back. However they will be harder to spot and deal with. In many cases these problems correlate to some deep underlying organizational behavior which may be really tough to change. To continue to improve, the team will need someone who will actively seek opportunities, think about possible solution, encourage the discussion about them and follow through on the actions the team takes. In the rush of regular work, most teams will neglect this, so they need to find a mechanism to guard the effort and make sure that deliberate improvement will be practiced.

In order to improve you will need to know and understand the team dynamics

In theory improving should be easy. For every issue encountered, you think of a few options that should help. You design some experiments around them, execute those experiments and see how it goes. When this process is repeated enough times, for any given problem, some good solutions will most likely be found. As simple as that sounds, in my experience it’s actually very hard to do. There are so many forces involved in the work of a given team. Carrying even the simplest experiment requires a lot of attention. After all if it was that easy all agile teams would become great. Sadly that is not the case. A team is a complex system (within a bigger complex system- the orgnaization), it is essential to invest time in really understand the context in which the team works. It’s important to know the team members personalities, it’s important to know their strengths and skills, it’s important to be aware of what goes on in the organization, and its important to understand the other forces in play. All of that requires time (and skill) to do. In order to become effective each team will need to invest the time in truly getting to know himself..

To continuously improve a team will require some new skills

Developers, in general, have a specific background and skill set. Naturally, their training is focused  on skills you need to posses in order to build a product: write code, test, design, understand and write requirements and so forth. Understanding process issues, helping people learn and improve, provide feedback, following up on experiments, understanding cause and effects in a complex environment, are only a partial list of the skills needed to nurture a learning inside a team. and that is before we add all the skills you need to have in order to deal with the human factor (the people involved). It’s not that these skills are particularly hard to learn (few of them are), it’s just that most developers don’t have a specific need or inclination to learn them.  So they don’t. To become an effective team you will need to acquire all these.

And, You will need patience

So do we really need a full time dedicated person for this?

Maybe yes and maybe no. Maybe for you it will be more effective to spread this between the various team members. or maybe there’s is this special someone who is really passionate about doing all this. You will need to decide on your own.
No matter what you will decide, I do know that to succeed, you need to intentionally invest time and effort in this. The people doing this, will need to develop some new skills, they will need to understand the team context, and they will need to dedicate a significant chunk of their time for doing all this.

Maybe you should start by letting one person start doing it.
In order to help people understand and learn some of the skills involved at being a SM, we will designed a full dedicated week filled with learning. The event will take place on the last week of June (starting on the 25th to be exact). It is a combination of 5 different workshops (one day each), where each workshop is focused on a different skill you need. you can sign up for the entire week, or just to the workshops that you are interested.

If you feel like you want to improve at being a SM, check them out here

Should Testers know how to program? (version 2.0)

Back in 2013 I published the following post, but since I know, no one actually read these links I’ve chosen to quote that post in full. Sadly enough I still get that question way to often to my liking.

MUST TESTERS KNOW HOW TO PROGRAM? 

One of the most common question that arises when talking to testers in an Agile context is “Does testers have to possess programming skills in an agile team?” For a long time my answer to that was no, since testing includes a vast number of activities which doesn’t require programming skill there will always be room for testers who can’t program.
However, I think that I was mistaken. These days I would expect anyone who claims the title of a professional tester to possess some level of programming skills.

Testers who cant program are obsolete.

This fact can no longer be ignored. As automation gains a firm hold in our industry a tester must be able to significantly contribute to all automation effort. And while certainly one can contribute to this effort without knowing how to program, the room for these is relatively limited. Yes, even 10 or twenty years from now our industry will still have a large number of testers who can’t program. The same way that even today there are still professional Cobol programmer or programmers who can’t do object oriented programming. But I would expect that this will be the minority.

Testers who cant program – CATCH UP

If you want to stay valuable in the market, start learning the basic skills of programming today. No, I don’t think you will need to become an expert top notch developer (not that there’s nothing wrong with that). The actual skill level required in order to become a productive test automation engineer (i.e. significantly contributes to automation effort) is lower than that. But Unless you will start to acquire these skills soon you will find very hard to find new open positions.
Here’s an interesting post that backup these claims with some concrete data.

And while I don’t consider this in any way as scientific proof or even big enough to indicate anything with significant statistical confidence, it still suggests that ~80% of testing job posting indicated a programming skill as necessary. Also notice, this post was published as early as 2010. My personal observation of recent job ads, which is certainly skewed towards Agile culture, suggests that the percentage is even higher.

So what have changes since 2013?

As I said, not enough.
However I do start to notice one subtle change in tone.
In 2013, (and this is purely relying on my own personal memory) some teams when talking about automation, while admitting that it sounded nice and valuable, still weren’t 100% sure that’s automation fits them. It was still considered as something that you can do without. These days when I encounter new teams which are not fully engaged at automation I detect a slight tone of shame. They don’t challenge the fact that automation is crucial, they just say that they don’t know how to do it. some blame the organization not allocating enough time, and some are still puzzled at how to approach that.

So to me there is still progress

What can you do?

Another change is that more  knowledge on proper automation is generated  and made widely available. In fact towards the end of the month we are opening our own special program aimed at helping manual testers make their first steps to learn how to automate (if you’re interested press here for more detail). Given time I expect we will see more and more similar programs being available (even locally).

And what can you do? well I don’t know, but if you are interested in these matters and have any kind of idea on what is needed, or what will help people to bridge this gap. let us know, just leave a comment down below .

Revising Estimation

Many teams feel the need to go over finished stories and update their story points in order to reflect the amount of effort needed to complete them. The general notion is that it’s a good idea to fix the original estimates in order to reflect the “true” velocity of the team. Which later on will result in better estimates.

However, as much as this sounds reasonable, actually doing this is counterproductive.

and to explain that we first need to go back to the basics and understand better the purpose of velocity tracking and the entire estimation process.

Velocity

First the definition (taken from Agile Alliance website)

At the end of each iteration, the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity. Knowing velocity, the team can compute (or revise) an estimate of how long the project will take to complete, based on the estimates associated with remaining user stories and assuming that velocity over the remaining iterations will remain approximately the same. This is generally an accurate prediction, even though rarely a precise one.

reading this definition its important to notice that the notion of “Productivity” isn’t mentioned at all. And indeed using Velocity to measure a team productiveness is a misuse of the metric, Especially if one tries to compare team based on their velocity data. The reason for that is that the actual numbers are actually controlled by the team itself, therefore it will not be an objective

Ask yourself this:

If we have one team with a measured velocity of 20 and another with a measured velocity of 40? does it have to mean that team B is working twice as fast as team A? Or is there a chance that team B just gives larger estimates? in order for him to be true the estimate of each team needs to be normalized to some sort of standard unit of measure, and both team need to conform to that unit. Usually that is not done.

how about this: if a team Velocity has just increased from 10 to 20, does it means that the team has become twice as productive?  Maybe the team (consciously or not) is just encountering some difficulties in getting things done and react to this by increasing the estimates given to the same tasks (I’ve seen hat to happen) while still more or less competing for the same amount of work.

Velocity should only be used as a predictive tool. It’s a good technique for extrapolating how much a team can finish in a given amount of time helping to answer how much work can be finished in the allocated time (or how much time we need to allocate). This is based on two assumptions. The explicit one is that the velocity of a team will not change drastically in the time frame we have. And the hidden one (which is important also understand) is that most teams while are bad at estimating, do tend to be consistent about that. That is, a team, in general, will either overestimate or underestimate (or average out) but will do the same for all stories. So if we actually measure the team velocity and leaves the estimates as is, we can actually find the error factor in the team estimates. and can safely extrapolate how much work is going to be finished.

Changing the Past

So going overt past estimates and “fixing” them is actually counterproductive. once we do that we break the hidden assumption of consistent error. Estimates for the finished stories are now reflecting an error factor caused by our ability to track past information (i.e. know how much effort was invested in stories) And future stories reflect a different error factor (i.e the accuracy of the team estimates). In most cases those two are not the same. (I think it is reasonably safe to assume that teams are better at tracking effort invested than at estimating future work).

So no. revising past estimates is not a good idea.

Reflecting on Estimation Errors

All that being said, I do think that reviewing estimation errors is very useful. In fact. I suggest for teams to periodically (every 2-3 sprints) invest some time during retrospect, focus on a few (3-4) stories the team estimate was very far off and do a root cause analysis. The main goal of this practice is no to get better at estimation but as a general improvement thing. As it happens stories with very wrong estimates, hold the highest potential for learning. A wrong estimate is usually caused by some sort of a very unexpected thing happening. it can be caused by something new the team encountered, something unexpected that happened, or just something the team failed to recognize during the initial planning. In any case, whatever is the cause, it is always an excellent opportunity for learning. Maybe the new things actually represent a new technology that the team needs to learn. Maybe the unexpected things are caused by changes in the context which are going to repeat themselves and therefore require some thought on how to deal with. Or maybe its just things the team needs to learn to pay attention to so they won’t get missed. The nice thing is that when the mistake is big, it’s usually easier to pinpoint its root cause and therefore easier to learn and fix.

So remember it is important to reflect over your past trying to learn from it. But as always trying to cover up your past (estimate) mistakes is less productive.

If you Want to Scale up – Use Small Stories

Much has been written about the importance of working in short cycles, and the need to cut and slice your stories to small pieces that will fit inside of a single sprint. I’m not going to repeat all this.

What I would like to write about is something that might seem counter-intuitive at first and it goes like this:

The bigger and larger the project you are working on, the smaller your stories should be sliced.

Yes, if you are inside this huge enterprise working on this big and complex project along with several other teams, your stories should be extremely small.

How small? about a day or 2 worth of work.

That’s the only way to achieve a constant flow of working software. Everything else you are trying to do will become much harder unless your stories are that small.

Let’s go over an example:

Let’s say that you have a few teams, and since we are talking about a real project (and not the ideal everything is just the way we like it) the work of the various team is not totally independent. It’s not that all features requires integration between ALL teams, but in many cases features span two teams and sometimes more. So the teams have decided that they need to catch up at least once a week and make sure everything is working ok together.

Sounds reasonable.

So, for Tuesday (that’s the day the team chose for integration), all the team gets ready. They finish all open issues, and make sure all the features they worked on actually work. They start the integration but Oops, something goes wrong and something doesn’t seem to be working. After a short investigation, they locate the suspected area, (yes it’s in Team A code), but in order to find the cause, fix it, the team needs to go deeper. Naturally the other teams not wanting to waste time, start to work on new stuff while waiting for Team A to fix this. After a day or 2 Team A finds and fixes the problem, but now there’s a problem, the other teams moved on. Their current state is not good to do integration, so they wait till Tuesday to try again.

And guess what’s happening on Tuesday? Right, since they try to integrate more work, the chances that something breaks is even higher. and indeed not everything is working,  only this time its team B. And in the following Tuesday its team C and so it goes on until someone notices and calls for a stop.

This scenario lies at the roots of the familiar “code freeze” mechanism. Since, it’s hard to do proper integration while all teams are working in the background. We need them to stop, and only immediate issues found in integration and other found bugs. The only problem is that for the teams being in code freeze feels very wasteful. Most managements will only tolerate this state is short and doesn’t happen too often. Once the Code freeze is long, everyone will feel the pressure to move on to new stuff. Which in most cases only makes the freeze longer and wastes even more time and effort.

So that’s not a good idea, what else can we do?

well another option is using source branches – but Ill save you the entire rant on those – these are not a good option (if you want you can read here, here and here about those)

The Benefit of Small Stories

The effective solution for this, is working on smaller stories. if you manage to get your stories small enough, you can do the integration more often, instead of once per week, maybe 3-4 times a week. And even when things do break during integration, chances are that since we are working on such small items, it won’t take so long to investigate and fix. if it doesn’t take too long, so the other team maybe will be able to wait for a little until we do manage to locate and fix. And even if it does takes more time (maybe a day or two). Once this gets resolve we can try integrating it again almost immediately.

Remember principles 1&3:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Want to learn how to create those small stories?

on December the 25th we will be conducting a workshop for Agile Product Owners, join us to learn techniques and tools for creating an effective backlog.

for details and registration go here

Don’t forget to organize your teams

When you start out an agile transition one of the first things you should consider is the move from component teams based structure into feature teams. I like the following definition:

A feature team is “is a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one”, taken from  http://www.featureteams.org/

However, feature teams are not the norm. Most companies have created their teams by separating different functions into different groups (Product, Analysis, Programming, testing,…) and then based on size, they split those groups according to an area of expertise, which reflect the product architecture, (Infra, Back End, Front End,…).  Changing this structure to one based on feature teams requires some “Motivation” if possible at all.

The Trap of Component Teams

So other than the obvious statement of “you need to move to feature teams if you want to succeed at your agile process”, what else is there to know about feature teams. Why do component teams find it hard to function inside an agile process?

While there are a few reasons for that, I find the main cause is simple:

When you work inside a component team the work you are doing is actually never finished inside the team.

In most cases,  a single team member handles only part of the work. When he finishes his part, the work is either passed to another team to continue or integrated with work done on different teams (sometimes by a third team) into the final product. The final product is then tested and approved by the QA (Fourth Team). Technically, this means that as the work progress, the original team member is becoming less and less involved, to the point of him not being involved at all.

Is This Bad?

Of course it is. It lengthens the cycle time.

Naturally, as the programmer gets less involved, he has more time and will take new features to work on. In turn, this makes him even less available to support the ongoing integration of the“older” features. And when his help is needed, he will need to “find” time for it. Usually he will be in the middle of something else and will not drop everything and help (people hate to be interrupted). Therefore time will need to be scheduled for that. Later. And everyone either waits (less likely) or finds something else to work on and before you notice it the need to get everyone together at the same time, will result in Special “integration time” to which everyone agrees to meet together and “integrate” the new work. Did someone say “Integration phase”?  And since it is needed from time to time, why not plan it ahead, in fact, let us allocate integration time for all our new features.

Another thing that tends to happen gradually, is caused by the fact that teams are not perfect and not always finish all the work inside an iteration.  When that happens, normally, those pesky integrations, tend to be postponed to the next sprint. By then, since we are going to do integration anyway,  it looks much more efficient to combine several of them together… and you know where this going to end, right?

Let’s also consider the fact that team members who are less involved in the later stages of development find it harder to see the “big picture”. When you pass your work to another to integrate your ability to see and understand the entire system is smaller. You don’t see the entire system work together that often, you tend to interact with “end users” much less, and understanding the actual business domain also becomes somewhat twisted. That is a very big problem.

And if that’s not enough, when I worked in such a context, I found it very hard to work as a real team. Even though I worked with others in my area of expertise, the fact that I was constantly pulled to help outside the team, interfered with my ability to coordinate work time with my teammates. Since that happened on a regular basis, we all found it much easier to just split our work in a way that minimized our interactions. That way no one had to wait for someone who got pulled away in the middle. Another very big problem.

Moving to feature teams

Working inside a feature team tends to help with those aspects, Since those teams are in charge end-to-end, the majority of integration and testing is done inside the team, and the ability to collaborate and continuously work on a feature from start to end increases. You are less likely to be pulled away and synchronizing everything becomes much easier.

In fact, feature teams are an essential ingredient for scaling up an agile process. (If you only have one team, it’s a feature team by definition). The more teams you have, the more important it is to reduce the number of inter-teams dependencies and that is usually possible only with feature teams.

However, that’s not an easy move, I’ve been involved in too many failed transitions that failed due to the fact that the organization was not willing to make such a move. If you find yourself working in such a context,  we would still like to make small incremental changes in that direction (and hopefully will reduce the problem on the way). So here are a few tips:

  1. Make the goal of gaining more knowledge on the system, product, and domain explicit.  One way to do that is to have everyone involved in customer support. Another way,  is to make sure each member leads some significant integration preferably not of his own work.
  2. Encourage team exchange – maybe restructuring the entire company is not possible, moving some people from one team to another is always possible (at least for a limited time). Yes, it might not look very efficient at times. But the knowledge gained and the reduced effort in cross-team synchronization will more than compensate in the medium-long term. If possible, try to move people to other functions, team – not only from back end to the front end team but from QA to a product, from programmers to QA, etc …
  3. Focus on teamwork – generate real dependencies between people in a team. This can be done in the way of shared design activities, doing peer reviews, or just work together. When people depend on one another, they will have to collaborate and work together. Don’t allow teammates to work as silos in a team.
  4. Remove Pressure – And last, if we expect people to be involved in later stages, they need to have the time to do that. Intentionally free up the time for this. Don’t be tempted to pile up other work while “they wait” encourage everyone to get actively involved. And again while this may look at times to be inefficient, it tends to be more effective on the whole.

In the long run, people need to see and be involved throughout the life cycle and until their work gets truly done, feature teams are the most convenient and effective way to do that. It does not mean however, that if you cant move to those, there’s nothing you can do.

Stop Scaling Start Growing

Scaling agile seems to be a very hot topic these days, with the introduction of several techniques and frameworks that aim to help you achieve that.

However, too many management teams jump ahead and dive into the various frameworks without first asking themselves the most fundamental of question:

Do we really need to scale?

Recently, several of my meetings with new organizations started with:
We are a very successful growing company and we already have grown by XX% and we plan to increase in size by YY% by the end of the year
where XX & YY are in the areas of 30-40%. It then continues with:
Yes we do have some issues and we are totally aware that what worked for us so far will probably stop working/need change. How can you help us?

Which kind of making me think about why companies start this growing up adventure when, when clearly they are not ready for it just yet.

So, if you are managing a growing team/Group/company, here are some things you might want to consider:

The need to do more

The main drive for growing up is the simple need to just do more. The natural state of any company is “growing”. The minute we get into a state in which the current team is functioning more or less ok, or when the product seems to be quite successful, we instinctively try to grow. it’s a basic business assumption, Companies that don’t grow shrivels and die. In fact, it’s so ingrained into our DNA that it’s the most natural thing we think of. The problem is that growth in size is not always a smart move. Throwing more people at the problem will not always help. Brooks Law told that to us about late project. But even when we are not there yet, increasing our size is never a trivial process.

Maturity before growth

My youngest daughter started to walk quite late, in fact, we got quite worried and started to consult with doctors about it. The general answer that it’s quite common for tall babies to start walking later and since she is very tall for her age (in the 99%) we just need to wait. The same holds true for organizations, if you grow in size beyond your maturity level you will have issues “walking”. A statement like “we know that things we did so far will not work” which is not followed by “but we know what we need to do” is in any case a good indication of that. Hiring more people will most likely cause things to just move slower, which will naturally increase the need to hire even more people which will just make everything even worse.

Growth Capacity

Another thing to consider is the growth capacity of a team over time. Using Tuckman Stages of Group Development terminology  we know adding more people to a team takes it back to earlier stages. For most teams adding just a single member means there’s a period in which their speed will decrease until they get back on tracks.  If you add another in that time, the decrease will become even more significant and I suspect the effect is not linear. try to add a third member and most likely you will just create a dysfunctional team for a very long time. What’s more, for some reason It seems that this is never to see that reflected into actual plans. While management acknowledges the fact that new people are not productive in their first weeks, the fact that introducing a new member disrupts other members’ work is just ignored.

Sometimes Less is More

what is better having two small teams (3-4)  or one big team(6-8)?

while there is no simple answer, in most cases we do know that there is definitely an overhead the minute one switch from a single team mode into working with multiple teams. In most cases if we only consider the short term and we don’t need to grow beyond this, a single bigger team will be more productive and effective. The downside, is that a there’s a limit to how big a team can grow. above 8-10 members things just get too hard to manage.

Do we really need to be big?

In this blog post Ron Jeffries talks about SAFe, in the section about “SAFe Fundamental Assumption” he describes assumptions that I encounter inside and outside the context of Agile. People want to be big (the basic need for Growth) they like to work on the big and complex system (basic need to feel important) and sometimes this makes them ignore the simple truth that while they are “Many” they are no “big”. What looks like a big company working on a big system is actually a collection of small systems worked upon by small groups that may or may not need to be in complete synch.

But we NEED to do more

I agree trying to get more done is always a goal, however if I quote Ron Jeffries again:

Finally, many of your multi-team projects can turn into single team projects once you get your teams competent in really doing Agile Software Development. You don’t need to build a big process because you don’t have a big problem any more.

We can see an alternative:

Before you start increasing in size, Get you team really competent in developing software. In some cases that will be enough, and even if not. before you do that you are just not ready to grow

Dealing with Technical Stories

One of the first thing they tell us about stories, is that they should be valuable.  That’s what  the ‘V’ in INVEST stands for:

Taken from: http://en.wikipedia.org/wiki/INVEST_(mnemonic):

V – Valuable – A user story must deliver value to the end user.

That suggestion usually sits quite well with business side people, which nods in agreement when they hear this, but generally raises a few skeptical eyebrows over at the technical side of the room. Which soon turn it into the following question:

So how should we deal with all the technical things that we need to do and have no direct value to the end user? Things like replacing our DB technology, working on infrastructure, or building some inner development tools?

A very good question indeed.

What is Value?

The first thing we need to understand before we tackle this question, is that  value can take two main forms:

  1. Value can be linked to things which increases revenue, and
  2. Value can also be linked to things which decreases costs.

Once we agree to that, we can see that “regular” stories usually falls into the first category of value. As we add new functionality to our product, it is capable of “solving” more business problem for our end users, which in turn are willing to pay more for our product. Or maybe that new functionality opens up more markets we can sell to. In any case, by adding more functionality we hope to increase our revenues. Technical stories on other hands usually fall into the second category. Most of them can be linked to some sort of “saving” either in our development process or directly to the costs of operating/using the system. For example, investing in our logging infrastructure, usually helps us developers in locating and fixing bugs, reducing the costs involved in fixing them (and yes I know it’s always better to avoid those). Investing time in setting up a one click deploy mechanism reduces the cost of rolling out versions to our customers which again saves money.

When dealing with technical stories, the trick is to try and quantify this cost reduction. Once we do that, prioritization is made easier, and the question of what is the value of those stories goes away.

Technical Debt

However, there’s another common type of technical activities that teams are turning into user stories. Those activity’s main goal is to reduce the technical debt in our product. Just a quick reminder technical debt has been term referring to all the things which we (as a team) know that we should have done in the past but for some reason decided not to do. For example, things like cleaning up the code, writing automated tests, improvement in system design, are typical things teams tends to leave for the future and starts to address them once they understand they can’t be postponed anymore.

Ron Jeffries made a strong case for not putting those on the product backlog (Refactoring – Not on the Backlog)  and I totally agree with him. Normally, technical debt should not be turned into user stories and managed on the backlog, reducing debt should be an ongoing effort. However, many of the teams I see are just not there. They first need to learn how to do this continuously refactoring while working on other stories, and for that to happen they need to allocate time for learning. Putting stories in the backlog  is one way to help them secure that time. But be warned, adopting this temporary solution as a long term strategy is risky. It is usually not enough and it opens up the door to accumulate even more debt with the thought that later on it will be turned into stories.

In any case, dealing with these kind of stories is a little more difficult, their direct “value” is usually less visible. Even if we treat it as a cost reduction it’s very hard to convince the business side that the value in rewriting parts of the system that currently works is big enough for the effort involved, and in many cases on its own it’s not. But here I would like to suggest a third kind of “value” and that is the value of learning. The real value of stories related to Technical Debt is that by allocating time for learning, not only we can reduce the amount of debt in the system, the team also learns how to avoid those kind of mistakes in the future. And that can be priceless.

If you also struggle with using stories to manage your team work, or find it hard to prioritize between all the things that your team needs to do. I want to invite you to attend our Agile Product Owner Workshop in this advanced workshop we deals with various issues related to managing your backlog. The next workshop will be on the 18/9 and you can register here

Image by Anja Heidsiek from Pixabay

Scrum Master and Leadership

Taken from the Scrum guide:

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters
Do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those
Outside the Scrum Team understand which of their interactions with the Scrum Team are helpful
And which aren’t. The Scrum Master helps everyone change these interactions to maximize the
The value created by the Scrum Team.

So Here’s a question: Is the Scrum Master (SM) a leader?

Clearly we know that the SM is not a manager, he has no authority on the team, however, it clearly states the “SM is a servant leader for the team” so naturally he’s a leader.

Lately I’ve encountered too many people assigning too much responsibility to the SM. For example, we expect the SM to help the team grow, to help them succeed at their sprint goals, to help establish the process and on and on.

Now don’t get me wrong, I really think that a good SM can really make an impact and help the team become so much better, but I would say that about any other member of the team. so lets take it from the beginning:

The SM is not the team leader

Many organizations adopting Agile and Scrum find it hard to grasp the concept that Scrum roles do not define and managerial role. Ideas like self management, shared responsibility are hard for them to understand. After years and years of growing up hierarchical based divisions. The simple idea that smart people are more than capable of managing themselves is simply too much to handle. (At least at first stages), so the natural move for them to make when transitioning to Scrum is nominating the various team leaders as Scrum Masters. Reading the description of the SM role, and the various activities is supposed to carry out, it really sounds like something we expect a good team leader to perform. And indeed in many case team leader transitions into the SM role quite well.

But sometimes they don’t, Sometimes Team leader is so used to telling other people what to do, that they naturally continue doing so. On the other side, the teams are so used to having a team leader telling them what to do that they continue looking up at the SM expecting him to provide answers – and eventually he does. Resulting in some cases ending up at the same spot we started in. Instead of having a team of responsible people self managing themselves with the help of a the SM. We get a team managed by the SM (ex team leader) going through the notion of the scrum. Making it so more difficult for the SM/team leader to actually manage the team. (Remember, he has no formal authority)

The SM Does not have to be a leader

Some, however move beyond that. They understand that the SM is not a manager, and model the role as some sort of leader to the team. And again this makes a lot of sense, having a good leader as the SM, can do great things for the team. The leader will naturally help the team do his job, he will help them resolve problems, he will manage the expectation of the organization and more. One thing he usually won’t do, and that is make the team learn how to manage without him.

Good teams don’t need a scrum master

The best teams I’ve worked with, didn’t need a designated SM. They just did the work. They didn’t need anyone to babysit them and tell them what to do. They knew what meetings they need to schedule and schedule and attend. They managed to conduct their own meetings, and they found out by themselves what worked what didn’t. They just did the work.

They met on a daily basis, shared information, when issues were raised, some one took the responsibility to handle it. And whenever work didn’t follow according to plan someone volunteered to notify the rest of the organization. Funny enough, it wasn’t that hard for them.

So lets put the SM role back into proportion.

It really helps having a good Scrum Master. If he’s a good leader great.

But if not, so what?

Ask yourself, do we really want the team to be led? Or do we prefer them leading themselves?

Is This All?

No. I would like to invite you to our upcoming Scrum Master Week. We have designed it to help Scrum Master catch up on everything they need to know and learn to become really effective

Image by Ribastank from Pixabay

Managing Without Authority (Things they forgot to tell you at Scrum Master training)

“Congratulation, we have decided to become Agile and in order for that to happen, we have nominated you as the team Scrum Master. Next week you are going to a two-day training that will teach you everything you will need to know about Scrum”

Sounds familiar?

Going to a Scrum Master training is a first good step, however, expecting you will become a “Master” of anything at the end of a two-day course, is, well a little unrealistic to say the least. I’m not saying that these training are not valuable. On the contrary, they are very valuable, but they are not enough. Most likely they will focus on the what and will leave you to figure out the how.

For example, one of the first things they probably teach you there is that a “Scrum Master has no authority over the teams”. They are expected to serve the team, by helping it to tackle and remove obstacles, by facilitating the various meetings and in general try and lead the team into a better place.

Great. But, how? How can a Scrum master control things when he has no Authority over the team?

Stop Telling

The truth is that the SM is not expected to control anything his role is to help the team. However, in most organizations he will be looked upon as some sort of leading figures, partly because of his special role, and partly because in many places the new Scrum Masters are picked from the management layer.

What they don’t teach you in these training is how one can lead people even in contexts when he has no authority over them.

The first thing one needs to let go (especially if you are an “ex-Manager”) is your habit of “telling” people what to do.  While in many contexts you can actually do that, being some sort of manager, in most cases that will be counterproductive. In order for a team to become hyper-productive, it is necessary for him to assume responsibility for his work. Relying on someone else (manager) to tell the team what he should do well in most contexts prevents the team from assuming ownership.

Build Trust

To get people to cooperate with you, you need to earn their trust. Trying to lead people who don’t trust won’t work in the long run. People won’t follow someone if they are not feeling comfortable doing so. They resist everything he suggests or asks them to do. So it’s absolutely important that you as a scrum master invest time in earning and building that trust.

Here are some things I found important when I try to build people trust in me:

Be reliable

People stop trusting those who don’t do what they say they will do. To earn someone’s trust, you need to make sure that you don’t do that. It’s crucial to honor all promises made, even those small ones (which you might not realize became a promise at all). Try to minimize the times you fail to follow up on what you said, and in those cases, you do fail, don’t be afraid to admit to it. Then you apologize and lest you try to fix it. A common defense mechanism for failing to deliver is belittling the act. Try to avoid that. The other person might put the great significance of the promise and by belittling it, he might feel you are belittling him

Be Honest

Tell the truth. Even when it’s not so pleasant, being frank and direct sometimes helps to deal with uncomfortable situations. When people recognize that what you say is your absolute truth, it is much easier for them to trust you. If you do happen to lie (which I’m guessing everyone does eventually) admit to it. Denying a lie is just another lie. And last don’t forget to expose your feeling and your mistakes.

Be Open

Share information, don’t hold facts for yourself. Make a mental effort to supply more than enough details, and don’t start omitting things. People will notice those little contradictions and eventually will consider you a liar. If someone, for example, asks your “how did the meeting went” a wrong answer is: “it went fine” a better answer is “it was ok, we discussed A and B and C, we argued over D and E and decided F,G, and H”. If you need to keep secret, let it be known. People will respect you better if you say “I’m sorry, but I can’t share those details about the meeting.” and will stop trusting you if they find that you are withholding information from.

Be Respectful

Yes, you are the Scrum Master,  and maybe know more about some things than others, maybe you have more experience, or maybe you just understand better. Still, no reason not to be respectful. To everyone. The minute you stop respecting someone you will lose his trust. And most likely another will be wary of you as well. If you are disrespectful to him, how will I know you won’t start disrespecting me?

Start Asking (for help)

One of the best alternatives I have found for “telling” people, is asking them for help. As a consultant I use that a lot. For example, in one of my recent projects I needed the team to update their build cycle to include unit test execution. It was perfectly reasonable for me to go ahead and tell them to just do it. However, knowing the current, pressure, I  knew that telling them will cause a discussion about who will do it, how much time it will take, what’s the priority of that,… (that is a 1-2 weeks until it gets done). Instead, I just approached one of the team members told him I need to update their build cycle and asked for his help. The answer I got was: “you know what, if you give me a day or two I will just do it myself” – mission accomplished.

And that I found is a common pattern with most people, when you ask someone for his help is solving YOUR problem, they are much more willing to cooperate and assist them if you try to make it their problem. (Of course the guy could always say no, and left me to do that alone, but even when that happens, most people do try to make sure that you are not stuck which ends with things getting done faster)

Is this all?

Of course not, leading people is an art form, and this is one of the subjects being researched and investigated in many fields. Some people have a natural talent for it, some don’t.  But everyone can improve. The best Scrum Master, I’ve see recognized that and invested the time and effort to teach themselves.

If you also feel that the basic training you have received is not all of it. And are trying to learn more techniques and tools that will help you become a better Scrum Master, I would like to invite you to our upcoming Scrum Master Week. We have designed it to help Scrum Master catch up on everything they need to know and learn to become really effective

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 do the same thing just smaller. Like this:

See where this is going?

I encountered several contexts in which a company, after getting some basic knowledge about Agile, seem to think that they are already mostly Agile, and what is 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 in 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 now. Doing a mini-waterfall isn’t necessarily a bad idea.
On the Pro side, we can say the following:

  1. Mini-Waterfalls are 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 kinds 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 are some kind of an iterative cycle so you will get more feedback.
  2. Working in short iterations has been just different than working in long cycles.
  3. If you don’t do the needed mind shift, working with 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.  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 process. 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 discussions 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 you are half way there.  Best option at this stage is to face reality heads on. Stop pretending you are Agile. You are not and it’s 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 from them. Each and every pain is a place in which something new can be learned, 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 affect your 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) requires a new way of thinking to make it work. Most likely old solutions won’t solve these new problems.

Scrum is not a process

One of the most common discussion that always seem to pop up again and 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 not equal, each has his own set of skills and ability and treating them as equals will not work.

And although in many cases, those arguments 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 succeed. 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 to create a product at the 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? Let’s 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 your 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 there a lot of hard work involved. They start with using Scrum and expect that all of their problems will go away. They read the book follow everything that is written there with the best of their 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 seems to be really hard, When a team starts using Scrum all kinds of problem 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 end up in their old process (and then the claim that Scrum has failed) or they end end up somewhere else that technically looks like 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 states 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 than 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 scrum 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 forever 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?

Image by Pete Curcio from Pixabay