Agile Pitfalls

I must admit, I really don’t get some of the scrum “naming” conventions. First of all, what’s the first association  you have in mind when you hear a word scrum? What I imagine is a bunch of big guys, heads down, bottoms up, pushing hard. And Scrum Master? Sounds like a guy you need to obey, not really a service guy as you read in the role description. And then how about calling iterations – sprints? What was wrong with iterations? To me, software development is more like a marathon than a short sprint, unless you can run 400 sprints at once…

picture by © Chris Frazer Smith

Either because of the chosen names, or because of the of the way scrum was originally defined, there are few problems you might get into:

  • Having standup meetings where people report to the Master (if you see guys in the standup circle always looking at the same guy while talking – you have a problem)
  • PO playing an aggressive customer role and pushing folks into DemoDrivenDevelopment Mode (see one of the previous posts)
  • Team forgetting the big picture, with emerging design ending up in no design
  • Team replacing heavy waterfall planning with no planning (how often have you heard of “flat backlog?)
  • Developers feeling constantly under pressure, getting exhausted after “400 sprints”, not having time or energy to play or read

One of the biggest issues with agile introduction is the confusion people have between roles of the scrum master and the project manager. One needs to remove the obstacles in front of the team, while the other one needs to provide the planning to the stakeholders. From the moment that role is shared by the same guy, it is hard to avoid situation in which people see the Scrum Master as the Master. Be aware of that. That’s all I can say. The longer you work with the team and more trust you earn, the easier it will be to combine these two roles.

When it comes to the planning, this is a hot topic, and in my next blog I will explain how I do it. There are plenty of books around, and this time I will only recommend 2 blog posts:

And how about creativity and motivation? Ken Schwaber said once: “Scrum is like your mother-in-law, it’s constantly pointing out your shortcomings.” (for the record, I love my mother in law). It is true that we need to learn from the feedback, but it can as well be tiring and boring – even more if retrospectives are done too often leading to the same conclusions. In one of my previous posts I touched upon this topic “How to do Lessons Learned“, and unless really necessary, I suggest you don’t do them every iteration – you better go for a beer with the team and celebrate if you’ve done something great.

One way of embracing creativity is to introduce “Fed-ex” days. Atlassian folks today get all (TED) credit for it, but as far as I remember, they were not the first guys to try it out. Fed-ex approach is a great way of enhancing existing application with some cool features, or sneaking a new language or framework you want to try out – but you need to be careful there and avoid “pattern-happy” people abusing the concept.

So, put your rugby jersey on, heads up and be ready for the fun, the field is rather muddy first time you try it out.

Posted in Agile|Agile, blog | Tagged | Leave a comment

Fighter jet, toothbrushing and agile rituals

When I am in position to talk about the topic that is so “obvious” to me while struggling to find the right words to explain it to the others, I often escape in metaphors, looking for inspiration in nature, other people quotes or anecdotes. Agile philosophy is one of these topics, as it has truly become part of my nature – or it probably always was. When I start talking about it, I very often find myself in kind of schizophrenic mood: saying that agile is a flexible but strict discipline at the same time.  At first, it looks as agile methodology is full of controversy, probably because it insists on practices that look conflicting at first sight:

  • It requires strong discipline of all members while it claims that it is a flexible methodology
  • It requires empowered teams and strong leadership
  • Some people (who actually don’t do agile) compare it to a cowboy coding although agile movement has brought so many novel testing practices

So, the real question is: How to find the right balance between stability and agility? 

Let’s start with my first metaphor for tonight:

The new generation of fighter jets have one design feature in common. They are designed unstable, which is intended to increase agility.

High stability and highly effective flight controls are therefore incompatible requirements. In stable aircraft a compromise has to be made. However, no concessions need to be made in unstable aircraft.

Any pilot will find it very hard to control an aircraft like this without assistance. A computer (“fly by wire system”) is needed to provide necessary stability.

Practices such as standup meetings, iterative development, continuous integration, pair programing, TDD, serve as “fly by wire” system in agile. Although most of these practices should be applied to any methodology, there are crucial to agile, without them agile can’t fly. 

Great, it is all good and settled, so let’s check how it goes with one typical agile team during retrospective meeting:

What was I thinking first time my mother asked me to brush my teeth? I can’t remember, but I don’t think I really enjoyed it. Toothpaste doesn’t taste that great and rubbing your mouth with a toothbrush is not that exciting. While I still do it, I don’t think about it any more (unless I try to write some silly blogs) and that is why we call such activities “ritual” behavior: you do some things not really thinking about how and why you do them.

When you start working, no matter where, on no matter what, there will be things you like to do – aaaaand other things. The same is true for other people around you, sure about it. You may say: hey, hold on a second, how about motivation? Isn’t it all about autonomy, accountability and stuff like that? People will just do it, give them some space, right conditions  and things will happen, no? Well, noooo. Doesn’t really work like that – always. You see, some people confuse motivation and toothbrushing, and this is not the same thing. Your job as agile manager is to do both things, keep people motivated and engaged, and at the same time, sometimes, annoy people by asking them to be consistent. That is most of the time hard with things that they don’t like, part of the job that is not natural to their nature. In that case, motivation really doesn’t help, you need to use some other tricks, or like I put it here: “If you want to keep the ball rolling, make sure it is ticking.” In order to create a ritual behavior in the group, you need to do two things: make the outcome of the activity clear to everyone and fix the frequency when this activity is performed. So, let’s see how to do it:

  • Make the goals clear to everyone
  • Make sure everyone understand his/her part in the big picture
  • Give people space, autonomy and accountability (don’t ask folks to play piano with handcuffs around their wrists)
  • Make the checkpoints visible to everyone – such as percentage of the code tested, the number of bugs found in time, logging of activities in tools (in case you have multi site)
  • For each checkpoint define the activity and fix the frequency at which you want to review the results
  • Check the outcomes
  • GOTO 1

 

Tip: you can use the same methodology if you wish to loose some weight or prepare for the next year marathon. 

Posted in Agile|Agile, project management | Tagged , , | Leave a comment

How to deal with Grey Swan event

In this post, I will be talking about one important role of project managers, and that is, what to do when things are not that great. But before that, let me tell you one little story. When I watch football penalty shootout on TV, I really don’t know who is going to score the goal, but I am very good in guessing who is going to miss it. When I see a player approaching the ball with his face telling you “I must not miss it”, I am pretty sure that the guy is going to miss the goal. Similary, if the eyes of the player who is taking the ball are telling you “I am going to score the goal”, most likely, the guy will make it.

Similar things happen in project management. I have seen too often project managers trying not to miss the ball, making project plan look like long distance excuse thing. In that fashion, as soon as things turn ugly, as they often do, the first task of such project managers would be to find an excuse. The strange thing though, this is the last thing people expect from you.

There is also another important thing you should remember. Higher you go in the hierarchy, people have less time for other people’s problems. Therefore, when your project is hit by a grey swan, think for the moment and come up with the following slides to your boss (this is one of few places where I believe slides are useful):

  1. Define the problem
  2. Explain the impact of the problem
  3. Give a plan of what you think should happen next
  4. List all dependencies of your proposal(s)
  5. Tell what you need from your boss to make it happen, if required
  6. Say what will happen if nothing happens
  7. Tell your preferred choice and explain why
  8. Give a date by which you need a decision

In my previous post, I talked about some of situations in which your project will certainly get in trouble. The last thing you need then is to get in panic, look for excuse and let other people manage your team and your project. Stay cool, prepare few scenarios and then knock at the door of your boss.

Now, it’s time to fix the team

Your job is not over yet – you have only defined your grey swan and don’t think that the problem will be resolved by itself. Now it is time for the next phase – get the job done. The first and the most important thing to remember now – you are on the stage like in Shakespeare play, and people will look at you. You need to stay calm and consistent in your messages. Your team needs that. There will be pressure building from various directions, but you must keep your team in isolation and let them do what you ask them to do.

And now, it is time to fix yourself. Everyone else is busy.

How to deal with pressure – or “Fake it Till You Make It” approach

Grey Swan events are usually remembered by the number of meetings, and no worry, if you have forgotten them, you will be reminded. There is only one thing you should do: go back to your first slides and stick to your message. Patience is the mother of all virtues. The most stress and frustrations in your job come from actions directed to things you can’t influence or from a feeling that things go too slowly. If your team needs a week to test the fix for concurrency bug, or if the rollback to the previous platform takes 2 weeks, this is what it takes. If that means coming every day to the same meeting and repeat the same message, so be it. “Fake it till you make it” is mantra I very often think of in these moments. Or as William James put it once:

“Act as if what you do makes a difference. It does.”

Posted in project management | Tagged | 4 Comments

Grey Swan and Chicken Run

The trigger for this blog was the recent bbc article ”Black swans’ busting IT budgets” that you can find here. The article starts with a fact that one in six big IT projects go over-budget by an average of 200%, more than in any other industry. What got my attention was not that figure but the proposed remedy for it, which you can find at the end of the article: “Managers are very likely to run into black swans. They need to be able to identify them and prevent them”. Oh, my God…

So, let’s start first with Taleb, and his famous book Black Swan. In his retrospective about the book in this New York Times article, he made a nice summary of what he ment by Black Swan event: “First, it is an outlier, as it lies outside the realm of regular expectations, because nothing in the past can convincingly point to its possibility. Second, it carries an extreme impact. Third, in spite of its outlier status, human nature makes us concoct explanations for its occurrence after the fact, making it explainable and predictable. ”

What often you can find in the management books about the risk management is one rather simple formula: Exposure to the risk  = probability of the event * negative impact of that event.

To be frank, that is all you need to know about the risk management: you create a plan, make list of all issues that you THINK need your attention, sorted by the exposure, make the action points register, and regularly monitor each item till you finish the project. This is not Black Swan management, this is a simple risk management tool – and it always works (for what is supposed to remedy). That combined with iterative development, which deals with other risks such as changing requirements is what most of the agile teams do these days.

What I liked about the article though, was that it recognized the fact that this approach is not good enough, and that the biggest problem you will encounter in IT projects are often the ones that suddenly happen. So, what we can do about it? We can do something, but definitely not plan for uknown, this is rubish.

Let’s first try to define types of Black Swans that I have encountered so far. Here I am walking on a slippery road, since unknown events are of course of the unknown types. So, I will call my swans grey swans (see picture below). I think this can get me out of the trouble…

  1. People leaving the team: It often comes in waves where more people leave at once, and it can be either result of the bad management, HR policy, new sexy start-up in the neighborhood… In one of my previous posts, I have proposed few ways to look into this problem. The most important thing though, no matter how it happened, you have lost the most valuable part of the project – people who know how to run it. When this happen, you need to staff new team members, train them on the product, which will obviously keep the rest of the original team busy as well. To the outside world, nothing is really happening. Therefore, you as the project manager, might be called into endless meetings, where people want to see actions, while the only thing you can ask for is patience.
  2. New framework/platform failure Any time you introduce a new database version, application server or similar platform upgrade, you really need to be careful. The first thing to do is to run few spikes and test technology, check what other people say about these products by reading blogs and forums and go over your maintenance contracts with 3rd parties. Even when you believe that you did everything necessary, be ready for surprises. And if happens that you need yet another upgrade, or rollback to previous platform, you are in trouble. Therefore, you as the project manager, might be called into endless meetings, where people want to see actions, while the only thing you can ask for is patience.
  3. Nasty bugs, I mean really nasty bugs There are only two things certain in your life. You will die one day, and your application will have bugs. But here I am not talking about any bugs, here I am talking about concurrency bugs, almost random bugs, the one that come and go, the ones that leave complete team in disbelief, the ones that challenge your atheism and make you read stack traces on your blackberry. Therefore, you as the project manager, might be called into endless meetings, where people want to see actions, while the only thing you can ask for is patience.

Chicken Run

If you don’t stick to this message, and let other people manage your team and project, every day there will be more crazy stuff, till everyone runs around like a chicken. Chicken run trajectory is the one in which chicken in any given time slot completes always the same distance and always in random direction (unlike frog from the previous post). Therefore, the only effect of doing ’emergency actions’, escalations and quick fixes results in more troubles. In my next post, I will talk about things you need to do when you are hit by the grey swan – how to provide a proper feedback to the management, how to deal with your team, and most importantly how to keep yourself sane and healthy.

Posted in project management | Tagged , | Leave a comment

Jumping frog syndrome

One day, one smart ancient Greek guy discovered something very disturbing: If you have a frog that jumps every time half of the distance that it jumped before, even after infinite number of jumps, the total distance covered will never exceed twice the distance of the very first jump. At first, that really sounds confusing and counterintuitive, and unless you try to draw these jumps on the paper, you would not believe it (OK, you probably had something like that in maths when you were 12 years old, but who still remembers that stuff, no?).

To me, this example is troubling for two reasons: first, it makes infinity pretty hard thing to swallow, and secondly, it does tell you how sometimes your initial instinct can get you in trouble. Yet, I see frogs jumping around in that fashion way too often, hoping that they will get somewhere.

In software development, the distance you cover in the first release is most of the time the longest. I would argue, whether the application will get you the first customer or not (and for many start-ups that is one time chance) is not that much question of the clean code, as much is about someone willing to spend money for it. What makes you a business is the next release, and the one after this one … This is where the jumping frog story gets tricky. If you don’t keep the code clean, let others cutting your corners, start patch hell with quick fixes, your jumps will get ever smaller, till you find yourself not moving further, though you feel like doing infinite effort to get somewhere.

If this little story somehow resonates your situation, please read one of my previous posts 

 

Posted in project management | Tagged , | Leave a comment

Demo Driven Development or “Strange Case of Dr Jekyll and Mr Hyde”

Once upon a time there was a software development methodology called waterfall. People disliked it for many different reasons, but today I will only mention one in particular – that it was hard to see anything working, before it was too late.

So, people turned to agile development, delivering business value in increments, during complete project life-cycle, after every iteration. Although Agile Manifesto says quite few things, most of sales guys and PO’s remember only single one: there will be a demo every week or two: and then you hear them saying: oh, yes, yes, finally!!!! Even better, we can finally show something to the customer, get a feedback, bring it back to the development and in the next iteration show the new stuff again… Fantastic, great, beautiful. And it really is. But… there is a catch. Mr Hyde is coming….

What often happens is that agile teams are too focused on development around demos, since this is the only way they are getting evaluated outside of engineering. Obviously, more you show every iteration, assumption is that this team is more productive. Finally, rather than keeping eye on all aspects of software development, team might start making too many shortcuts, leaving dirty hacks and famous //TODO comments all over the place (if they still feel like doing it).

Just as a test, try this in your project, go to the root of your source directory and try this one liner: find . *java | grep -v todo | wc -l

First time I typed this command on my project and saw the number, I almost dropped the coffee on the floor. At first I was surprised, then felt angry, and then betrayed. After all, all these guys who left these traces behind were my good friends and colleagues, and they were excellent coders, just brilliant. So, how was that possible I wondered? Why would someone add reminder and never come back? Was this a message to himself, or to the next guy, like if you go to the toilet and read graffiti on the wall, or was it some kind of subconscious mea culpa sign?

And then I realized – it was me, it was mainly my fault. It was me who always pushed to the limits, who was too much into demo thing… And this is what happened:

Every day, Dr Jekyll would come into to the office and write something fast and dirty, and since he read the book “Clean Code”, would leave the trace behind him, as a reminder to come back later and clean the stuff. At the end of the iteration, Mr Hyde would suddenly arrive, show a demo, write down the feedback, erase the memory of Mr Jekyll that there was something still //TODO and move on again.

So, you may wonder how it all finished for us? Well, we were quite experienced group and we knew when something was really bad. If we couldn’t stand the code smell any more, or if it looked impossible to add a new feature without having a brain damage from trying to figure out how actually existing stuff worked, we would go back to PO and announce that we had to do “big re-factoring thing”. And most of the times it worked out, but unfortunately, sometimes it was too late – we rushed too much.

And finally, this post would not be complete, if I didn’t have 7 rules of how to avoid DDD (Demo Driven Development), so here we go:

  1. Be fast, but not crazy
  2. Review the code – always
  3. Have time to come back, some things are never 100% done (life is never perfect, so it is with some “done features”)
  4. Avoid re-factoring tasks, ask folks to refactor while coding
  5. Not everything can be done between demo’s – some features just need more focus and different planning – more about that in another post
  6. Never ever design API/SDK/NBI in increments
  7. Never add a feature that is half right (notice, I am an optimist, I didn’t say half wrong). Half right is always wrong.

 

 

 

Posted in Agile|Agile, blog, product management, project management | Tagged , | Leave a comment

Project risk management and HR policy, a new way to look at it together

It looks as the software development is one of the most risky activities on this planet. I can hardly think of any other profession in which the focus on the risk management is so embedded in a daily practice of making things. The reason is rather simple, unlike in any other (engineering) profession there is no real hard science that gives you a comfort that the project will ever succeed. In construction business, projects might go over budget or might be late, but you have hardly ever heard of a bridge collapsing because of the “minor glitch”.

Obviously, software developers are not any better or worse than other engineers, but our ability to mess the code, applications, deployments and projects in such variety of ways is something so unique to software projects that makes people to think and write about the risks in our craft all the time. TDD, code analysis tools, pair programming, code reviews, continuous integration, automation testing, stand-up meetings, iterative development … all these techniques are there to provide us with a fast feedback about the project status on time – before the crisis happens.

Today I would like to add one more technique in to this toolset, the one that I borrowed from the belief network propagation models, my other passion, next to software development. This is how I got to think about applying this model in the first place:

One thing that troubled me for quite some time was how we evaluate people in larger organizations. It turns out that the formula is rather simple, and it is based on the following question: “What would be the damage to the organization if that person leaves”. At first, it sounds as a reasonable question, till you ask yourself another question: “What would have been the damage to humanity if Einstein had died as a child?”. That is what I call possible negative impact vs. possible positive impact evaluation thinking. You may wonder what this has to do with risk analysis in the software development? Well, everything actually.

But before I continue, let me draw you a graph of a software team using belief networks: one application is developed by 6 developers, which work on 3 modules, and if one of the modules breaks – application goes down. In this model, person 6 is the only experienced developer (modeled by prior of doing correct things 99.9% of the time). Other developers have priors of doing things right “only” 99%. Without any observation, you can see that the probability of applications working while people coding is less than 70%. Since person2 works on two modules at any moment in time, he is the most “risky person” – (noted by 0 in the circle).

Let’s consider the same project from another angle. We are going to keep the same model, the same priors, with only one important difference. This time, I will consider that one module is healthy if at least one developer is doing the right thing. All the rest is the same. This time, I am not interested in knowing whether the build gets broken or not, but how many people I need to keep the project alive. Suddenly, the weakest link is person6, although his performance is 10 times better than of the others (have you heard this number before?).

So, here is the thing. The way you consider development strategies in your project is not only the question of being an optimist or a pessimist (although it helps to walk around with a smile on your face).
For instance, if you have relatively inexperienced team and your assumption is that everyone potentially can mess the code, you probably think it terms of possible negative impact exposure, and adopt the first model. In that case, only few people are allowed to “touch” the core of the product – by introducing architects and team leads that verify all checkins or something similar. Penalty you pay is a less flexible development model, modular ownership that bottlenecks development, less engaged team members and the fact that if the key people leave, the project is doomed. On the other side, projects are easier to “control”. This is a typical model that you can find in large multi-site (off-shore) projects. That is also the reason why in larger organizations, “possible negative impact” HR policy is a dominant one, since you do care a lot about the “checkers” – people that own the features or modules.
On the other hand, if developers work on different modules while implementing features, people are more engaged and you have fewer bottlenecks. The risk of project failing because of one guy is leaving is less likely. You can also witness quite some different development dynamics after a while, what Michael Feathers calls “emerging design”. This model of project management requires professionalism of all team members, and unfortunately, sometimes this is too much to ask. In companies and teams that strive to this model, “possible positive impact” is much more important than a negative (thinking). These are the organization that truly believe that people are “allowed to fail” – as long as they tried their best. Some people call this agile development model.
In reality, you have mixture of both. It is hard to imagine that in the bigger projects people do not develop either preference or expertise in some particular part of the product. Therefore, it is always a fun to create such diagrams on your project and try to figure out where the most troubles you might expect – when it comes to development/application or HR dependencies.

Finally, I would imagine that it would not be that hard to build this graph from the SVN or GIT, where you would analyze checkins per user per component and the number of broken builds to build graphs with some priors. I hope to do it one day and publish my findings in some future blogs.

Posted in Agile|Agile, project management | Tagged , | Leave a comment

People before process – and what does it mean for agile manager?

Only recently I came across Jurgen Appelo’s blog and then I read his book “Agile Management 3.0”. I also went to his course and had some time to chat with him as I needed someone to talk about people management in agile context. Although his book goes even further than that and primarily focuses on complex/system theories or theory of everything 🙂  – since the guy is really ambitions, I did recognize someone with similar experience and similar ideas.

The thing that bothered me for so long was how many books, blogs and agile gurus are around repeating the same mantra about how agile is great, story points and similar stuff, and how few of them talk about real issues – related to managing people in agile environment. In the past few years I have read so many of the same thing (just in another format)  that I became sick of it. More over, I have start seeing more and more of agile bureaucrats – true reminder of a great idea first time I came across in the book “Crossing the Chasm”:

So, here we are, 10 years later, and plenty of late majority making fun of agile (by being so serious). So be it. Nothing to fight there, except to add few blogs like this one, written by early adopters and crazy people – that is who we are. That’s why I have started this blog and why my first blog was about people.

So, let’s go back to agile managers. Agile managers are responsible for creating environment in which people can perform, enjoy the work and create something of the value to the company and humanity (yes, no kidding). Agile folks know how to do their stuff, but sooner or later they need someone to talk to about their career, about their performance (although peer recognition is all that counts), about salaries, lousy coffee machine and so on. Agile managers also need to step in when things turn not so great, when arguments are too loud or when the team goes to extreme. Agile managers are service managers. Agile managers are not managing papers, specifications and roadmaps alone, agile managers must be good in people/soft skills. Not everyone is good at it and nobody is great in it – unless you read, try and ask for the feedback too.

So, here is my advice, take some books that talk about people management. I have already mentioned Jurgen’s book, it is great way to start, and I also recommend few more, such as “First, Break All the Rules”, “How to Win Friends and Influence People”, “It’s Your Ship: Management Techniques from the Best Damn Ship in the Navy”, books from Drucker and so on. Once you start reading, you will know where to go. Also, try to play some team sport, if you have never done it before, that helps too. Try to take some course in soft skills, there are quite few courses around,  it is not agile folks who invented a need to have motivated professionals.

Finally, I would recommend one simple model to start with, called DISC model {wikipedia}

The assessments classify four aspects of behavior by testing a person’s preferences in word associations:

  1. Dominance – relating to control, power and assertiveness
  2. Influence – relating to social situations and communication
  3. Steadiness – relating to patience, persistence, and thoughtfulness
  4. Conscientiousness – relating to structure and organization

People with high “D” are very active in dealing with problems and challenges, while low “D” scores are people who want to do more research before committing to a decision. People with high “I” scores influence others through talking and activity and tend to be emotional. Those with low “I” scores influence more by data and facts, and not with feelings. People with high “S” styles scores want a steady pace, security, and do not like sudden change. Low “S” intensity scores are those who like change and variety. Finally, people with high “C” styles adhere to rules, regulations, and structure. Those with low “C” scores challenge the rules and want independence and are described as self-willed, stubborn, opinionated, unsystematic, arbitrary, and unconcerned with details. {wikipedia}

For people who went this far in reading, here is the price – link to this great pdf file from my favorite blog – how to handle people from different groups in one simple schema, great stuff. If you find time, please listen to their podcasts too. By now, you should know how to manage Chuck Norris, no? Let me help you a little bit, he is for sure high D and  low S and C. So, here is a little test: how you tell Chuck Norris that his last change in the code has broken the build? Here is a little quiz and you need to select the right sentence:

  1. “Chuck, when you break the code like that, my test manager is so upset that he goes home right away and takes few pills to fight depression “
  2. “Chuck, when you break the code like that, the team thinks that you have no idea what you do and they even might think that you are such a loser”

One last warning, people are much more than mix of 4 letters, so  please don’t take shortcuts, always read, do, ask for the feedback, read, do, ask for the feedback… Hmmm, sounds like one of Jurgen’s models, just forgot which one, and I am sure I missed few steps, have hard time remembering any model that has more than 3 … But then again, I know the book is somewhere around, so let me check one more time.

 

Posted in Agile|Agile, blog, project management | Leave a comment

Do you need Chuck Norris in your team?

If you want to test whether you have Chuck Norris in your team, how about checking this blog post first. If you recognize someone in the team that fits this description, congratulations, this blog post is for you. Chuck Norris is really a lethal guy, and you should distinguish first whether your hero is only good in applying destructive force, or he is also trying to make any  good in the process of writing the code. One thing for sure, you have a guy with a great ego – and if you decide that the guy is worth trouble, you need to learn how to handle him (and don’t tell him that, as Chuck Norris doesn’t give a shit about management).

Before I continue, I would like first to say few things about myself and similar personal experience – not in software engineering, but in handball, which I start playing professionally when I was only 15 years old. When I was a kid playing handball, I had an idea that I can only trust myself, and when it was very important part of the game, I would simply take a ball and try to score, not thinking that much what other guys were doing (or thinking). One day, my coach came to me and said something that sticked to my mind to this day: “You know kid, if you continue to play like that, I will break your neck. But (and here is the funny part), if you don’t think that you are better than others, you will never become a great player.” And this is indeed the fine balance that big coaches need to manage every day in successful teams. In that respect, agile development is not that different from handball, it is a team effort where different people have different talents and you need folks that are willing to take a risk and score the goal.

During my career, I learned that there are two types of coaches. In first group are guys that I labeled as “Russian style coaches”. These guys would hate heroes and would ask every team player to surrender his imagination and personality to the benefit of the group, and then you would have team performing like a swiss clock, but just it was so boring to watch…  These teams had no Chuck Norris. And then, you had some other teams, where you would see fun, imagination and style. These were the great teams that we all remember. And occasionally,  you would see these great teams going loose, where internal fighting and argument would bring the complete team to the meltdown.

So, the question whether you need Chuck Norris in your team or not depends on two things. First part of the answer is about you, not him. Are you ready to take a risk and invest your time to get best out of him? That requires a lot of stamina and knowledge – and I will cover this in my next blog post.

Secondly, and even more importantly, not all projects require imagination and people looking to make the next big thing. Some projects just require pure execution, like a swiss clock.

 

This post was

Posted in Agile|Agile, blog | Tagged , | Leave a comment

How to organize lessons learned sessions

What is lessons learned? It is a bottom up improvement: you invite people to give their feedback on the quality of the work they do and the problems they face during product development. Final goal of the lessons learned sessions is to create a better working environment and enable the team to be more effective in future projects.

Unlike top down approach, this one is much more engaging and therefore needs to be done very carefully, as people who are involved in this process get more emotionally involved and expect much more from it in return. That also implies that it will work only if people have trust in facilitator, other team members and the complete process.

Phases of lessons learned:

  • preparation
  • data gathering
  • data mining – split issues in categories
  • identify problems and list actions
  • find owner for each action and agree on expected outcome
  • follow up on actions

Preparation

The best place to run the lessons learned sessions is everything but office. You should find a place where people are not disturbed, phones should be switched off and no laptops allowed. Announce the lesson learned session at least few days or weeks upfront so that people can think a little bit before coming to this session.

Data gathering

People should give their opinion on good points and things that need to change. The process of collecting this information depends on few things: whether people trust the facilitator and whether people feel comfortable to speak openly. Another very important remark, issues might be either technical, or social. People are more willing to speak openly about technical problems, such as lack of hardware resources, slow or lousy tools, than about things that are related to personal relations. Before you start the session, facilitator needs to be prepared in order to react and navigate discussion in constructive manner.

If the facilitator is the “boss”, that can only work if they trust him (meaning they know him for a long time and they can say openly everything) – there is an old joke “tell your boss the truth and truth shall set you free”, so never forget this… If that is not the case, you better ask someone externally to lead this process, best would be HR.
How you should collect the data? If people can speak openly, you just need two white boards, and people simply speak loudly and facilitator writes it right on the boards – good points on one board, and things that need to improve on the other one, the order is not important. In case that people for one reason or the other are not that free to speak (I can write a long post on this topic alone), you can ask them to write down all that on the paper, facilitator collects it, reads it loudly and write it on the board. You can as well use stickers, since it is easer to move and group them later.
So, your data is there, on the board, and people will start thinking about all of that. Let them talk and argue…

Data mining

The first thing team needs to do is to find problems that belong to the same category. Once the team has agreed on different categories, depending on the team size, you should assign task of suggesting solutions for each category to several groups. Each group should have not more than 4-5 people so that everyone in the group gets his fare share of time to say something. Of course, one group can try to address more than one category of problems.

For instance, the team and the facilitator can group topics into categories such as lab issues, coding guidelines, office setup etc. For each problem, every group comes with suggestions how to fix those. Once all groups are finished with analysis, let them present solutions to the complete team, till there is a consensus on all actions.

Identify actions and the owners

Facilitator lists all actions on the board and ask who would be willing to own each of the actions. For every action, the team needs to discuss proper set of activities, expected outcome and date at which improvement is required.

Follow up

This is a hard one. People are good in talking, good in analysis, but very often very lousy in being consistent. If you really want to make a change, you need to be very good at this. And somehow, we humans are not good in this. The best way to do this is to already provide checkpoints in time, and you meet with team at these points to assess the progress. You can use one of the kick off sessions to quickly go over the status. Tip: if this is not your first lessons learned session, before you do the next one, check how many actions points you have closed from the previous lessons learned session. What you will find very often, unfortunately, is that some issues pop up all over again…

You should do lessons learned sessions after every major release of the product, or at least once every 6-8 months.  In agile methodology, there are also scrum retrospectives. These are specific lessons learned sessions, and they are primarily focused on issues related to the current development. These sessions, to large extend can be seen as activities that are related to technical bottom-up short cycle fixes. I advice people to do them as well, next to lessons learned sessions.
One last comment. Try to change things that are feasible to change. Many times people waste their energy talking about issues that they are beyond their control. It is great to list them, you might want to escalate them to people that can do something about them, but don’t assign them to folks you know can’t make it.

And don’t be afraid of hearing people complaining (unless it is always the same guy). Only people who are motivated and engaged will always want to remove obstacles that slow them down.

Posted in Agile|Agile, project management | Tagged , | 1 Comment