Jul 21

DevOps and Product Ownership

Change Tyre

[This article was co-written by Miel Donkers and Niels Talens.]

You could see DevOps as expanding the mindset, toolset and processes which started with Agile. Where Agile focuses on creating maximum business value as soon as possible, DevOps can help you to actually deliver this working software quickly. Finally a Minimal Viable Product makes real sense.

But just as we found out time after time with agile adoption projects, the gap between business and IT is often a bottleneck and not an easy one to resolve. With DevOps this often becomes an even bigger bottleneck since it adds the technical aspect of maintaining software in production.

DevOps is not just a matter of integrating Ops work into Scrum. In this blog-post we would like to focus on questions like; How are we going to …

  • help the business with this changed reality?
  • be able to cope with unplanned work (like incidents) while retaining a sustainable pace?
  • show the benefits of DevOps to the business on short term?
  • make sure features aren’t always prioritized above quality and security?
  • make sure that all important work is going to be planned on time?

Read the rest of this entry »

Permanent link to this article: http://agilethings.nl/devops-and-product-ownership/

Jun 17

Moving the mastodont

1206068419g4cHE2hMore and more I see companies who want to work with frameworks like Scrum but fail in getting it right. The more I look at why this happens the more obvious it becomes for me that the larger the company the more the challenge. And sometimes it is even impossible to get it to work.

In large companies the start of working with Scrum can be sparked in two ways. Either by development teams although this is very rare and I’ll explain later. Or by middle management and this is also the reason that it fails often. Now I’m not talking about a company with around an hundred or so employees, this is a challenged but easy to take. I’m talking about the 1000+ size organizations The bigger the more impossible.  You might gues that this is because the communication is harder and it takes longer to get everybody on the same page.  But it is not the communication that is the problem. It is the anonymity of the company.

If you look at scrum from the bottom up, to start with the teams so to say, it is very hard to get management involved. And when they do, they often lack the power to change upper management. Especially in large companies things go as they go and there is a lot of traditional way of working. Change is hard as many doors stay closed and business will stay as it is. Teams might get some improvement but never get Scrum to work to the full extend. Hey but what about DevOps. Well, DevOps is nice, but when you don’s have the cooperation of the entire company, this will also fail and especially DevOps. But let’s stick with Scrum for now.

What if the upper management wants to change then why should the people in the lower levels of the company? The problem is that the bigger the company, the more the anonymity of its workers. Why should you change when nobody will see it? I often encounter people who have worked almost their entire live at one company. They have seen many changes and scrum is just another thing endorsed by management.  To them it is nothing more then the movie of the week.

So basically the chance that you get stuck when wanting to implement Scrum in a larger company is very real. So should you not do it then? Please don’t let me keep you from trying. But you need a lot of energy and even more, a lot of people who are willing to change. And most important, you need sponsor. You need people who are willing to give time, influence and knowledge to help this change. The bigger question that large companies need to ask themselves, and not just the bigger companies, is why they would want this change. The “Why?” question is the one often not answered. Simon Sinek addressed this topic a time ago and more and more I see this question popup its curious head. Why the hell do you want things? Why would you start with scrum in your large 1000+ companies and if you do why is it not working?

So apart from wanting to turn the company on a 180 degree rampage towards something else. Ask yourself why you would want to do that. And once you know why, you can start with what you need the change and how. So there is a little spark here. You can redesign a big company, but you really need to shout the why question.

 

Permanent link to this article: http://agilethings.nl/moving-the-mastodont/

Jun 03

You need to have a SIT

7695928_origSo how do you get things to move within a larger organization? As I mentioned before just hiring an Agile Coach doesn’t do the trick. He or she can only bring change on those parts where people are willing to change. But it is just like a Chinese plate spinner. Once you have the first team spinning. The others will loose momentum and might fall. So you need more hands. You have your different Scrum Masters. True, but what if they need coaching as well or are not yet experienced enough to provoke change. What you need it a Scrum Implementation Team. A group of people with enough knowledge to teach others how to work and act with Scrum but also people who have time to do so. And by time I mean, mandated enough to do invest time and effort where needed. Not just one hour per week. This team also should be able to move freely through the company. And last of all but most importantly. They must have authority. It’s almost like the CRACK rules for a Scrum Product Owner.

This team should also be able to provide change by using Scrum. Build a product backlog with all the goals for that period and conduct daily standups, reviews and even retrospectives. So implementing Scrum with Scrum.  So what does the coach do then? Is he or she suddenly redundant? Absolutely not, but the coach can start with the change on a corporate level. And start helping the Implementation team as they need all the help they can get.

Now this is nothing new. You can read about this in the book that Jeff Sutherland and Ken Swaber wrote “Software in 30 day’s”. Yes I know, it is nothing more then a big sales brochure but it has got some good point. But also look at Spotify where they use coach teams who teach and help the different subgroups. It works. Change is not something you can do alone as a coach or as a single individual within a company. You need people; lots of people who are willing to adapt but also teach, promote and change. So as soon as you can. Start with a Scrum Implementation Team (SIT), or whatever you would like to name it. And keep all those Chinese plates spinning. It’s the only fast way to get things done.

Permanent link to this article: http://agilethings.nl/you-need-to-have-a-sit/

May 12

Be the change

Image source: http://pragprog.com/magazines/2009-11/the-agile-coach

People hire me as a Scrum coach to help them to make changes. Often these people work at companies that want to work with an Agile Framework, often Scrum. In many cases when I have the first talks about the how’s and why’s. I get most of the information I need as a coach to get starting. Sometime I’m asked how I’m going to do my work or if I have a plan. My honest answer is that I don’t. Off course I have ideas about how I’m going to do my coaching but I’ve learned that just starting with inspection and a lot of talks helps me to get my hands on everything.

The biggest challenge I face often is not that of helping a team with Scrum. I coach the Scrummaster and Product owners so they can lead and facilitate the teams. But in almost every case I smash into the company walls. Upper management, CEO’s, CTO’s and so one, sometimes want Scrum to work but don’t invest the time needed to get knowledge for themselves. They just rely on me as a coach to do the job for them. I think this is very dangerous, I might have a lot of knowledge and experience to apply changes but I’m just like everybody else, just human. I can make mistakes and my power (if there is any is limited. But even more important, how can you expect that your company will change if you as an initiator. don’t know what is happening or why. Yes I can teach and consult but the responsibility for change is not mine. It is of those who want that change.

At every intake that I conduct with companies, my first question is why they want to work with Scrum. Often I get a logical response but my response is always the question if everyone is committed and willing to change. But telling that someone is commiting is one thing, actually committing is something else. So I was thinking that maybe it would be a very good idea to make this commitment transparent. Maybe a sort of Scrum Coach Commitment document with statements like this one;

My name is …….., and I hereby commit myself to the learning’s, coaching, consultancy and examples of the appointed Scrum coach and will do everything in my power to turn this change into a success. I know it will be hard and difficult. I acknowledge that the way we are used to work will change and I shall accept this and make this change my own.

I would so much love to set this in writing on the wall and ask everyone who is going to work with the Scrum framework to sign it. I know there is the Agile Manifesto and you might say that this should be enough. But even though the manifesto is a very good idea, it does not say anything about really committing to change.

I would like it if a company not just hired a Scrum Coach as a sort of excuse or silverbullet, but that they openly commit themselves to the change. And then ask a coach to guide them. The best guide is knowledge and this is something that you can get for yourself. So read, learn, get involved, work together and most important be the change. Otherwise it will not work.

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

Apr 25

Have fun with Lego

Lego RetrospectiveIt’s not the first time I write about this. Maybe I’m very enthusiastic about this. Maybe I just want to tell you about this because it is plain and simple fun but very effective. Doing your meeting with Lego.

As a coach I help people to see things how they are, either good or bad. Applying transparency is important in every environment, not only if you are Agile or doing Scrum or Kanban. So once in a while it is good to look back at situations to see where you can improve. In Scrum it is a good idea to do this after every sprint. It’s one of the moments where you get to change and improve the way of working. But even if you don’t do scrum it is smart to look at what you are doing. One way to do this is with Lego Serious Play.  You can start with buying a big box of Lego and just do it. But a little knowledge of how Lego Serious Play works and how those little bricks can jumpstart the brain is, I think, important.

I’m not going to tell you how this exactly works. It might take a few pages. Although LSP seems simple, the logic behind it and the working of this method takes a bit more explaining.  But once you are able to understand how it works (ask you local coach or LSP facilitator) you can do very powerful sessions with your team or department.

This is not a blog to sell myself. Don’t get me wrong, I’m always keen to do this and earn a little money. But I write this to show you that you can do more with your Retrospective then just sit around the table and talk. Even when you use stickies, retro-games or whatever, once in a while you need new and fresh ideas to get people to attend with new energy. You might want to consider Lego. The glistering in the eyes of ever the participants is so much fun because no matter what age you are. And no matter what you position is within your company. Everybody just loves to play with Lego. Imagine that you have that positive feeling and then do a meeting. Trust me, it will be both fun and work. It will be serious play.

Permanent link to this article: http://agilethings.nl/have-fun-with-lego/

Apr 24

Agile Scrum. What else?

Renovations-no-pool

Image source: www.clearwaterpools.co.za

Probably the first indicator that lets me know as an Agile Coach that people don’t really know about the Scrum Framework or the Agile mindset is the way they describe what they are doing. “Yes we do Agile Scrum”. Every time someone tells me that they are doing Agile Scrum the small hairs at the back of my neck start to rise.

Why you may ask is this the case. For this you have to know the difference between the two. Agile is a mindset. It’s a way of thinking and not a way of doing. If you understand the Agile Manifesto, the four simple guidelines are just not more then what they are just four good ideas. Agile doesn’t say anything about how to work, plan, act or do. It is they way you might approach a challenge. You can’t apply Agile. You can’t implement Agile (trust me, this has been asked of me in the past). It is a way of thinking.

The second is Scrum. And Scrum is nothing more then a very simple framework. Scrum has just nine basis ingredients that if you apply them correctly you might get some things done. Scrum is about how you are going to communicate and get transparency within your work. For as far as I know there is only one kind of Scrum (if you leave the Football out of it). So if you work for example in ICT, none will expect that you show-up in shoulder pads and an egg shaped ball if you say you are working with Scrum.

So when I meet people who say they are doing Agile Scrum, I know that they don’t really understand what’s what. It is a very good signal for a coach to start helping people in explaining what Agile really means. To start explaining how Scrum works. And why they are connected but are not the same thing. Keep in mind that there is no other way of Scrum. And when you do it right, you might be Agile without knowing it.  Don’t use them in the same sentence and know them for what they are en what their place is in your team, company or where ever you might use it.

And yes, the same goes for telling people that you are an Agile Scrum Master or Agile Product Owner. Off course you are. But hey you might say. How about you? In the first sentence you present yourself as an Agile Coach. True. But as a coach I like to look at a bigger picture. Having an Agile mindset and explain and train in Scrum, Kanban, XP or what ever it takes to get to a better way of communicating and collaborating.

So. You can think Agile and do Scrum. If you do Agile Scrum, I might ask you if you also do sporting football, water swimming or parachute jumping with a parachute.  Get the idea? I know. It’s a mindset but very important that you get it.

Permanent link to this article: http://agilethings.nl/agile-scrum-what-else/

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/

Older posts «