That’s because people freak out when they hear about story points and relative estimations.

Why wouldn’t they?
If you’ve ever done a project before in your life, you know that at some point in time, you’ll need to tell your stakeholders when it’s going to be finished or how much it’s going to cost.  If you then reply: “In agile projects, we don’t care about up-front estimations.  The team plays planning poker before each iteration and measures velocity afterwards.” you’re bound to get some funny looks.

That’s natural, because you first have to explain agile release planning.

What is our goal in Agile software development?

• To avoid investing money & time in up-front work because we know the future is uncertain and things change.

How do we address this?

• We invest just-in-time, in focused time-boxes.

What is missing?

• If we do everything just-in-time, we’ll never be able to do release planning.

True, if we estimate iteration by iteration, we’ll only know our cost and release date at the last iteration.

You don’t have to be a veteran project manager to know that the only way to successfully deliver a project is to continuously monitor scope, budget and time.  Depending on the primary project focus, you can work with the other constraints to keep it on track.  (Don’t let people who say they successfully manage a project with 3 fixed constraints fool you, they actually do the same because they include contingency buffers.)

This also applies to agile projects. Even better, it’s much easier to monitor these constraints.  After each iteration you’ll have new data.

• How many person-hours have we spent?
• How many story points were delivered?
• How are we doing on timing?

In order to be able to use this data, you need a fully estimated (release) backlog.

If you keep your releases small, it’s not difficult to split up the requirements to a user story level.  Techniques such as user story mapping are a great way to do this.

The next thing to do is to estimate all user stories.  But because you have limited detailed information at this point, the only thing you can do is compare them, thus estimating them relatively.  This is where story points come in handy. However, stay away from planning poker!  It tends to drag you into detailed discussions, which are not relevant at this moment in the project.  A great alternative is silent grouping. The exercise on its own makes it clear to everyone involved that its goal is to get a first high level comparison, nothing more.  Which are big user stories, which are small?  Use story points as a scale, and you will have a fully estimated backlog.  Quick and without much discussion.  I still use planning poker, but only when we notice during iteration planning that a user story has a completely wrong story point estimate (which doesn’t happen a lot).

Skeptics might say : “How can this be accurate?  You’re estimating without any detailed information?”  True, some estimates might be high, others might be low.  Some might level each other out. Whatever.  Just remember, our goal is to get a first idea about the size of the backlog, nothing more.

A next step is to get an idea about the team velocity. If you can wait a few iteration, great!  If not, guess!  In both cases, you’ll have your measurements soon and you will need to adjust continuously.  But at that point, you’re in control. Iteration after iteration you can project the results onto the release planning and adjust some of your constraints if necessary.

Take a look at this burn-up chart example as a tool to monitor the release planning of a project where timing was the main constraint.  The worst case, best case and linear scenario make it visual that a plan is never going to be 100% certain.

If you think about it, agile projects are not that different.  Letting go of the illusion of a fixed plan, drives a completely different behavior.  One that focuses on creating value and making healthy decisions.  The way project management was meant to be…

2 weeks ago, I explained why I wrote the book and what it’s all about.

I propose you give it a read, and let me know what you think.  My next goal is to improve and extend it with the help of you, the readers!  That’s why I deliberately chose the lowest price plan on leanpub, from 0$ to 4,99$.  So don’t let the price keep you from downloading it, you can get it for free!

If you want to send your feedback or work together on new chapters, contact me via my website or twitter.

I hope you enjoy reading it!

If I were a tester on this project, I would do things differently.

In many cases, you even have ideas to do the job better.  Whether or not these ideas are valuable or achievable, ideas are always interesting.  They give an opening for improvement and learning.  Don’t let role hierarchy ruin this.   A junior programmer might have an incredibly bright idea to help you improve your role.

During an agile retrospective, we want to stimulate the entire team to think outside their context and come up with ideas that can improve the process.

A great exercise that enables this, is role swapping.

• You write down each role of the team on a card.  So a team of 9 will have 9 cards.
• In random order, each team member chooses a card.  Try to choose a different role than your own. (You might have to level out the team roles to make this easier, because typically half of your roles will be ‘Developer’)
• For a couple of minutes, we reflect in private on how you would do the role differently.
• When time’s up, we share our ideas one at a time and discuss.
• Concrete actions get recorded and planned to be implemented.

This exercise can only be effective when there is enough trust between team members.  People need to be open to suggestions and willing to discuss options, so they can learn from each other.  If your team is not in that stage yet, you’re better off doing exercises that build trust.  The effect of the role swapping exercise would be limited anyway.

Give it a try, you will be amazed by the ideas that pop up.  Plus, it’s a fun exercise to do as a team.

Why?

This annoys the hell out of my colleagues, family and friends.  But, I’ve learned the hard way, that taking enough time to trace things back to its roots, is worthwhile the effort.  Why are we doing stuff?  What’s the purpose?  Only by answering these questions, we’re able to tell upfront whether an initiative is worth starting.  If any doubt should surface, we need to rethink the whole idea.  Because we already know that it’s going to be hard to keep up the energy for a half-baked purpose.

I’m currently writing an e-book, called Kanban for skeptics.

It’s only fair if I ask myself: Why?

There are 3 reasons:

1. I want to make Kanban more accessible to the general public.
   In my role as a coach, I constantly need to reassure people, that the path we follow, is worthwhile traveling.  This need is often expressed in the form of critique and difficult questions.  I noticed that Kanban raises tough questions on a management and leadership level, once people are introduced to the basics and start to explore the subject on their own.  The type of questions Kanban triggers, seem to be much harder to answer without lapsing into an hour-long discussion.  Books and conferences on the subject do not seem to address this need.  People get lost in scientific and management jargon, without any clear answers on primary questions.  By listing the 5 most common arguments against Kanban and my response to them, I hope to give people a response in a simple, yet profound way which is understandable by all.  I would be satisfied if more people got interested in Kanban because of the book and started to explore Kanban more deeply.
2. I enjoy writing and want to do it more.
   Ever since I started this blog, I realized that writing is something I enjoy a lot.  My dream is to write books for a living.  But I realize that I’m still far off. That’s why I need practice, step by step.  Writing a small e-book (70 pages) brings me one step closer to that goal.  Any other tips to improve my writing skills are more than welcome !
3. I want to get feedback and learn.
   We all hate to be criticized. I do too!  But I’m no longer afraid of it.  That took me a long time.  It’s quite scary to create something and show it to your peers.  “Will they like it? What if they make fun of me?”  You’re taking a leap into the dark, and exposing yourself in a vulnerable position.  This has a major advantage, though.  By seeking feedback quick and often, you get interesting feedback!  Am I on the right track? How can I adjust and steer myself in the right direction?  It works on many levels: personal, team and organization.  Personally, the moments when I learn most are when I get feedback by
   - asking somebody to review
   - presenting an idea to my colleagues
   - doing a talk at a conference
   - writing a blog post
   and I hope to get tons of feedback by
   - writing an e-book

I’m currently processing the reviews from friends and colleagues, but unless the world has finally gone apocalyptic, I will publish Kanban for skeptics in 2 weeks.  I hope you take a moment to read it and give me some feedback.  It’s free, by the way!

We can even collaborate to create next versions, which is the beauty of the leanpub concept!

As with all new conferences, their tends to be a special atmosphere in the air.  Curious tension, enthusiasm, I’m not sure how to describe it.

What struck me most was that almost every management session referred to Eric Ries’s book The Lean Startup.  Right from the keynote, to the last session. I’m guilty to that as well, I must admit.

This tells you something about the impact of this book. It feels like the entire software development industry has suddenly been shaken awake.  Everybody seems to realize that we were focusing too hard on the development part.  The issues in adoption of agile reflect this.  We’re not getting the expected results that were promised.  Sure, more projects get delivered.  But still many fail to match customer expectations.

The Lean Startup approach doesn’t sell a magical bullet to do this better, it attacks the root cause head on.  When developing a product or service, we make assumptions, no matter how much we test it in focus groups.  The only thing that we can do to get an answer to these assumptions is releasing fast and measuring how the users react. The next step is to learn and adjust.

Various talks in the conference made the link to these ideas.  Topics ranging from Kanban to continuous delivery, from agile to innovation, etc.

What explains the popularity of these ideas?  Maybe this is the next step in maturing the software industry?  Although I still feel like there’s something missing.  How do you scale these concepts?  Which consequences does it have on your organization and how do you deal with it.  I guess the journey has only just started. Exciting times ahead!

If you haven’t read the book, don’t hesitate.  It will get you thinking…

78% of all agile teams hold daily standups, according to the 2011 State of Agile Development Survey from VersionOne.

Each day, at a specific time, teams gather around the task board and plan their next actions.  Although this practice has been around for many years, it still feels awkward to some extent.  Especially for the Scrum Master and Product Owner.

Should we also explain what we have done and are planning to do next? Won’t this bore the team? Do I just stand there, and listen?

I’ve been in both roles before and will explain how I took part in the daily standup.

As a Scrum Master…

… I always prepare myself for 5 minutes before the daily standup.

• What have I done that is useful information for the team?
• What am I planning to do that is useful for the team to know?
• What does the task board look like? Any bottlenecks appearing?
• Are there any tasks that are left aside? How can I help to get those moving?
• Any user stories coming up that need special attention?
• How are we respecting quality?
• Is the preparation of the next sprint coming along? Does the Product Owner need any help?
• ….

As a Scrum Master you will always have something useful to say. It can be related to your role, but in many cases you will share an observation about the process.  In the end, that’s your job.  Helping the team to use the process in their advantage and deliver succesful sprints.

As a Product Owner…

… I also prepare myself before the daily standup.

• Do I have any additional information that is applicable to the current sprint?
• What kind of features am I preparing for next sprint? For which ones would I like feedback from the team (outside of the daily standup)?
• Any feedback of the stakeholders that’s interesting for the team?
• Is the team respecting the user story prioritization? If not, I explain why it’s important to me.
• Am I out of the office? If so, I explain when and how the team can contact me.
• Are there any user stories I can already review? Ask for help.
• …

As a Product Owner you will always have something interesting to share about the features. Those in the sprint, or those you are preparing for the next one.  Remember that you are the Single Point of Contact for the team, and most of the feedback they hear from the stakeholders is through you.  So share as much as possible.

I’ve noticed that as a Scrum Master or Product Owner, you can also bring a lot of added value during the daily standup.  It shouldn’t only be the developers talking.

Most people in software development have experienced the moment in a project where the quality level starts to be discussed.

In agile projects this happens on 2 levels:

1. Do we keep a zero defect policy?
2. Does all code need to be covered by tests?

1 . Do we keep a zero defect policy?

Agile software development is centered around the idea of delivering a potentially shippable product on a regular basis.  In practice this means that at the end of an iteration, your application needs to be in a healthy state, ready to deploy to production.  This can be interpreted in different ways.  Some claim this means you can’t have any open bugs anymore, while others categorize bugs and agree on which categories should be fixed immediately.  The first group doesn’t negotiate on quality, while the second group does.  I personally think that there is no right answer because it often depends on context.

If your project has a clear focus on one of the angles of the iron triangle (I hope we’re past the phase where we thought all 3 could be fixed), this can strongly influence the discussion.  For instance:

• Create a release before a certain date

Some projects need to be released before a certain date.  Because your product is targeting Christmas shoppers, for instance.  Or your company will have to pay a huge fine if it crosses a date.

Since the schedule is that important, stakeholders will focus on continuously monitoring progress to quickly adapt when the outlook on making the date is starting to look bad.  One option to adapts is to work on the team’s capacity, by helping them to improve their process or getting extra help.  Another option is to work on the scope, by making it more simple, reducing it, or negotiate on quality.

This last one is a tricky thing to do. Sure, deciding to only fix critical bugs, will make the team go faster, in the short run!  The problem is that bugs start to pile up, causing more and more issues in the process.  It will decrease the stability of the system, increase confusion while testing and make your process less lean because you regularly need to review the open bugs and categorize them.  Even the release will get more difficult, because training and support need to be aware of the bugs.  Risk increases that after the release you will get a lot of bug fix requests, causing an extra investment on top of support.

So is it worthwhile, then?  To some degree, in my opinion.  Many bugs, whether critical or low, don’t take that much time to fix if you do it on a continuous basis.  Many projects have bugs of a generic type, who take more effort to fix because they are linked to the design of the application.  This is where you can gain time if you want to make your deadline.  But make sure that the number of the bugs you won’t fix stays extremely low and get them high up the list of the second release.  Otherwise you’ll soon be in the mess I’ve been describing.

• Get as much value for a fixed budget

It’s healthy to set a target budget when you’re still figuring out the functionality of your system.  This gives you a baseline that helps to focus on not overdoing it and making a proper business case.

When budget is your main constraint, of course your stakeholders want as much value for it, as possible.  So naturally, at some point, quality will be traded in order to have some extra features.

Again this is a tricky thing to do.  For a while, the illusion exists that you got extra features and therefore made a nice deal.  But soon things start to backfire in the sense of increased overhead, slower delivery and most importantly an increased risk on a budget overrun by extra support and bug fixing afterwards.

Good idea? In the short run, maybe. In the long run, certainly not.

• Release a certain scope set

If scope is your only constraint, it’s much easier to strive for a zero defect policy.  Since scope is much more important than time or budget, stakeholders will generally have a good idea about what the functionality needs to be.  Keeping the product high quality will guarantee that you’re living up to expectations.  The features are the main focus of everybody involved, so they better work!

Continuously attacking all bugs will make the release much more comfortable and the risk on having to spend an extra budget on patches afterwards will be dramatically reduced.  So from an investor viewpoint, this increases reliability, which is always interesting if you’re in that business.

It seems like I always come to the same conclusion.  Quality can be negotiated, but to a very small degree.  And even then it will generate a cost that you will have to pay back eventually.

2. Does all code need to be covered by tests?

Since I have limited technical knowledge, I will not even try to say something intelligent about this and leave it up to Marc Lainez to write a blog post about it

If you want to talk about this kind of stuff, or just want to tell me in person how wrong I am, come to the next Agile Belgium Drinkup.

It may be just an informal gathering, but I’ve gotten new insights each and every time!

Every new team goes through a storming phase.

These are times when nerves are tight and you can feel the tension in the air.  As a retrospective facilitator, it is important to recognize this and plan your retrospective accordingly.  How? Let’s start at the end and work our way up.

1. What do we want as a result?

As a facilitator I want the team to agree on actions they will take in order to improve the situation.  This may be too optimistic for one retrospective, but at least I want them to express their true feelings and look for root causes together.  If the team gets to that point, a big step has been taken.

This may be culture specific, but it’s not easy to share your feelings when it comes to a group dysfunction.  Many prefer not to talk about a dysfunction because of the possibility of conflict.

2. How will I help the team to achieve the result?

First of all, your most important task as a facilitator is to create an open atmosphere.  I bet you all know 2 kind of meetings.  The meeting where only one person at a time is talking and others nod or remain silent AND the meeting where everybody talks to each other, with energy and passion, where in the end you have the feeling you did something together.  If you’re able to create this second type of meeting, people will participate quicker and are more willing to speak up.

There are different exercises and techniques you can use at the start of your retrospective to work towards this.  For instance, start as you always do, by going over the retrospective rules and purpose.  Then choose an exercise to get input on dysfunctions.  For instance the Hopes & Concerns exercise.  Group the hopes and concerns by topic and try to find a root cause by using the 5 why’s technique or some other root cause analysis exercise.  As soon as you can agree as a team on a possible root cause, you need an appropriate exercise for the team to work on this dysfunction.

The following exercise is a good match:  “How can we make things worse?”

It sounds stupid, but it works amazingly well.  As a team you start by defining your topic.  Suppose we all agreed that there is too little communication amongst team members, then the facilitator writes that down on a flip chart.  Then he invites everyone to write down ideas on some post-its on how we can make this situation worse.  That’s right, worse!  So in this case: “How can we communicate less?”

You will notice that people find it amusing, thinking about how they can sabotage things…  When everybody is finished, ask them to group their post-its on the flip chart and start discussing.  Let the team make some fun.  It helps to create an opening for what we need to do next, which is to generate insights.

Slowly turn it back around. Go over each cluster of ideas and discuss in group whether it gives you ideas to make things better.  For instance, if we have a cluster called “Work at different locations”, and we start discussing it, people will turn the idea upside down quite easily.

Facilitator : “Guys, can we use this idea for the better?”.
John : “Sure, we could do the exact opposite and move our desks closer together”.
Mary : “Maybe we can create a big square, so we face each other and can easily share ideas”.
Kanye : “Why is the tester not sitting in our room?”
…

Make sure you’re not only focussing on the search for actions.  If you want to get out of the storming phase, people also need to get insights.  We need to learn the other’s point of view and have to work on a shared framework of understanding.  Actions are fine, but don’t worry if it takes 2 retrospectives to get them. The hardest part is building the understanding.

3. How do I prepare for this?

As soon as you feel the team transitioning into a storming phase, it’s time for you as a facilitator to change your retrospective format.  Focus less on finding new ideas to improve, and more on creating shared understanding.  It’s important that you create a plan on how to approach this delicate topic.  Picture how you will introduce the exercises and what timing you need to facilitate them.  I always create a short schema just to make sure I don’t skip a step during the retrospective.  If you set the frame and guide the team through, the rest will happen by itself!

I quit one of my biggest clients last week.

For almost 2 years, it has been a major part of my professional career.  You can imagine it was hard to say goodbye after such a long period.

So why did I decide to leave?

Number one reason is that I started to feel settled.
This is my biggest fear, getting so used to the job that it becomes a routine.  I’ve seen this happening to former colleagues of mine.  Sure they knew everything about the company, its politics, it’s business rules, it’s history…  They felt in control.  But then suddenly the company started a big reorganization, and their world instantly looked different.  While they used to be experts in their domain, they had now become legacy, standing in the way of the new business processes.

From that day on I decided that I would never let that happen to myself.

When I experience one week without (healthy) stress, I would force myself to change.  Maybe inside the company, maybe outside.  That’s why I’m still happy to work as a consultant.  I get to switch projects once in a while, meet new people and face new challenges.  Basically, as long as I’m learning, things are fine. When I’m not, it’s time to do something about it.

I thought it would be fun to share my view of the past 2 years in a small personal retrospective.  I’m sure some of my former colleagues will read stuff they didn’t know about.

My 1st week was very hectic. I remember I first went to the SDC conference before starting at the company later that week.  I was tired of travelling and the stress of public speaking, but the friendly atmosphere at the office made it much more bearable.  As with all new projects, I started to dig into the business domain and local terminology which were quite new to me at the time.  I had never worked in the recruiting business before.

It soon became clear to me that this client had an extremely ambitious vision.  The entire business model was turned around to provide better value to its customers.  At the same time, the entire IT infrastructure had to be modernized to be able to support the new business processes.

I entered in what was later seen as the kick-off project of this change program. Lucky for me, the project was still starting up.

Since I was hired for my Agile/Scrum experience, I unleashed my knowledge to the team.  With wild enthusiasm I was confident we could become a great agile team.  Things did change. Not at the speed I hoped for, but we became a closer group and started to get into the cadence of our 2-weekly sprints.

The project entered its final weeks, and things started to heat up. It was almost time to release, but there were still too many bugs and missing features.

As a result, discussions got more intense.  In my opinion because I wanted to go forward full speed ahead, while some members of the team just didn’t care.  I learned later that the organization actually drove this kind of behaviour.

Our CIO who was, and still is driving the vision, helped the team and the product owner to get out of the deadlock.  One of his biggest capacities is that he can slice projects into releases like no other. He can spot options which others will never find.  I learned a lot about release planning from him.  So instead of dragging on until we could finally release the whole thing, we released a 1st version and updated it 2 times later.  While I thought quality would delay this project in the classical sense, it became a success by applying aggressive release planning.

If I look back at it now, we never had that energy and motivation again.  I haven’t found a reason yet. Did it take too much of the team?  I ‘m not sure.  Personally, I felt pretty confident for the next project.

At that time we had already split up into 2 project teams.  While one team was supporting the freshly released application, the other team was building a brand new customer website.  But since this was an architectural renewal, we had to deal with a lot of legacy and synchronization.  What struck me most was the big variability during this project.  We tried different methods of planning & measuring, but never really got it under control.

This was a painful project, from a PM perspective. But again, we managed to release a pretty decent first version of the website and gradually finished the remaining details.  From a team member perspective, this was a project to be really proud of. A new fancy website with lots of visitors every day.  The shiny access gate to the company!

Meanwhile the second team started a 3rd project, which got highest priority from our stakeholders.  A couple of new people came into the picture, and we continued on our way of working.  Many ‘Agile’ practices were present, but with less and less enthusiasm.

It became harder to keep the business stakeholders closely involved, since we seemed to slip from a product view to a technical view.  This made it hard for them to understand what we were discussing during planning meetings and daily standups.  Demos were of fewer interest to them because of the technical angle.  As a result, feedback got delayed and the gap between what was planned and what was delivered became bigger.  But again we managed to successfully release the system.

We came to a turning point.  Or we could pull our act together and try to move back to the agile core, or we moved to a more classical phased gate approach.

The 2nd option was chosen with best intentions.  I was not disappointed because we knew we needed to try something different.  After almost 2 years, it became clear that the organization was not ready to embrace agile and get full use out of it. In my opinion this is in many cases the root cause of why an agile adoption doesn’t sustain.

I loved this customer so much that I was willing to give it a try.

But one of my biggest fears started to form. The start of the next project got delayed because it first had to be analyzed to a large degree.  However, because of the rapid changing business, it became impossible to pin down the requirements in that amount of detail.  One week, we felt like we were almost finished. The other week we were back off to zero.

At the same time, the development team was waiting, eager to get started.  So they kept busy cleaning up their stuff, doing technical tasks, until they got tired of it and the atmosphere started to change.  A classical decision was made to add more analysts to speed up the requirements gathering.  Off course this resulted in even more discussions and less progress.

This is when I realized that I had played my part and should leave it to others.

It was a tough decision to make, but a necessary one.  Although I’m going to miss my ex-colleagues, I’m also looking forward to learn new things, meet new people and most importantly have healthy stress again.

Many thanks to all! I’m sure you will release many more fine applications and I hope together you will find a process that fits the organization.  Who knows, we might meet each other at a conference where you’re presenting an experience report.

Since the beginning of the year I started my own business. You can now hire me as an independent consultant.  Keep an eye on this website.  Things are going to change!

 
(image by -eko-)