Apr 10

To Scrum or not to Scrum

hamletA good colleague of mine came up with a good idea. Or better said, a good mindset. For a while now in Scrum there is something known as Scrumbut. It’s like the Pino in Prince2 (Prince in name only). We Scrum….but.. and then the excuse why you are not fully doing Scrum.  “We are doing Scrum but only do the daily standup, the planning is done by the project-manager” . I know of a lot of companies and teams who do Scrumbut. They only do a little cherry picking and avoid the more challenging parts of Scrum. “Yeah we do a weekly standup” or “We do sprints of six weeks” and so on.

A lot of people are doing Scrum but only do a few things. They think that it will work. Scrum has only nine basic things you need to get it running. These nine things (three roles, three artifacts and three meeting) are needed to get it to work. Every single one of these nine scrum things has a purpose. It is there for a reason. If you leave them out, your Scrum-process might not work and you get Scrumbut. Now why is this dangerous? When a company is doing Scrumbut and it does not work, they immediately blame Scrum. “Yeah we did Scrum but it did not work for us.” But when I ask such a company why it does not work, I get all the wrongs and hear the stuff they did not do. So that’s why my collogue said. You either Scrum or you don’t. And even if it looks a bit like you are doing it. Don’t name it Scrum. Call it something else.

It is all about an image and a mindset. If you do it right you can name it what it is. If you are doing it just partially it is something else but not Scrum or scrumbut or scrum-almost-doing-it.

So ask yourself the question. Can you say the words with you head held high. To Scrum or not to Scrum, that is the question.

Thanks to Rien Walraven of Centric, credits paid where credits due.

Permanent link to this article: http://agilethings.nl/to-scrum-or-not-to-scrum/

Apr 05

The Agile Concerto

Earlier this week I was at the Effenaar in Eindhoven for the first show of The Jam Sessions by The Kyteman Orchestra. It caused a severe case of professional deformation in my head: for me this show is the ultimate agile concert. And it was great!kyteman

Let me first explain the concept of this new project of former control freak Colin Benders (aka Kyteman): a team of 20 good musicians comes on stage with a mission to entertain the audience (in this case 1200 people). They have not rehearsed any songs, they have only built and rehearsed their framework of cooperation. By pure improvisation they create new songs live on stage.

What I specifically like about the framework, is that the string section has a completely different way of working than the horn section. They are both doing what works best for them.

Kyteman himself plays the role of conductor, mostly by giving some general signs, thereby both facilitating and channeling the creativity of the orchestra. For me, witnessing the creative process turned out to be a huge part of the entertainment. The music was mostly good, sometimes great, but also with a few boring minutes.

On 3voor12 Kyteman referred to The Jam Sessions as the complete anti-ego-project. Much like in agile software teams, ego stands in the way of team creativity. I’ve seen it happening in Scrum teams, and I saw it happening at the concert: the boring moments happened when the ego of one individual musician took over (first one of the keyboard players, later one of the drummers and in the encore when Kyteman himself pleased part of the audience by blowing his own trumpet). In all three cases, you could literally see the rest of the team lean back rather than participate.
And the great music sprang when there was no ego whatsoever, just a well-oiled musical team enjoying itself and the entire audience. During those moments I felt very much aware that these awesome songs were not designed upfront, they were invented right there, and will never be played again. It doesn’t get more agile than that.

Let me conclude with a shameless job application. This show in Eindhoven was just the first sprint, there are at least nine more to come. Kyteman, if you read this: I would love to facilitate your team’s retrospectives to enhance your continuous improvement. Please contact me at rudi.v@nderma.de :)

Permanent link to this article: http://agilethings.nl/the-agile-concerto/

Apr 04

The myth of estimation

product-in-a-boxOne of the trickiest parts in Scrum is estimating the entire Product Backlog. Often I’m asked to do this or to help Product Owners to do so. In almost every case management, the CEO or the customer demands it. Why would they want this? They want to know when everything is finished. And by estimating the entire backlog you can make a simple calculation. Divide the number of work items, or points or whatever by the velocity of the team or by what is already delivered and you end up knowing how many sprints it takes. Seems very simple. This is also why there is something like a Release burn down. Right?

Wrong! If you read about Scrum you will find out that is has to do with continues integration. Building increments of software per sprint. And most important, develop what is needed most and deliver this as fast as you can to get optimum value. So Scrum is not designed to deliver the software projects where a sales person agreed upon the total amount of cost and the deadline. What happens is that these projects are chopped up in little parts and every part is done within a sprint with a delivery at the end of the project. So you get, waterfall or water-scrum. No wonder that stakeholders want to know when it is done en demand the product backlog to be estimated so they can feel save and happy again.

The fundamental problem with wanting to know when it is finished is that if you have that “when is it done” question, software is still seen as a product. As something you can ship in a little box. As something you can save on a floppy. But software is not a product. Software is a service, something you provide to a customer, and if you have a great customer you may do this for a long time. It is a complex system that keeps improving and growing over times. It keeps developing. You never really finish it. And if you can accept this, then what’s the point in looking for the end. There is none. And if there is no end, there is no way you ever going to be able to estimate the whole.

Nowadays DevOps is very popular. It is used very often to sell a product. Sales and account managers use the word quit often and out of context. Yes we are going to deliver you product with DevOps and it will be delivered at you demanded date within the agreed budget. You just can’t. Not even with DevOps.

So lets return to estimating the entire product Backlog. It is a myth. It is a story told to people who did not do their homework. You can do some estimating but it will stay be nothing more then a gut feeling. You will never get the exact estimated and when you think you do you miss the entire point about Scrum, continues integration, bringing value and quality. You are still doing projects in a sequential design process (waterfall). You still hold-on to the thinking within the (software in) a box.

Once you start with focusing on what is needed at the now point in time, you might take the fist step in really understanding what Scrum is all about. It is simply about delivering the most important stuff first and with the highest value and quality. And it’s not about getting to the finish line and already knows what your end time will be. Or playing a game and knowing what the score will be. Hell, if it would be that simple, I would be rich by now.

Permanent link to this article: http://agilethings.nl/the-myth-estimation/

Jan 20

A dog will guide you

DOGWe probably all know a little about the term DevOps. It is said to be the next best thing. Where Scrum doesn’t provide, DevOps does. Basically it’s nothing new. The goal is to maximize the predictability, efficiency, security and maintainability of operational processes. And this objective is very often supported by automation. Now Scrum does provide but I have to admit leaves a few black holes about deploying and maintenance of software. But let’s make one thing clear. DevOps does not replace Scrum. It can be seen as an add-on . As an extra way of thinking towards continues integration and optimization of quality and communication (try saying that after a few beers). So let’s be aware of the next wave of bullshit that is threatening to come our way.

I think we got away with the Scrum master, product owner and Scrum coach titles. We accepted somehow that there are Six Sigma Black Belt Lean Coaches (I really need a lot of beer to accept those guys). And now we start with DevOps. There is nothing wrong with DevOps but let’s agree not to go into the next wave of fluffy experts who charge by the hour to sell you a load of stuff you already know but are afraid to do yourself.

I’m sure there are already a few new titles in the making. And I have to admit that I’m not afraid of earning a little extra money on a hype. So I came up with some cool titles to sell to companies who want to start with DevOps and who don’t understand that your Scrum or agile experts can help you with this. If you don’t have an Agile expert then you might want to hire the next cool thing for your DevOps implementation.

The DevOps Guru or DOG for short. A dog can help you to guide you through your IT and development landscape. A dog can find the things that you have lost like the different self-optimized departments who somehow lost their way and connections within your company and who are running things on their own. A dog can round up any stray members who got lost from the herd and help them to work together again to optimize the software flow towards the customer. A dog can… Well I think you know where this is going. Just don’t accept new fluffy bullshit that is sold to your company. DevOps is just optimizing your delivery process. Good communication and Working together. To stop acting as separate departments and to begin to think again as one big team. Hey that sounds a lot like Scrum or Kanban, and there is even some Agile mindset to it.

But maybe I just keep the DOG in mind. As Scrum coach I think I can provide, maybe I’ll start the DOG application process where you must submit yourself to a Certified DOG trainer to get your DevOps guru License. Hell I could start help those gurus and become a DOG whisperer or something like that. Wow, I think I just struck gold here. Let me write this down in a manifesto of some sort. The DOG manifesto. No better, the DOG Domestication Treaty.

Ok, I’m rampaging, sorry about that. I’m just saying. Just do it. Use Scrum or Kanban to visualize your working process and agree that DevOps aids in release management for a company by standardizing development environments, it’s nothing more. And let’s try to stay away from all the magic and nonsense. Because before you know it a dog is just selling you your own shit in a new wrapper.

(by the way, respect for Cesar Millan. My dog won’t even listen when I shout)

Permanent link to this article: http://agilethings.nl/a-dog-will-guide-you/

Jan 04

Shit Bad Scrum Masters say

maxresdefaultI know we can laugh about this but you might be surprised what I encounter sometimes in real company situations. The truth is sometime more horrifying than you might see in this classy video. If you have seen it, have another laugh, if you haven’t. Watch and learn and really think if you see something that is so familiar to something you experienced.

Have a laugh but be aware that this might be you.

Permanent link to this article: http://agilethings.nl/sh-scrum-masters-say/

Jan 03

Changing Education Paradigms

sir-ken-robinson-changing-paradigms-495wMost of the times on this Agile things blog is just us, a bunch of dedicated and passioned people, sharing our thoughts, ideas and knowledge in the hope that we can inspire you. I know that I speak for my own, but i’m sure my fellow blogger agree on this, when I say that we also get inspired by others. Obviously as we are mere people who learn and search every day. One of the the things I found very inspiring to see and hear was a lecture by Sir Ken Robinson. Now he does not tell us what to do, but he does make you think.

Enjoy

Source: RSA Animate

Permanent link to this article: http://agilethings.nl/changing-education-paradigms/

Dec 29

Think universal

universeWe people need an end to things. We like to see where we are going, and we want to round things up. Yet we like to talk about continues integration and delivering software as a service and not as a product, at least when your mind is set to agile thinking and collaborating. Every year I look in amazement to the end of the year, especially at the people working around this time of year. Somehow the world seems to come to a full stop. Work is going slower and comes to a halt. We move stuff past the first days of the year. And we start cleaning things up.

It is at these moments that I realize that we people have a very hard time in getting to work with Scrum or Kanban. We are almost unable to adapt the Agile manifesto as a good way to work together simply because we can’t. Our way of living is intertwined with something that was invented decades ago and we just can’t to step away from it. Our own invented calendar, a system that does not work. It is ok to plan our holidays with it, we think. It seems to help us remember birthdays, when we want to. And is tells us when we have to take a day of, even when we don’t need to. But when you really come to think of it. It is a very stupid thing that we do. I always laugh when people tell me that it is very warm for the time of year. As if nature follows our calendar. It is a system invented by puny little men who gazed at the stars for a while and thought they could see a system in it. A system that can be laid upon everything to make sense of things. Again, men who are trying to build a system upon nature. I think you have been looking up once in a while at those stars, and it is very big and complex up there. Sure, it seems to work but remember one very important thing. We are human and very tiny under those stars. We are the most irrational, chaotic and unreliable being that we know of in that huge universe. We think of systems and don’t use them. We come up with deadlines that we break. An appointment is never on time. And our watches are never in sync. Meetings run late and rules are broken. We try so hard to follow time schedules and plans even when we know they are wrong.

And then one day, a few people came up with a smart idea. Let’s just forget time, planning, thinking ahead and doing everything perfect according to a set plan and start listing to our feelings and human nature. To stop doing what we have done for hundredths of years. To forget what we have learned from generation on generation and just act upon our feelings. You can imagine why being agile and working with agile frameworks is so very hard to do. It is not something you take on overnight. With it we go against years of science and knowledge. But when you come to think of it, and I know I’m going on a limb with this one, we start doing things as nature intended. We start working with our instinct and guts. We start planting crops just because the temperature is right and not because the calendar told us to. We start working in harmony with the universe itself. Ok, maybe this is a bit to far fetched, but I think you get the point. And hey, it’s the end of the year so I’m entitled to my own end of year resolution. Oeps now I’m doing it myself, thinking in days. It is so hard to let go. Have a great 2014.  Don’t forget it just a number, so better said, have a great part of your upcoming life and enjoy every moment of it.

(And don’t buy a 2014 calendar, just for the fun of it)

Permanent link to this article: http://agilethings.nl/think-universal/

Nov 15

The complexity of a simple sollution

Magic_RoundaboutI was asked to give a talk at the Unicom seminar in Amsterdam. The people who gathered had experience in the finance sector and I was asked to talk about complexity in the banking and financial sector regarding software development. I haven’t got any real experience in the financial sector apart from trying to balance my checkbook. So I decided to keep it simple. So what was my talk about, well. It’s about the fact that we people have some serious flaws.

We humans are good at coming up with very complex solution for questions we got. We can build elaborate systems that do all sort of things. We are awesome at it. But when things start to get out of our control, and many times this happens, we also try to look for complex solves. It is almost impossible for us to just accept that it is possible to  unravel the tangled threads of our software solutions with a simple solve. Every time when I talk to people en propose a simple framework or method, I get the response that this not possible or not for their company or department because their problem is so complex that… well, you get the picture.

So why do we end up with these complex situation and is it so hard to just accept a simple solve. You have to keep in mind that there are a few factors to be taken into the account. Flaw if you like. First of all, I get a lot that making things complex is in our nature. It is in our genes. I talked to a developer and he said that almost every software developers tries to find solution just beyond the edge of their knowledge. They like to challenge themselves. This is nice and great, but not when it is about you software. I got a resume once from a programmer who stated that he was very good at coming up with complex solutions, sounds great but I would not hire him. So we like to make it difficult for ourselves.

The next flaw is that we are terrible at planning. We try to predict the future but we can’t. It’s like predicting the weather. And even though we have a lot of experience with this, and measure everything we can only predict five days ahead. Everything else is just assumption. So why try to do so with software development.

The second flaw is that we like exceptions. There is not a single software project where there are no exceptions. We like to do this, except when the other thing might occur. We just can’t stick to a simple yes or no. It is always maybe or what if.

And the third flaw. Ah yes, communication. We are terrible at it. We just can’t talk with one another. So we have all sort of tools to do it for us. Things like email, texting, documents and so on. But a simple good talk is very hard. I have had people sitting next to each other who talked by using email.

Now you might say that doing thing complex is in our nature. Just like the spider builds a web or a flower grows a mosaic like heart. But they have something that we have lost over time. When we evolved we lost one thing. Instinct. We do not dare to use our gut feeling when doing things and especially when we work with complex situation. We need our tools and plans.

Well at the talk, my message was simple and the same goes for this blog. All I’m saying is, start doing simple. Take small steps. Use an agile framework. Use games to get people to talk. Use special workshop tool break down the barriers in meetings and idea sessions. Just start doing it. But the first step that you have to take is accepting that as a human being you are full of flaws and that it is impossible for us to solve with complexity. We have to solve using simple small steps. It isn’t that hard but you just have to see and found out for yourself.

Permanent link to this article: http://agilethings.nl/the-complexity-a-simple-sollution/

Oct 16

AgileOpenKitchen: Visit, share and learn

AgileOpenKitchenAgileOpenKitchens. We have had a few and until now the response from attendees is positive. We have been very welcome at companies who opened their business for those who are interested in Agile, Scrum, Kanban and anything in between. Companies who don’t have everything perfectly running and still learning the ropes, but who are on a path to success or at least a fun and great way of working together.

So what makes a great AgileOpenKitchen?

  1. First of all, just open up. We often hear that a company is not ready for us. That there agile journey is not yet to a point where it is perfect. But it never is. You keep on growing and learning. The end not the goal, the journey is. And you only get better when you learn from everything.
  2. Be honest. Just show what you do and how you do it. An AgileOpenKitchen goes both ways. Share what you do and be open for feedback. Positive and the learning’s.
  3. Spare a little time and involve everyone within the company, don’s just do it in a confined meetingroom but open up your workfloor. Show your scrum or kanban board. And let those who work with it share what they do.
  4. Just have a few beers.

 

It is so simple to get insights, contacts and feedback. And most importanty, knowledge.

If you are interested in opening up your company to an AgileOpenKitchen. Just let us know. And don’t just think this is something you can just have in the Netherlands, where we started this, you can have it anywhere. We can use your help as a location (kitchen) provider but also as someone who would like to initiate a contact for a kitchen. Just let us know and we help you on your way.

Permanent link to this article: http://agilethings.nl/3942/

Sep 29

Agile thoughts from the mind

BrainLightBulb-300x300At this moment I am working on a presentation for one of our departments about Agile and Scrum. When I started working on this presentation I was thinking how to inspire the people about Agile. I know the obvious theory and values from the books and trainings, but what are the interesting things for the average employee in a company.

Because of these thoughts I started to write this blog post. I won’t be a regular theoratical post with all facts, but it is a post written from my experience and opinion. I would therefore love to hear some feedback from you guys!

By the way, the list below is just at random order ;)

Agile is a culture

The first and maybe most important thing is that I believe Agile is a mindset, a culture within a whole company. You cannot just follow the rules of Agile, you need to support the mindset. It’s also important that the whole company is Agile; meaning that management is supportive instead of controlling, business is looking at product increments instead of complete projects and the complete value stream from business to operations is optimized.

Reviews early and often

Reviews are important in finding errors, wrong assumptions or improvements. Reviews are available on different levels; you can have a peer review between two developers or the sprint review for the stakeholders. The important goal of reviews that you can validate what you have build and, when it’s found early, you can make improvements at low costs. So why wait for the sprint review to show the complete sprint to the stakeholders when you can validate the user story directly with, for example, the product owner.

Trust

Trust is key in Agile product development! No trust will limit people in their work, because the focus will be on not making mistakes and stay in the comfort zone. The thing about mistakes is that without making them, no learning is possible. It’s not bad to make a mistake, it’s bad to hide your mistakes and do nothing with it! Another thing is that when people are focussed on not making mistakes, this will block their creativity. The last thing I allready mentioned in a way is: find errors a soon a possible! Early errors are cheap errors! If you find an error at the end of a release, it will cost you a lot to only figure out where this error came from. Not even mentioning the costs to fix the error and releasing a special hotfix.

Rewarding result

What I see in practice is that when people get rewarded on their role or as a person, thats where the focus is! Agile is about working together in a multidisciplinary team, focus on result and delivering value for the customer. If you start rewarding teams and their result, people stop to focus on getting their own task done.

Incorporate people

Again, Agile is about working together in a multidisciplinary team! This also means to incorporate people who you don’t think of right away (legal, compliance, communication, etc). It’s better to involve them from the start, then to inform them when the product is fiinished. Think about yourself; will you be more open minded if your opinion is asked during the process or when you are informed after the product is finished?

Invest in improvements

This might be an open door, but I see it so often that a quick fix is done so the team can go back to working on the project. If you do this, the problem will hunt you all the way through the project. If you invest some time to really solve the problem, this will benefit you all the way throughout the project! You can make the improvement visible by adding a user story on the backlog with the improvement and also explain the improvement in the sprint reviews.

 

Well this is it for now; looks to me that this can be a “blogpost in progress” so please provide me with feedback and additions to this post. Hope you liked reading it and that it will help you a bit with being Agile in you organization.

Permanent link to this article: http://agilethings.nl/agile-thoughts-from-the-mind/

Older posts «