Agile/Scrum blog

Onderwerp: agile

Agile werken? Niets voor mij….

Niels Opdam Door: Niels Opdam,  24-04-2017
Onderwerp: Agile  

Ben je nog niet overtuigd van de toegevoegde waarde van Agile werken?  Of heb je inmiddels de eerste stap gezet en kun je wel wat hulp kan gebruiken? In dit artikel neem ik je kort mee in de impact van Agile werken op je organisatie.

5 things every agilist could learn from Bob Ross

Teun Menting Door: Teun Menting,  21-03-2017
Onderwerp: Agile  

--Yes, Bob Ross!

Even though Bob Ross failed his ultimate goal, to get me to pick up a brush and enjoy painting, he has never failed to relax me. I will probably never pick up a palette or hang any Bob Ross inspired artwork on my walls, still his soothing voice and repetitive brushstrokes calm me down after a busy day. Recently some of the things Bob says to help explain how he paints stuck with me and I noticed that they are directly applicable to any agile way of working. So, if you are like me and you won’t let Bob Ross teach you how to make (very cliché) artwork, at least let him teach you these five things to keep in mind.

Meten is Weten

Wiger Middelkamp Door: Wiger Middelkamp,  09-02-2017
Onderwerp: Agile  

Een aloud gezegde, een open deur, iedereen is het ermee eens. En toch blijkt dit één van de meest vergeten dingen te zijn in organisaties. Natuurlijk kan je zeggen: nee hoor, bij ons meten we de klanttevredenheid, doen we elk jaar een medewerkertevredenheidsonderzoek en hebben we heel veel voortgangsrapportages van alle projecten die we doen. Als dat zo is: gelukkig maar, er wordt data verzameld. En toch is er nog zoveel meer te behalen dan deze voorbeelden.

Needs of High Performing Teams

Alex van der Star Door: Alex van der Star,  20-05-2016
Onderwerp: Agile Management   agile  Agile Coaches  Agile Coach  Agile Teams  Culture  Development Team  High Performing Teams  Scrum  Scrum Teams  Team Happiness  Team morale  What motivates people  zelfsturende teams  

The needs that High Performing Teams have

In my previous blogpost, I wrote about the characteristics of High Performing Teams. To come to these characteristics I did a small literature review. For this part, I will establish the needs that need to be filled in in order to enable teams to become high performing.

Remember, I am still talking about a team of knowledge workers developing and maintaining a software product.

Characteristics of High Performing Teams

Alex van der Star Door: Alex van der Star,  14-04-2016
Onderwerp: Agile Management   agile  Agile Coaches  Agile Coach  Agile Teams  Culture  Development Team  High Performing Teams  Scrum  Scrum Teams  Team Happiness  Team morale  What motivates people  zelfsturende teams  

How to create high performing teams

This is the first blogpost in a mini-series of three in which I explore actions that Agile coaches or Agile managers can take to create high performing teams. I focus on high performing teams that consist of knowledge workers creating a software product.

It looks like we are in the middle of a social revolution equal to the scale of the Industrial Revolution of the 18th and 19th century. We’re seeing more and more self-organizing teams that make their own decisions within boundaries set by organisational direction, strategy and/or vision. The benefits seem clear, teams that take ownership simply perform better. But what is exactly the mechanism behind this? Is setting a certain corporate direction and giving freedom to self-organising teams enough to end up with high performing teams?

Seeding and Cultivating Agile Champions

Barry Overeem Door: Barry Overeem,  21-09-2015
Onderwerp: Agile  Management  

This morning I read the interesting article 'The Agile Manager's Practice: Seeding and Cultivating Agile Champions' by Michael Hamman. It describes how growing and cultivating Agile Champions is a key practice of designing the desired environments. Michael emphasizes that it's about cultivating conditions in which agile practices can flourish.

My intention was to share some of the highlights of this article, but as a result I almost copied it as a whole... However, please check the original article for the entire context.

Een Retrospective is net een goed diner

Henk Jan Huizer Door: Henk Jan Huizer,  09-09-2015
Onderwerp: retrospective  agile  scrum  

Veel teams zien de Sprint Retrospective als een saaie en zinloze meeting. Het hoort erbij, maar levert weinig nieuws op. En dat kost de deelnemers veel energie. Erg jammer natuurlijk want voor startende teams is de retrospective vaak een van de meest vernieuwende en waardevolle onderdelen van Scrum. In deze blog een aantal tips voor de scrum master om, net als bij het dagelijkse diner, toch elke keer wat nieuws op tafel te zetten.  


Voorbereiding is alles

Als je helemaal aan einde van de dag de koelkast induikt om zo snel mogelijk iets op tafel te zetten, is de kans niet groot dat je diner wat bijzonders gaat worden. Dit geld ook voor de Retrospective, als je als scrum master 5 minuten vooraf begint aan de voorbereiding ben je te laat. Wat je vooraf zoal moet doen als voorbereiding? Dat vind je in de volgende tips!

The Scrum Master as a Teacher

Barry Overeem Door: Barry Overeem,  14-05-2015
Onderwerp: Scrum  agile  scrum master  

The role of a Scrum Master is one of many stances and diversity. A great Scrum Master is aware of them and knows when and how to apply them, depending on situation and context. Everything with the purpose of helping people understand and apply the Scrum framework better.

In a series of blog posts I will share the different stances I consider to be relevant for the Scrum Master. This blog post is about the Scrum Master as a teacher. I'll describe the definition of a teacher, the theoretical viewpoint and some practical examples of the Scrum Master as a teacher.

Five Fundamental Questions to Assess your Agile Process

Barry Overeem Door: Barry Overeem,  25-03-2015
Onderwerp: Scrum  Agile  

Recently I read Mike Sutton's article in which he describes the misuse of the Scrum framework. He addresses a few relevant topics and practices that I've unfortunately also witnessed applied wrong quite often. Examples are Scrum being used as a methodology instead as a framework and all the elements of Scrum are practiced mechanically without really questioning its true purpose.

However, my intention with this post wasn't starting an in-depth discussing about the misuse of Scrum. It's the questions Mike presents to assess the quality of an organization's way of working that triggered me.

How to Build a Scrum Team with Contractors?

Barry Overeem Door: Barry Overeem,  23-03-2015
Onderwerp: Scrum  Agile  

Within companies that use Scrum properly the organization is built around fixed, cross-functional, self-organizing teams who are given the freedom and responsibility to think of a strategy they believe will result in the best product. Everyone around the development team is focused on supporting and facilitating the teams in building the desired product. In consultation with the Product Owner, the development team themself decides what to work on and how much they can handle during a sprint. This results in a clear focus and the opportunity to obtain a sustainable pace of continuous delivery.

So far so good.

The fact is that a large part of nowadays organizations consists of contractors. They have got a core of employees, and around it a flexible layer of contractors they can easily up- or downscale. In this turbulent age with rapid changing business- and market conditions, organizations are almost obliged to have this flexibility. Next to this, an increasing amount of people with specific knowledge and skills also choose to be independent. They are not willing to work for companies for years in a row but want the freedom to switch assignments and engage in new challenges and environments continuously.

As mentioned before, Scrum is based on fixed, cross-functional, self-organizing teams. The best teams have a stable composition for a longer period and hereby have the opportunity to really become a strong team instead of a group of individuals. They've experienced ups & downs together and thoroughly know each other’s qualities and personality. But how do you build such a strong team, when a large part of the team consists of contractors? Is it actually possible to build a true team when contractors are part of it?

The Team Consultant

Barry Overeem Door: Barry Overeem,  01-03-2015
Onderwerp: Scrum  Agile  

Currently I'm reading 'The Scrum Field Guide' written by Mitch Lacey. So far it's an excellent book that offers me some interesting, practical insights. One of them is the concept of the team consultant. This idea suits a matter I've encountered quite often. In this blog post I'll share some of the thoughts of Mitch Lacey on this topic and complement it with my own personal view and experiences.

The best team sizes are between five and nine people, all of whom are fully dedicated to a project for the duration of the project, and who work together in a cross-functional way to deliver working software at the end of every sprint.

Many organizations struggle to create teams that live up to these conditions, for example:

  • Some specialized knowledge might be thus scarcely available and highly wanted, that the people having this knowledge can't be allocated to just one team;
  • Some people have such highly specialized skills that a Scrum team can't offer them enough relevant and suitable tasks;
  • Some people don't have the personality to be the ideal Scrum team member. Ilan Goldstein wrote an excellent article in which he makes the distinction between 'rock stars' and 'studio musicians'.

So how can you compose a team that is dedicated to building the desired product, respects the fundamentals of teamwork but also takes the given realities as described above into account?

A Projects Nightmare

Barry Overeem Door: Barry Overeem,  16-02-2015
Onderwerp: Scrum  Agile  

When developing a product, the given constraints and boundaries aren't always easy to handle. But as long as they are realistic and used wisely it shouldn't interfere in building a great product. The most common constraints are set on scope, budget, schedule or quality.

In traditional plan driven projects, the features are described and estimated up front. The time and cost necessary to deliver these features should be clear at the beginning of the project. After the requirement analyses phase the scope, schedule and budget get frozen and the phases of design, implementation and testing start. Everything with the big-bang deadline in mind at which everything must come together magically.

Scrum projects are value driven. Given the complexity and unpredictability of software development an up front fixed scope isn't possible. Therefore the budget and schedule are often fixed, but the scope isn't. Because Scrum always focuses on the features with the highest value, the features that aren't done at the end date are the ones with the lowest priority.

Another variety is one that can occur in both traditional and Scrum projects but for sure is a recipe for disaster. And I know, it may sound like a Product Owners dream, but in my experience it's a nightmare for a project:

A customer with an apparently unlimited budget.

5 urgent reasons to embrace Business Agility

Peter Koning Door: Peter Koning,  14-02-2015
Onderwerp: agile  Agile Principles  Agility in de bedrijfsvoering  

Searching for easy, flexible ways to unlock growth? Tired of endless meetings and e-mails all about internal process? Is your competitor more flexible, innovative and just one step ahead of you? Business Agility is a lightweight mindset that will empower synergy between marketing, sales and support employees. Unlike more process, managers, checklists and meetings; Business Agility is about small, empowered, cross-functional teams with one very smart goal, called Squads. These Squads have a lot of freedom and ownership to increase the customer experience and their success. They are on a mission to make their customers continuously more successful by continuously improving their products and services. After explaining what it is, I’ll give you 5 urgent reasons to start with Business Agility.

The Reading List for Agile Newbies

Barry Overeem Door: Barry Overeem,  05-02-2015
Onderwerp: Agile  Scrum  

Recently I got asked a few times to give some advice on the best books to study when you're a novice in Agile & Scrum. This resulted in me checking my Kindle library and giving some custom made advice. Of course this is a small effort, but it gave me the idea to bundle it in a blog post, which makes it easier to send around whenever anyone asks me. The result is some kind of personal Agile reading list for newbies; I hope it's useful for anyone entering the awesome world of Agile software development.

My original plan was to focus on Scrum, but when you're a novice in the world of Agile software development, I find it more useful to study multiple practices & tools and select the one that suits you best. Therefore I've added some books and articles of the most common Agile practices. This list is based purely on my personal preference. Probably a lot of obvious books for a novice might be missing, if so, feel free to suggest them.

Magic Estimation

Barry Overeem Door: Barry Overeem,  02-02-2015
Onderwerp: Scrum  Agile  

Being an Agile Coach & Trainer for Prowareness, I use different types of games, tools and practices every week during meetings, workshops and trainings. Some of these I've invented myself, but most already existed and have only been changed slightly to a format that suits me best. The upcoming period I want to share some of these games, tools and practices. I will share the what-why-how-when and what worked well and what didn't. By sharing my experiences I hope to inspire you to give these tools and practices a try for yourself, improve it and hopefully share the perfected version in return.

What is 'Magic Estimation' about?
It's an exercise for the Scrum team to estimate an entire product backlog with story points in a reasonable short amount of time. It's a useful format to get some insights of the size of a backlog. Is it one month, 3 months or 6 months of work we're talking about?

Setup CI build on VS Online - Hosted build controller

Prajeesh Prathap Door: Prajeesh Prathap,  01-01-2015
Onderwerp: Continuous delivery  TFS  agile  git  CI  

With your VSO account and team projects created using the account, it’s very easy to have full ALM capabilities integrated to your
project. Once you have chosen the version control for your project you can easily hookup a build definition and create CI builds using the hosted build controller provided as part of VS online.
If you are using the hosted build controller, there is no need of any additional hardware resources that needs to be installed or
configured for setting up a CI build. Read more..

Lessons Learned as an Agile Coach

Barry Overeem Door: Barry Overeem,  05-12-2014
Onderwerp: agile  Scrum  

After working a couple of years as a Scrum Master for the web agency Enrise I made the switch to Prowareness at the beginning of 2014. At Prowareness, a company that helps organizations meet their challenges in the field of software development, I fulfill the role of Agile Coach / Trainer. In this role I help individuals create great teams by applying host leadership, and learn organizations to adapt and respond to a constantly evolving world.

This is quite a challenge. Not only because working in the field of software development means working with complex products in complex environments. But mostly because creating a truly lasting change is difficult. Not only implement some best practices, but really build awesome teams and create responsive organizations. 

The toolkit of an Agile Coach should therefore contain more than a few skills, competences and best practices. Gathering them will require training, hands-on experience and most important: the willingness to constantly improve yourself. For me personally it helps to continuously reflect my daily practices and translate it to a list of 'lessons learned'. This list grows on weekly basis, with this blog I want to share the most important ones I've learned since I started working for Prowareness. And for sure, there might be some very obvious lessons, but often these are the ones you're not always aware of. Note: not all of these lessons are related to the role of an Agile Coach. But fulfilling this role, they've proven to be valuable for me.

Continuous Delivery – Patterns for zero downtime requirements (ARR setup)

Prajeesh Prathap Door: Prajeesh Prathap,  17-08-2014
Onderwerp: Continuous delivery  CD  zero downtime deployment  agile  architecture  

Microsoft Application Request Routing (ARR) is a proxy-based routing module that forwards HTTP requests to application servers based on HTTP headers, server variables, and load balance algorithms. With ARR you can increase application availability and scalability by better utilization of content server resources with lower management cost by creating opportunities for shared hosting environments.

Agile Transition Bingo

Stephan van Rooden Door: Stephan van Rooden,  15-08-2014
Onderwerp: agile  Agile Coaches  CD  agilegames  

A few weeks ago at Prowareness HQ in Delft we had a very interesting discussion on how to add more fun to your work. Especially the things that are hard to do or are actually no fun to do at all. Very soon we were talking about gamification which is the use of game thinking and game mechanics in non-game contexts. And this triggered me to add some fun to a very large and important transition we are working on at one of our partners.

Continuous Delivery – Patterns for zero downtime requirements

Prajeesh Prathap Door: Prajeesh Prathap,  27-07-2014
Onderwerp: Continuous delivery  CD  zero downtime deployment  agile  architecture  

One of the main problems teams face when practicing continuous delivery is to manage zero downtime deployments to the production environments. The goal is to deploy as soon as possible and depending on the heartbeat of the organization, this becomes a higher priority to manage active users without losing their data and sessions during a deployment process. In this post I'll share some of the ideas and approaches that are been used for achieving the goal of zero downtime deployments.


An important process for reducing risks and managing a zero deployment downtime is by following the blue-green deployment technique. In a blue-green deployment scenario, the approach is to bring up a parallel green environment and once everything is tested and ready to go, you simply switch all the traffic to the green environment and leave the blue environment idle. This also helps in easy rollback and switch to the blue environment if anything goes wrong in the current installation.

Start with Done

Jeroen van Menen Door: Jeroen van Menen,  27-05-2014
Onderwerp: Sprint board  scrum  agile  Scrum Master  sprint  Value   

I am a big fan of the “Start at the End” way of thinking. When I apply this way of thinking to a situation or problem, it most of the times gives me a completely different perspective on things. And with that comes a completely new way of thinking about what is needed to reach the envisioned end result.

This “Start at the End” way of looking at things is applied in many areas, for instance in Solution Focused coaching. Good examples are the “Miracle Question” and “Future Backwards” session. In the Netherlands Berthold Gunster is promoting this way of thinking. He even came up with a word for it “omdenken” which maybe translates into “turn your thoughts around”.

Groups & Scrum: Why we do Retrospectives

Stephan van Rooden Door: Stephan van Rooden,  10-03-2014
Onderwerp: agile  Scrum  Retrospectives  Groups  

This is the second post in a series of blogs on groups and Scrum. In the first post we defined what a group is, why people join groups and what it takes to make them a team. Establishing the stage of being a team, or nowadays in most organizations, being a Scrum team comes with some challenges. How to get this team constantly improving themselves? The Scrum Framework believes it is that important to continually improve that there is even an entire event devoted to this.

Groups & Scrum: Why we do Retrospectives

Stephan van Rooden Door: Stephan van Rooden,  10-03-2014
Onderwerp: agile  Scrum  Retrospectives  Groups  

This is the second post in a series of blogs on groups and Scrum. In the first post we defined what a group is, why people join groups and what it takes to make them a team. Establishing the stage of being a team, or nowadays in most organizations, being a Scrum team comes with some challenges. How to get this team constantly improving themselves? The Scrum Framework believes it is that important to continually improve that there is even an entire event devoted to this.

Setting the stage

When I was preparing for my training course in getting the most value out of your retrospectives, I stumbled across something very interesting that opened my eyes. When talking about Sprint Retrospectives there is one book you cannot ignore. Agile Retrospectives? Making Good Teams Great by Esther Derby and Diana Larsen [Link].

Their book resolves around a model for running effective retrospectives. This model, or framework for retrospectives consists of five stage

  1. Set the stage
  2. Gather Data
  3. Generate Insights
  4. Decide what to do
  5. Close the retrospective

A very powerful framework from my perspectives that have helped me run plenty of very effective retrospectives. But I always missed the rationale behind these stages. Only after I started reading some old study books on social psychology, it struck me that this framework makes perfect sense. Here’s why…

Group decision making

There is no better feeling than being part of a group that is able (or at least feel they are) to solve every problem that is thrown at them. Our society now is so complex that one individual can no longer possess all the knowledge, he cannot oversee the entire picture. The necessity to organize ourselves in groups has never been higher. Scrum tries to achieve that as well. Assemble a group a individuals who together are able to win the game. To solve any problem thrown at them by the product owner. This also means that we as a group have to make decisions together as well...and that is not that easy!

Benefits of decision making in groups

Despite it’s not easy there are some major benefits for teams to make their own decision. First, the information and knowledge present in a group is more complete than in smaller groups. Two heads are better than one! However, this is should automatically the case (more on this in my next blog on knowledge sharing!)

Second, when a group comes to a decision they tend to accept the solution more often than when an individual makes a decision for the group. The last thing is hard especially nowadays where the hierarchical structure in organizations are under pressure because those lower in the hierarchy are no longer uneducated individuals but high skilled and knowledgeable. So they are less willing to blindly follow their leader (into the abyss).

This is why the book of John Kotter; ‘Our iceberg is melting’ [Link]  so popular. You have to go through great lengths to convince a group to take over your point of view. Wouldn’t it be easier to let the group themselves decide? Just give them some boundaries and they will solve the puzzle.

Third, and last, benefit of group decision making is that it increases the sense of legitimacy of the group. Making a decision as a groups gives them the confirmation that they are in fact a group! However, where there are benefits there are definitely some disadvantages to group decision making.

Groupthink and Groupshift

One of the most straight forward and most visible downside to group decision making is that is takes a lot more time. We all have been in those endless meetings where discussions go on and on for…well it feels like hours sometimes. In a Scrum Team, the Scrum Master plays a big role in facilitating the Scrum Events in such a way that they are as efficient and effective as possible.

Also when making a decision as a group, questions may arise who is responsible for the outcome of this decision. Should one person be accountable or is the entire group accountable. This is a thin line. You see this happening is sports very clearly. If a team is winning, the team is celebrated for this but when results get bad we try to shift the blame to an individual (usually the coach). In organizations you see that when a manager is held accountable he is almost obligated to take the decisions as well. This has become part of our DNA so much that we are having trouble letting this go. And when you start adopting Scrum you immediately get in trouble. I believe that if a group makes a decision, they should be accountable as a group as well. Delivering in small increments limits the impact of decisions made by a group and therefore makes this discussion less relevant.

The biggest disadvantage of group decision making is that it nourishes conformism. So people in a group tend to match their attitudes, beliefs and behavior to group norms. Two interesting sociological phenomena arise here; groupthink and groupshift

Groupthink is the phenomena where groups pressure leads to conformism so any critical, unpopular or minority interest will not be taken into consideration by a group in their decision making process. So what recently happened in a Development Team was that during a sprint planning meeting an ops-engineer made a very good point related to the monitoring of the item under discussion. However, since the rest of the team didn’t had any feeling regarding that topic the comment from the engineer was put aside and never came up again. Groupthink, a minority interest wasn’t taken into consideration by the team.

Groupshift is where members of the group exaggerated their initial toward a more extreme position. So risk averse individuals will propose an even more risk averse approach and the opposite happens with risk seeking individuals. In group decision making this will lead to decisions being made that are more extreme. So when in a group, individuals are far more willing to make riskier decisions. Shared risk makes the individual risks less.

Why we do retrospectives?

So how to deal with these two phenomena? There are two ways to improve the group decision making process and to limit the impact of groupthink and groupshift.

First is brainstorming. This has been a very popular approach in the 90’s and 00’s but the effectives of this approach is in question nowadays.

The other approach is a nominal group technique where you facilitate group decision making by doing a couple of things:

  1. Get everybody involved together
  2. Let people think for themselves first about the problem at hand
  3. Share the thoughts
  4. Discuss on how to solve the problem
  5. Order the ideas and decide

You probably connected the dots already but this technique is a nearly 100 percent fit with the approach from Derby and Larsen. So we do retrospectives to facilitate group decision making and in order to amplify the benefits of this approach structuring your retrospective as described above helps! If you look around on the web you can find plenty of ways to run your retrospectives this way. A nice example of this is the Retr-O-Mat, a retrospective generator.

Next post will address another very important aspect of Scrum related to groups. Having a cross functional, multi-disciplinary team to accelerate delivery and knowledge sharing. But sharing knowledge is extremely difficult especially in the very complex world of software development.

 

 

Valuecracy - let Validated Value steer your organization

Peter Koning Door: Peter Koning,  13-02-2014
Onderwerp: Validated value  agile  Product Owner  

Bureaucracy, adhocracy, democracy or holacracy? What is the best way to improve the value delivered to your customers? How can you get feedback so you can improve on it? I’ve searched for a long time for a proper way to lead an organization to improve the value really delivered to their customers. Everybody knows that a higher value increases revenue and sustainability of organizations. Valuecracy is of course not an official word (yet) but it sets the focus of an organization externally, it sets the mindset towards the customers. I’ll explain it in more detail below. Let’s brainstorm together on the best way to lead an organization! Give me feedback (by email, by leaving remarks, by hitting the twitter buttons) and I will improve this article with your valuable feedback! If this happens, it’s a proof that Valuecracy works!

Combineer Lean en Agile!

Peter Koning Door: Peter Koning,  28-01-2014
Onderwerp: agile  improvement  Lean  Lean IT  leiding geven  zelfsturende teams  

Scrum of een andere Agile variant is waarschijnlijk bij u al ingevoerd binnen de afdeling softwareontwikkeling (IT). De meest recente releases zijn dankzij Scrum voor de deadline en met hoge kwaliteit gebouwd. De medewerkers zijn meer tevreden. Maar zijn cijfers als de winst, de omzet, de liquiditeit of de klanttevredenheid sterk gegroeid? Is het mogelijk om de kracht van Scrum bedrijfsbreed toe te passen? Als dat mogelijk zou zijn, zouden dan deze cijfers sterk stijgen?

Bedrijven kunnen een combinatie van Lean en Agile (Lean-Agile) omarmen om zo de winst, de liquiditeit en de klanttevredenheid sterk te verbeteren. We zullen u uitleggen wat Lean-Agile is en hoe u daarmee kunt beginnen.

Risk Adjusted Burn-up Chart

Melvin Nijholt Door: Melvin Nijholt,  16-12-2013
Onderwerp: release management  agile  estimation  

Burn-up charts are used by Scrum Teams to visualize the progress towards a specific goal. This goal can be anything that can be measured over time. For example the scope of the next release or towards project completion. It helps Scrum teams to focus on the goal and creates the ability to make adjustments when the goal get out of reach. 

A few weeks ago I was introducing a release burn-up chart at a customer to visualize the current state of the release progress. They wanted to use this to make an estimation on the chance to finish all the planned features. So I created a default burn-up chart with the sprints on the x-axis and the number of story points on the y-axis. I added a line with the total number of story points of all the features in the release to visualize the goal and a line with the amount of story point finished to create the burn-up. 

Use usage statistics to validate value

Harm Pauw Door: Harm Pauw,  04-12-2013
Onderwerp: Product Owner  Lean  agile  

Do you know which features are used the most often by your end users? Do your know how much time they spend using your application and what takes up the most time? If not, collecting usage statistics can help you answer these questions and makes better choices on which feature you want to spend your money.

Continuous Delivery in a Nutshell

Harm Pauw Door: Harm Pauw,  02-12-2013
Onderwerp: Continous Delivery  Tech  agile  Craftsmanship  

What is it?

Continuous Delivery is a software development practice where you make sure that your application is ready to be deployed to production at any time. You’re not only making sure that when a developer commits a change is, it is correctly integrated by building and unit testing your application (Continuous Integration). You’re also making sure that your application is always ready to be deployed by running automated UI and/or acceptance tests on it and testing the release process itself.

Lean Agile....why? how?

Paul Weghorst Door: Paul Weghorst,  21-11-2013
Onderwerp: agile  Agility in de bedrijfsvoering  Lean  

The word 'agility' can be nominated to the top 3 management clichés of the last decade, at least to my opinion. A lot of improvement programs have been given this predicate to boost the credibility of the program. It's like world peace...no one can be against agility, can you?

Organizations who have been successfully implementing Scrum or Lean, know that you only achieve sustainable success if it is more than just a temporary program: it should become part of the DNA, the underlying habits of the organization. When you talk about this to senior managers who are not convinced yet, you always hear 'another hype who wants full management backup, but I have more things to do than just this'.

That is true, but there is one big difference between all the so called revolutionary improvement theories.....it's revolutionary in the outcome, not in the implementation. Let me explain this to you in this blog.

Waarom schatten in punten en niet in uren?

Rini van Solingen Door: Rini van Solingen,  19-11-2013
Onderwerp: agile  Scrum  estimation  

Scrum geeft er de voorkeur aan om niet te schatten in uren, maar te schatten in punten. Waarom zou je zeggen? Uiteindelijk komt het toch op hetzelfde neer? Je wilt toch weten wat het kost en wanneer het klaar is? Dan moet je toch weten hoeveel tijd het kost? Uren dus. Of niet?

Het zit toch net iets anders. Wij mensen zijn heel slecht in het schatten in uren. Tijd is een absolute eenheid en mensen zijn niet zo goed in het inschatten van absolute eenheden. Als voorbeeld, wij kunnen heel slecht inschatten hoeveel een auto weegt en hoeveel een scooter weegt in kilo’s. Of een ander voorbeeld: als wij twee torens zien, dan zien wij in een oogopslag dat de ene toren twee keer zo hoog is als de andere. Maar hoe hoog elke toren nu precies is in meters, dat kunnen wij heel slecht inschatten. In andere woorden: absoluut schatten kunnen wij slecht, maar relatief inschatten kunnen we weer wel goed.

Daarnaast is het vervelende aan uren dat ze ook nog gebruikt kunnen worden als eenheid van tijd en heel makkelijk tot misleidende berekeningen kan leiden. Het is heel simpel, 40 uur aan werk zorgt er voor dat een team van 5 personen in een dag klaar is, toch? Of niet? Verzetten wij wel 8 uur werk in een werkdag, of toch minder? Wij zijn vaak veel te optimistisch en houden geen rekening met verstoringen, afhankelijkheden, onzekerheden etc. Bovendien schatten we vanuit ons eigen perspectief en vergeten dan vaak het werk van anderen dat ook nog nodig is.

Kortom, het schatten in uren is

Wat is de Return-on-Investment van Scrum?

Rini van Solingen Door: Rini van Solingen,  12-11-2013
Onderwerp: agile  improvement  Scrum  

Hoewel Scrum uiterst populair is en veel organisaties ermee werken, is de hoeveelheid meetgegevens over wat het kost en wat het oplevert nog erg beperkt. Grote adviesbureaus als Gartner, Standish en McKinsey adviseren allemaal om niet meer planmatig via een waterval te werken, maar om jezelf op een Agile manier te organiseren. Gartner is heel expliciet: ‘The End of the Waterfall as We Know It[1]. Standish gaat zelfs zo ver dat ze durven te stellen dat: ‘Agile is the Universal remedy for software development project failure[2]. De poging van Rally[3] om de impact van Agile te kwantificeren leert dat bijna alle teams hun productiviteit verdubbelen, de kwaliteit van het werk toeneemt met 250% en het laag houden van de hoeveelheid onder handen werk (WiP) leidt tot een halvering van de doorlooptijd. In het Agile survey van Version One[4] wordt aangetoond dat 90% van de respondenten veel beter in staat is om mee te bewegen met veranderende prioriteiten en dat de inzichtelijkheid en transparantie sterk verbeterd wordt.

Ons nieuwe boek: Scrum voor Managers

Rini van Solingen Door: Rini van Solingen,  12-11-2013
Onderwerp: agile  Agility in de bedrijfsvoering  leiding geven  product companies  Scrum  zelfsturende teams  

Op 13 november 2013 is “Scrum voor Managers” officieel uitgekomen. Dit boek heb ik samen met Rob van Lanen geschreven. Het boek richt zich op de manager die zich afvraagt hoe hij in een Agile organisatie leiding geeft, stuurt, meet en optimaliseert. Het boek is opgebouwd rond de 50 meest gestelde vragen door managers over Scrum en Agile. Daarnaast gaat het in op de meest genoemde vooroordelen en misverstanden die wij in onze dagelijkse praktijk tegenkomen.

Agile Transition: Why and how?

Paul Weghorst Door: Paul Weghorst,  05-11-2013
Onderwerp: agile  leiding geven  Agility in de bedrijfsvoering  

The average lifetime of a company in the S&P 500 has fallen by 80% since 1937. The profitability of all publicly traded US firms has progressively dropped by 75% (source: The Shift Index, Deloitte Center for the Edge, 2011).

 Many organizations who are leading their market at the moment, didn’t exist ten years ago. New ideas can be succesfully executed because of new ways of sales and distribution.

 For organizations who have been in the market for quite some time, this is a serious threat.

Sinterklaas en zijn Pieten, het beste Scrum team ooit

Door: Wiger Middelkamp en Michiel Vrasdonk,  18-10-2013
Onderwerp: Agile  Scrum  Product owner  

Er zijn veel verschillende manieren om uit te leggen hoe Scrum werkt. Vaak gaat dat gepaard met een mooi plaatje waar iets in staat over rollen, meetings, artifacts en states.
Maar hoe vertel je iemand nou het makkelijkst wat de waarde van Scrum is? Lees onderstaande en gebruik het om mensen de waarde van Scrum te kunnen uitleggen.

Transparency….makes it hard to lie

Stephan van Rooden Door: Stephan van Rooden,  14-10-2013
Onderwerp: agile  Product Owner  Scrum Master  

A few days ago, I had a great day where I did some ‘magic estimation’ with two teams. In 15 minutes they created an initial estimation of the entire product backlog. This was an exciting moment for the Product Owners. They already know they have a budget for 14 sprints. Is it possible to do everything they want in only 14 sprints, while the team already is in their fourth sprint?

Een Agile transitie met een externe transitiemanager. Kan dat wel?

Rini van Solingen Door: Rini van Solingen,  08-10-2013
Onderwerp: Agile Teams  Agility in de bedrijfsvoering  leiding geven  zelfsturende teams  agile  

Elke dinsdagavond zitten wij met alle collega’s op kantoor bij Prowareness. Tot half zes hebben we het over de belangrijkste stappen die wij als bedrijf moeten zetten. Daarna eten we en van zes tot acht uur stipt werken we aan de top 5 onderwerpen die ons beter maken.

Dat doen we in teams. Wij zitten in het team rond onze transitie-aanpak.

Op dat punt zitten we met een dilemma. Vanavond werden we ons namelijk bewust (sommigen van ons in elk geval) van een paradox. Namelijk, wie leidt nu eigenlijk een Agile transitie? Een deel van ons vindt dat een Agile transitie wordt geleid door het management. Zij zijn de cultuurbewakers, zij zetten de lijnen uit, zij geven dagelijks leiding. Als externe Agile coach kun je dat niet doen. De leiding van een Agile transitie ligt bij het management van de organisatie die die transitie uitvoert. Dat is de mening van de ene helft van ons team.

Confession: I am not 100% agile!

Stephan van Rooden Door: Stephan van Rooden,  01-10-2013
Onderwerp: Agile  

Last weekend I returned from the south of Spain where I spent two weeks doing absolutely nothing. During this, from my point of view well-earned vacation, I did think a lot about my work. I didn’t intend to do this, but while driving in my car on my way there I made a shocking observation. I am not 100% Agile!

Last week during my talk on visual meetings at the Agile+ Market, I talked about my trip. I was very happy with the directions I had found on the internet. Instead of following my TomTom (which is seriously outdated) or a boring description which says ‘Turn left after 100 meter in the direction of...’ I had my directions consisting only of road signs. Great! Just match the road sign with the image on my paper. What could go wrong?

Slalom race

Dave Woertman Door: Dave Woertman,  26-08-2013
Onderwerp: Agile  

Afgelopen weekend heb ik, na heel wat jaren afwezigheid, weer eens plaatsgenomen in een raceauto. In voorgaande jaren heb ik veel aan karting gedaan. Deze keer mocht ik hetzelfde doen in een grotere variant met veel te veel PK's. De racedag werd afgesloten met een kleine competitie waarbij we (met collega’s) een slalomparcours rondom pionnen moesten afleggen. We kregen van tevoren bijna geen tips over de manier waarop dit parcours het snelst kon worden afgelegd. Eigenlijk was er maar één tip: Less is more, zorg ervoor dat je niet te hard door de slalompoortjes gaat. En toen sloeg de beroepsdeformatie toe: in Agile-projecten is dat eigenlijk hetzelfde… Less is more!

Controle is beter dan vertrouwen… Toch?

Wiger Middelkamp Door: Wiger Middelkamp,  16-08-2013
Onderwerp: Agile  Scrum  Product Owner  

”Scrum is extreem makkelijk uit te leggen, maar extreem moeilijk om toe te passen.” Deze uitspraak komt van Jeff Sutherland, één van de geestelijk vaders van Scrum. Hoe zit dat dan precies? En klopt de uitspraak van Jeff wel? Deze blog gaat in op één van de aspecten die product ownership zo moeilijk maakt: loslaten.

Retrospective

Dave Woertman Door: Dave Woertman,  02-08-2013
Onderwerp: Retrospectives  Scrum  Agile  

Tijdens het coachen van teams heb ik veel contact met Scrum Masters. Binnen mijn huidige Agile transitie opdracht heb ik de verantwoordelijkheid over tientallen teams, waarbij ik me voornamelijk focus op het werk van de Scrum Master. Een collega van me begeeft zich meer op het vlak van de Product Owner.

Aangezien de boeken voorschrijven dat de Scrum Master verantwoordelijk is voor de retrospective meeting, krijg ik daarover de meeste vragen. Welke manier van retrospectives werkt het beste? Wat is het doel van de retrospective? Hoe versnel je het team?

Snel van Idee naar Product

Edwin de Werk Door: Edwin de Werk,  24-07-2013
Onderwerp: agile  high performing teams  

Op dit moment wordt in veel organisaties getracht om Agile te werken. Dat je eerst Agile moet denken en daarna pas Agile kan werken is een Blog op zich waard, maar daar wil ik nu niet over hebben. Wat ik keer op keer tegenkom bij organisaties is dat er binnen de IT-afdeling Scrum gebruikt wordt en dit al heel snel voordelen biedt, in de juistheid en snelheid waarmee functionaliteit opgeleverd wordt. Op dit moment is het “hot” om over DevOps te praten en wordt gelukkig tegenwoordig ook de beheerafdeling van IT erbij betrokken met alle voordelen van dien. “Optimize the Whole”. Weer een “muurtje” minder.

Wat nog vaak over het hoofd wordt gezien is dat naast de softwareontwikkeling en het beheer er vaak een langdurig voortraject bestaat. Dit voortraject waar projecten gedefinieerd worden, Business Cases en requirements worden opgesteld, neemt vaak zeer veel tijd en geld in beslag. Het komt vaak voor dat de helft van het budget al op is voordat begonnen kan worden aan de werkelijke softwareontwikkeling. IT-organisaties hebben inmiddels wel begrepen dat zekerheid zoeken in requirements niet de juiste oplossing is, maar geldt dat ook voor de business van deze organisaties? Te vaak zie ik nog dat er aan een Productbacklog gewerkt wordt waar uiteindelijk honderden items op staan. Een opsomming van requirements! “Old habits die hard” zullen we maar zeggen.

Uitnodiging kennisevenement Agile Coaching Playground

Rob van Lanen Door: Rob van Lanen,  28-06-2013
Onderwerp: agile  Coaches  

In de professionele wereld wordt het woord ‘play’ vaak nog geassocieerd met kinds, kinderlijk en speels. Echter; wat maakt nu dat play en volwassenheid hand in hand gaan? Hoe kan het dat kinderen vaak een enorme focus hebben waar volwassenen jaloers op zijn? Hoe kunnen we de voordelen van play toepassen in onze professionele agile coaching?
Over deze vragen en nog veel meer willen we met jullie speels gaan sparren tijdens de Agile Coaching Playground. Het is een kennis- en netwerkevenement op maandag 8 juli voor, door en met Agile Coaches in Zuid-Oost Nederland. We zien jullie graag rond 15.30 uur op locatie, Regards, Gele Kegels in Eindhoven.

De mensen zijn OK, het systeem zuigt!

Edwin de Werk Door: Edwin de Werk,  02-11-2012
Onderwerp: agile  

Transities naar Agile zijn leuk, maar vaak ook best lastig. Tijdens de eerste Sprints komt het regelmatig voor dat ontwikkelaars negatief reageren op vragen om een rol te spelen in een team. De eerste reactie van de meeste Managers is dan om de discussie aan te gaan en de medewerker op zijn/haar verantwoordelijkheden te wijzen. Of beter gezegd: hierop te plichten…

Wat mij als Coach opvalt is dat wanneer dit gebeurt de focus altijd ligt op wat de medewerker niet goed doet en er direct een actie aan wordt gekoppeld wat de medewerker juist wel zou moeten doen. Eigenlijk is dit het de kop indrukken van symptomen zonder naar de dieperliggende oorzaak te kijken. De werkelijke oorzaak is namelijk meestal dat de betreffende medewerker lange tijd gedwongen is om zich op een voor hem/haar ongewenste manier te gedragen. Toch heeft de persoon dit gedaan omdat het systeem (organisatie) waarbinnen hij werkte dit vereiste.

Agile en aanbesteden... water en vuur?

paul weghorst Door: paul weghorst,  24-09-2012
Onderwerp: agile  

Binnen het uitbesteden is een traditie gegroeid van uitgebreide specificaties opstellen, een aanbieding aan de markt vragen in een proces met minimale interactie, de goedkoopste laten winnen en vervolgens een contract opstellen met hoge boeteclausules. Of dit allemaal echt wordt voorgeschreven door de wetgever is nog maar de vraag, maar het is wel de standaard van vandaag. We weten ook dat dit zelden verloopt zoals het bedoeld is: gemiddeld 35% van de specificaties verandert, en het levert software op waarvan 65% niet of nauwelijks wordt gebruikt. Er wordt stevig geëscaleerd, de relatie komt flink onder druk gestaan, maar ondanks 9 jaar ervaring in zakendoen onder aanbestedingen, weet ik dat boetes zelden worden geëffectueerd (de opdrachtgever was zelf nooit van 100% onbesproken gedrag).

Op de conferentie Agile en Overheid van 17 september werd stevig gediscussieerd over hoe het zou moeten en hoe het zou kunnen. Waar een wil is, zou een weg moeten zijn, ook binnen de aanbestedingsrechtelijke kaders. Gelukkig zat de zaal niet alleen vol met Agile-adepten, maar ook met geïnteresseerde maar tevens kritische belangstellenden. De emoties liepen hoog op! Gaandeweg de conferentie zag je de wil om het anders te doen groeien, en kwamen met name de vragen 'zou het werken' en 'wat moet je dan afspreken'. Want meer vrijheid (in bepalen wat er gebouwd wordt), moet niet ontaarden in vrijblijvendheid!

How To Initiate Improvement in 20 Minutes

Rob van Lanen Door: Rob van Lanen,  02-03-2012
Onderwerp: agile  

Have you ever been in a situation where you wanted to generate improvements in a small amount of time? How can you facilitate a well-structured session when you only have 20 minutes of time available? After reading this post, you will add a practical way of generating improvements to your toolbox. This approach is based on the elements of a good retrospective.

Leiding geven aan zelfsturende teams: Hoe doe je dat?

Henk Jan Huizer Door: Henk Jan Huizer,  24-02-2012
Onderwerp: agile  leiding geven   zelfsturende teams  

Op de trainingserie Meesterschap in Scrum komt elke maand een specifiek aspect van Scrum aan bod. Op 16 februari was het onderwerp ‘Leiding geven aan zelfsturende teams’. Zelfsturende teams zijn één van de kernelementen van een goed functionerende Scrum organisatie. In de praktijk is het ontzettend lastig om hier invulling aan te geven. Wat is precies een zelfsturend team? Heeft een dergelijke team helemaal geen leidinggevende meer nodig? Mag dit team niet bijgestuurd worden? Wat te doen als het niet goed gaat met het team? Hoe komt het dat het ene team wel zelfsturend is en het andere niet?