Agile in Practice Experiences from my agile life

A pillar at the sea

I am sharing my own experiences of an agile life. While I started using agile techniques many years ago I only learned following the agile approach when I started my latest project in early 2009. Since then, I learned a lot from the community and my own colleagues. Agile has become a pillar on which I build ideas today. Now I like to give back some part of it what I find interesting, hoping that you, the reader, will gain something from my views and ideas.

Experiences in getting certified and especially as a PMI-ACP

5. November 2012

I am often asked to share bit about my experiences in getting certified, so here is my story…but beware it is going to be a long story (which is why it took me so long to write it down).

The Scrum certifications

I am sure many of you have at least thought of getting certified in an agile domain. While the most widely known certification has always been the Certified Scrum Master (CSM). over the past years many have also noticed that the role of the Product Owner is even more important, which is why the Certified Product Owner (CPO) has become more prominent and thankfully more and more within our community have become certified as a CPO.

There is quite some history though on the certification as CSM. Many have complained that you just have to visit a course to become certified (as I did). Then, after the Scrum Alliance had introduced an exam, many complained that it was a test that you cannot fail. Scrum Alliance has again fixed that recently (see here) . Even though they say, you get your results immediately I am not sure to what detail the information is but more about that below.

I was honestly never into certifications at all but being a passionate agilists, running and coaching agile projects, giving training I thought it would be important to look over the rim and get to know others and learn other ideas. This is why I got certified as ScrumMaster. I actually only did that after I had some experience, which is probably not the best way but in my case the course itself gave me the chance to learn answers for many of my questions that arose from my daily challenges within the project being agile (fortunately the people within my project like me had some previous agile experience, so it wasn’t too bad in the project without a certification ;-). Thus I came back with new ideas and answers and that really kicked off my enthusiasm even more within the project. Over the following months I learned more, the CSC community became bigger and I was interested in the next step:

The Certified Scrum Practitioner seemed to be the next subsequent and consequent step. By that time it wasn’t a multiple choice test as it is today, I had to give compreshensive answers to 20 questions, which in my case led to a 17 pages document that describe essentially how you practition agile in the real world, how you deal with challenges of Scrum and how you establish the continous improvement process by telling stories that give real world project evidence. This was then reviewed by a certification board member and you may pass or fail. I actually like this idea because you really have to prove and explain what you have experienced. For reasons which are not clear to me in the meantime it has also become to be a multiple choice test. My best guess is that the old approach does not scale very well…By the way, I hardly haven’t met a CSP who is not a practitioner or at least passionate about the topic.

As many know the Certified Scrum Coach or Training are nearly impossible to get if you are not a full time Agile Coach and you are not putting a lot of effort into the Scrum Community by writing blogs or books or giving speeches in conferences. Therefore I called those quits approaching them.

The alternative

Most of you know, the Scrum Alliance “lost” Ken Schwaber and Jeff Sutherland who then founded the With them we have now a Scrum certification alternative now (see here), eg. the Professional Scrum Master (PSM). Their main difference is in terms of the certification: they also have multiple choice tests but you can do them online and without having participated within a training. On the other hand they are known to be comparibly difficult so it is advised to take the training. You can register with the and check out an open assessment. I have not taken the training but I know of people (within CSC) that have and even have failed at the first time – so don’t underestimate the difficulty level.

PMI-ACP – The PMI agile alternative – My ups and downs

I am aware that in the in meantime more and more alternatives pop up and I love to hear about experiences. However the one that I encountered and thought it was interesting to look at was the Project Management Institute – Agile Certified Practitioner – short PMI-ACP. PMI monitored the market and came to the conclusion that “PMI’s research has shown that the use of agile has tripled from December 2008 to May 2011″. So PMI started to work on a PMI Agile certification in February 2011 and invited people like Alistair Cockburn to the committee. They had a beta in the end of the year and it started around the beginning of this year officially. Many in the agile community who had known the PMI for their traditional project management were very skeptical about that and so did I.

However, it turned out that the PMI did their homework. Even though I have the feeling that the topic was formed mainly around the books that some members of the commitee have written or the really famous books (I am sure it really drove their selling lately, which I by the way support because most of them are a good read) , the list of what is being checked during the certification is pretty comprehensive (for those who want to know what the 13 books and topics are in detail, look up the PMI-ACP content outline: it is categorized around two areas: 50 % is about “agile tools and techniques” and 50% is about “agile knowledge and skills”. It is pretty comprehensive as it does not only cover Scrum but also Kanban, Lean, DSDM, Crystal in terms of methodologies but also aspects like stakeholder management, progressive elaboration, distributed teams, team conflict management, servant leadership or how to organize retrospectives:

The Tools and Techniques consists of:

  • Communication
  • Planning, Monitoring  and adapting
  • Agile Analysis  and design
  • Product quality
  • Soft skills negotiation
  • Value based prioritization
  • Risk Management
  • Metrics
  • Value Stream Analysis

The Knowledge and Skills is a long list, which you better lookup in the content outline. However, PMI defines also

Domains of Knowledge:

  • Value Driven Delivery
  • Stakeholder Engagement
  • Boosting Team Performance Practices
  • Adaptive Planning
  • Problem Detection and Resolution
  • Continuous Improvement (Product, Process, People)

If you consider this as a content of a certification, this is a much wider knowledge that you have to build to what “just” Scrum is. Honestly, if you want to run Scrum projects successfully I am sure now and then you already encountered quite a number of all of those topics but sometimes rather coincidentally. This certification makes you think about it more. This is why I thought it makes sense to go for it.

I by chance had the opportunity to talk to Wally Moore, from PMI, who is PMI’s relationship manager to the company I work for, in July this year. He for example told me that the PMI-ACP was the certification that really had the highest increase rate of all new certifications they have provided to the market. Even more than 5000 people had registered for the beta phase (but not all took or passed the first exam). So, taken into account the widespread content of the ACP-content and PMI’s reputation I decided to go for it.

The first things that I encountered were the eligibility requirements which I thought were good. Remember, it is called PRACTITIONER. When I am preparing for a certification like that it should indeed separate those who have just learned it theoretically from them who know how to do it. Therefore I was happy to see that there requirements were tough to reach. Unfortunately I cannot currently prove it but shortly after the beta they decreased the eligibility requirements to something that if had them, I would not call myself a practitioner: 2000 hrs working on project teams, 1500 hrs working on agile teams. You are not required to have been a PM on a traditional project, nor you are required to have been a PO or method facilitator (aka ScrumMaster in a Scrum project) – you are just required to have been working in a (agile) project. This definitely has watered the eligibility requirements. My feeling is that PMI wanted to have more people to jump on the certification wagon (it actually shows currently that many do the certifications on top of a PMP or the courses only for PDU-purposes) and it would have been harder the previous way. However to me this lowers the value of the certification.

But even worse to me is audit process. It is just a formal one. What does it mean? Well, when you register, you automatically adhere to the ethics of PMI, so you have to be honest of what you you tell there and you have to list all projects that prove the above eligibility requirements. As long as you don’t get audited, you could basically tell whatever you want (even though this is against PMIs ethics and if proven you will be disqualified!). If you get audited, and I did(!), what you essentially have to do is, download a prefilled form from the PMI-registration site that exactly contains what you have told what you did. This exact form needs to be sent to your contact person whom you have defined to be able to prove that. The form needs to be signed by that person and sent back in an enclosed envelope. You collect all of these and send them to the PMI via snail mail. Everything’s fine, right? No, not really from my perspective. First of all, rumor says it is only about 10% of the people who get audited. Secondly, you usually would only name a contact person whom you have a good relationship with – why would the person then not sign what you pretended to have done? As far as I know this is the only thing that PMI checks – whether the contact person signed. They are then not questioning this. PMI, if that is wrong, I am happy to correct. I would actually love if the PMI would make random inspection calls with those stakeholders and interview them. Even though ethics do not allow to cheat, believe me there is a reason why I would love to see a deeper audit… (sigh). Thirdly, the audit process takes so long, you lose a lot of knowledge you learned in a PMI-ACP preparation course. In my case, I thought it would make sense first to go a preparation course to find out what gaps I had, then register for the certification. Wrong! Never do so: Why? Because then the audit process started and of course you need to give your contact persons time to answer, then send it to the PMI (oversees), then wait for the PMI to accept (or reject). In my case, as far as I remember, overall it took more than four weeks. Even worse, at least 2 weeks after having sent the documents to the PMI I got an automated reminder to please send the proof. I then contacted PMI directly and surprisingly the next day I again got a (automated) message and not a personal answer that they had received it…  Most of the details I learned from the prep course were gone and I more or less started learning from scratch – what a waste of time (not a really lean thinking…). Lessons learned: Only register for the certification when everything you need to do is under your own control. The second lessons learned was: Only show edit eligibility requirements that are barely sufficient (again lean thinking). Why? I listed more proof (a longer list of projects) than what was really required. Naively thinking this would maybe convince someone at the PMI that this guy is indeed a practitioner…It only resulted in a longer list of proofs I had to made and more people to be contacted, convinced to sign and send the enclosed envelope back to you. Sadly me feeling is that the audit process doesn’t really raise the bar of the eligibility requirements but made me lose a lot of time for my learning.

How to get prepared for the PMI-ACP?

What the PMI basically tells you is: Here is the list of topics and here’s the list of 13 books you should read. There is nothing like a traditional PMBOK which summarizes the content. This is were the training providers jump in: They provide PMI-ACP prep courses. So, what do you learn in the course? The whole content? No! The intent is to give you an overview on mostly all of the listed topics and is provided as means to identify the gaps of the knowledge you need to work on. At a certain point in time there was one thing I didn’t want to hear anymore from those who knew me: “Don’t worry, you will be fine in the exam”. Even though I appreciated those who appreciated my knowledge, in hindsight from my own perspective I would say I would have failed the exam if hadn’t learned the topics thoroughly. It is actually something positive I take from the exam because that tells you that the questions are indeed sometimes pretty tough to answer without learning.

So how did I prepare myself? As I mentioned I took a prepare course which runs over 3 days and automatically provides you with the 21 PDUs you need to have (I already had had enough PDUs through teaching myself and a Kanban course I had participated in but I wanted to be able share experiences of the prep course and know my gaps). Then I had this long wait time because of the audit process. Then finally when the audit was through I made sure I had a long weekend (Friday through Sunday) on my own without family and started to get prepared. Before that I read thoroughly Mike Griffith’s book “PMI-ACP Exam Prep, Premier Edition: A Course in a Book for Passing the PMI Agile Certified Practitioner (PMI-ACP) Exam”. I was actually surprised by the concise content of the book. To me it is not only a book for someone who prepares for the certification but anyone who wants to have a broader look at the topic. With the course the course provide delivers not only the book (which can be separately bought) but also Flashcards and an exam simulation software with hundreds of questions (see here). I prepared myself mainly through the exam questions which can be run based on “agile tools and techniques” and “agile knowledge and skills” or based on the domains (see above). Every time I wasn’t sure about the answer I either picked up the book (or others I own) or researched the internet. By that approach I got to know the gaps and directly was able to fill those with new knowledge. Then I took the simulated exam which provides you with 120 questions within 3 hours (like in the official exam). After I did well there I finally took the what they call the Super-APC-exam which are 120 most difficult question. With that I felt pretty well prepared the next day.

How well was my preparation?

As I said I prepared myself over the weekend and I took my exam on Monday morning to make sure I had  a fresh mind, thus felt positive when I entered the exam. One thing that has to be mentioned: The questions are English only! And I have to tell you the question use an English that is sometimes really challenging to understand. The reason why I am mentioning this is that I think it is discriminating non-native speakers. I was sometimes challenged by some of the questions and answers that sometimes had only subtle differences which were important to be understood. Dictionaries are not allowed and I think the fact that you pass or fail should not be something where native speakers should have advantages – PMI must definitely think about that. Be also aware that others may distract you as you are not alone. Especially if you start getting nervous any further distraction makes it worse especially when you additionally have loud aircon that prevents you to concentrate (sigh).

How the exam went

I actually thought I was well prepared and I think I was but… When I left the simulated exam I was able to answer the questions in seconds but the real exam is still different. They have a different ways of asking and they had different focuses. The result was that I hardly couldn’t answer any of the first ten to twenty questions in a safe way which definitely made me nervous. I convinced myself to go on and mark every question as “review” where I wasn’t completely sure. I can’t tell you how many I marked but it was definitely more than half of all questions, honestly! I made it through all questions in roughly a bit more than an hour. Then I went only through all marked questions. For each of the questions I made sure I read the answer completely right (beware the nots, nevers, always, ideallys…) and then went on with a process of answer elimination – each by each. This again took me roughly an hour. By that time I started to become more comfortable (and not capitulating which I had in mind after the first twenty questions). Finally I again reviewed all questions quickly: Read the questions, read my answer, feel comfortable with the answer and then cross-check with the other answers. I recall that through this process I again changed (only) 3 answers. I was done 10 minutes before 3 hours and decided this is it and don’t look back. Sometimes, by the way, I really had the challenge to find the right answer because I would have said “it depends”. Especially because many of the topics deal with soft skills and sometimes as a Facilitator you need to  be sensitive and there is not the ideal answer and it just depends on the situation. In some of these cases experience really helps to envision the situation and answer the question. Sometime the question helps if it mentions a word like “ideally” because then the answer usually becomes easy.

I pressed the button to get the exam results and … had to answer a survey … only then I was allowed to send my answers and after a seconds I got the result: I had passed. It actually gives you feedback whether your on average, under average or proficient in both of those areas. And this is again something were I complain: Agile is about continuous improvement and learning. If you fail you hardly get any feedback on why you failed - they only tell you on both areas that you are under average. You don’t know which questions were not answered correctly! And this is what I hate about certifications: the exam does not give you any way to improve yourself, it is not about learning and improving it is only about passing!

Executive Summary

I won’t be surprised if some of you just jumped to that section , so here’s my essence:

  • PMI made its homework – the content is comprehensive and passing the exam is not an easy task
  • To make sure that the PMI-ACP is really a practitioner’s certification I would want the eligibility requirements to be higher, the audit more personal (adding interviews of contact persona) and the questions even more tied to situations that only practitioners can answer
  • Only list what is barely sufficient for your eligibility requirements.
  • Choose a prep-course that is run by a trainer who runs agile projects
  • Only take a course after fully registering. You have one year before you have to take the exam
  • Participating in an agile exam I would expect a much more detailed feedback on why I fail the test and guidance. The best would be if the test would show all incorrect answered questions with the right answer. Why not? Isn’t it about learning them? The people under test are not allowed to take away or tell anything after the test anyway, so there is no risk, they will spread this knowledge.
  • PMI must allow dictionaries not to discriminate non-native speakers.

Finally: If you are a practitioner, you are well prepared and you get nervous during the exam, follow my approach (see above) and I am sure you will pass…

Was it worth it?

Yes – it was.


Poker Planning on T-Shirt-Sizes

22. February 2011


Many of you have definitely heard about Poker Planning. If not, let me quickly recap the idea: The intent is to estimate sizes of user stories but with the special perspective of the team, not the individual. Given “the cone of uncertainty” project management tells us not to invest to much work in too fine granular estimation. So what is the intent and how does it work:

(short notice: for those who know poker planning in and out, jump to “Coming back…” at the end right away)


* The complete team should estimate to build an estimation of the user stories for the team and not the individual
* Each and everyone of the whole team should learn about all stories to get a comprehensive view on the project
* The team establishes a unit for the size (mostly points) during estimation with which a velocity can be measured for the sprint (V = Points / Sprint)

Way to go:

1 The team comes together
2 The Product owner tells the story to be estimated
3 The story is quickly(!) discussed
4 Every participant draws his/her poker card (on the card you’ll find a number)
5 Chances are high that not all drew the same number
6 Only the one with the highest and lowest vote get a short moment to discuss about their votes
7 A new round of voting happens and reality shows that the votes of the whole team converges very quickly.
8 Continue with 2) only as long as the team is not getting tired…
9 So that’s it.

The outcome is a pile of user stories that is understood and estimated by the whole team. As you know stories are taken from the product backlog and put into the sprint but how many stories do we take? Let’s step back a bit. As any story has a number of points at the end of the sprint we just count the points of all stories that team has finished under its definition of done. This is what we call the velocity. Let’s say the team produced 40 points. Taken the fact the team does not change, for the next sprint we just take so many stories from the backlog until their story points add up to 40, the teams velocity. Sprint planning becomes a piece of cake (as long as the backlog is prioritized).

So, where’s the catch?

Remember the title at the very beginning? The question is about what unit we chose and how we scale it:


The unit should be as neutral as possible. Why? It should NOT count hrs, days etc. but a neutral unit that represents a SIZE of a story and NOT how long it takes. But how do you measure the “size” of a story? Only by personally comparing it to the next one. This is not rocket science. It is personel estimation which is becoming a team estimation through the poker game. Duration is always very personal, size is not. The recommendation is to use POINTS which are completely neutral but more important it is possible to add them up. Only if it is possible to add units up, you can get a velocity which is required for the planning and the team to know its velocity.

What’s the point?

Scaling the units: A story of a size of 2 points is twice as big as a story of 1 point. 5 points is five times the size of a one point story. 100 points is 50 times the size of a 2 point story. What about 101 or 102 story points? Are the 101 or 102 times the size? Mathematically, yes, in reality I doubt it. Humans tend to run out of accuracy when they come to big numbers. The higher the number the more inaccurate is the estimation. If you would allow to estimate at 101 or 102 points it would only PRETEND higher accuracy which is not. Therefore people have come up with a scale that has a higher distance between adjacent numbers the bigger the numbers get. Therefore they typically use the following sequence

1 – 2 – 3 – 5 – 8- 13 – 20 – 40 – 100

This sequence looks very similar to the famous Fibonacci Sequence. A number is the sum of its last two predecessors making the distance always become bigger and bigger. Our sequence differs slightly in that it doesn’t start with two ones (1 – 1 – 2 – …) because we do not need the number 1 twice and also we start rounding with the number 20 which normally would be 21. Like I said above even 21 would pretend a certain accuracy that isn’ really there.

Coming back to the T-Shirt-Size…

Now, I’ve seen some teams over the year who used a different way of setting up their scale on Poker Cards – they use T-Shirt-sizes like

XS – S – M -L – XL – 2XL

I found out that typically the team chose that sequence because it felt(!) for them easier or more natural to grasp the size (remember it is T-Shirt-sizes) but how do you actually compare the sizes of the stories? To me (and probably most of us out there) it becomes even harder to compare the story by that. How much bigger is a XS-story compared to an XL-one? What is the actual scale of that story (linear / non-linear)? What lies even deeper is the fact that you cannot sum up: What is the size of the sprint 2xXS + 1xM + 3xXL? And even worse: What is finally the velocity of the team of the sprint and on average over the last three sprints to plan the new sprint? The velocity is important to know. Finally Scrum is also about efficiency and therefore team needs to know how fast and efficient it is!

Recommendation: Don’t go for it

Try T-Shirt-sizes out if you want because you are the team and feel free to try what you may make you more efficient. But I highly recommend not to go for that because you are losing to many options and chances that come from using story points on a non-linear scale.

the above image represents a set of poker cards that a colleague has designed for my team

Get started the right way

11. July 2010

Go together

I was recently approached by a disappointed colleague. She told me she had read a lot of our communities’ introductions to scrum and agile and applying it to her  team Scrum had failed almost completely.

First of all I asked her about her role and relationship to the team. She told me she was the the project lead of a small team and as the project didn’t work very well (budget and timeline wise) she thought about introducing something else to improve the situation. As we always say “start small”, she decided to establish the Standup-Meeting and introduced the burn-down-charts.

What was meant as a support turned out to be completely negative to the team

The result was devastating: The team didn’t like the Scrum Standup at all. They actually kind of refrained from telling what was happening in the project. The burn-down was even worse. No one was willing to provide  information. What was meant as a support for the team actually became a threat to the team.

I talked a bit more about the project with her and we quickly found out that team had no background at all about  Scrum or Agile in general. No one ever had told them about the principles of the agile approach. They hadn’t learned that the techniques and principles are about the team and not about someone who leads the project. They only perceived the techniques as a new way a becoming even more controlled by the project lead.

Explain what agile means

The issue is that the team never learned what the idea behind Agile is. No wonder that they felt even more supervised instead of being empowered. They hadn’t understood that the Standup meeting for them was meant to be an information platform to spread news about what happened lately, what is going to happen soon and what’s an issue currently within the team. They thought it was kind of a standing investigation of the project lead. I may exaggerate that real situation a bit (I was never with them unfortunately) but I am sure I am not too far off. Even worse of course becomes then the situation when you introduce the burndown too. Not knowing that the burndown is for the team (actually only) to synchronize themselves if they are still on track to their commitment, the team of course even more got the feeling of being even more tightly controlled than before.

Start small but explain first

So what had went wrong is that the team never got an introduction to Scrum. You need to do that wisely. Many teams that have gone astray with their project are very sensitive when someone introduces new techniques that make the project more transparent. Us agilists know that Agile Projects are in many cases more transparent than one would think. Most people who know nothing about Agile and who go through my courses tell me in the end that firstly they haven’t thought that agile is more controlled than the word agile made them thinking and secondly that they were extremely surprised how transparent the project all of a sudden becomes. To many this really comes so much to a surprise that even though they were enthusiastic about agile before the course, they feel a bit scared about that after knowing that. It is just too human sometimes not wanting to be too clear about where you are..

What I would recommend is

  • Tell your team about Scrum – tell about the principles and techniques
  • Only the understanding of the whole Scrum process with understanding all feedback loops and techniques makes you understand what the intention of Scrum is
  • However, when the team knows the whole Scrum Framework, it doesn’t need to implement all of it as long as it knows what the aim of all is
  • Have the team trained as Certified Scrum DevelopersThis course was only introduced lately by the ScrumAlliance. It is the course for the Scrum Team Member. I highly recommend that. This could be easily even done by a knowledgeable ScrumMaster (Be aware though that you need to be CST to certify people!) and could be also done by the those who drive the community within your company.
  • Be sure you have a Certified Scrum Master on board -either full time or as a coach who helps you with getting the project started.

the above image was taken nearby our house where the sign on the street reminds people to go slow because of children. To me it looked as a nice metaphor for going together the same way holding each others hand in a trusted way.

The ScrumMaster in kindergarden

28. February 2010

well prepared environment

“Help me Do it myself ” has been Dr. Maria Montessori’s first work on her ideas on chilrens education. She developed ideas how to assist children develop the abilities by making their own experiences.

I am sure everyone of us has learned that guiding teams is sometimes really hard. The teams are diverse in mentality, person’s characters, motivation and engagement. While we always strive to have a sustainable pace we have to meet some goals, too. This can only be reached if we learn each day to improve ourselves and the team. Please stay with me during this little essay: I will first write quite some ideas about children learning – later I try to relate this to agile development and teams.

How I learned about Montessori

Before I start to talk about the interesting ideas of Maria Montessori, I need to mention that I started reading about her, six years ago, a bit ahead of the time when our son was born. I wanted to find out how a child can and should be educated. After reading some books I noticed that a kindergarden (Maria Montessori calls it a “children house” / casa de bambini) was nearby to where we live today. We participated in an introduction evening and there I asked one of the kindergarten teacher if every child was “appropriate” to the Montessori Pedagogy. She smiled back to me and said “Yes, every child is, but not every parent”. Wow, that really made me think! What she meant is if you want your child be raised based on the Montessori ideas, of course you should live up to the same ideas by yourself otherwise you would just counter it. Today our is a happy member of the “Kinderhaus” since 2008 and he, as a person, at least to us has become a person who is joyfull, self-confident with a  good portion of self-competency “but” still a very “normal” child. Let me explain why this is so important to us:

How should we actually learn and teach new things? Enter Montessori!

One of the main ideas is nicely expressed in the few words I mentioned in the beginning: “Help me do it myself”. Though not said by Maria Montessori herself but by a child she worked with, it greatly expresses that teaching does not mean to throw new information and requests onto the child who wants to learn but to prepare the environment to let the child experience what it wants to learnd and what it is open to. Children (and adults too) have the capability and the motivation to learn by themselves (though learning ability over the lifetime of a person changes). They are eager to strive for more information and are hungry to learn. Maria Montessori though emphasizes that every child has its own point in time to learn what it wants. This is probably one of the hardest ideas to accept as an adult (or parent). In education most of us learned in school that the teacher decides what is to be learned at a certain time. If you have children you most probably know a lot of other families with children and you happen to compare your own child with theirs (I am not free to that!). Guess what, they all develop differently, even though seen over a longer time frame all children learn similar things (like walking, speaking etc) but just not at the same time. This is why every child choses its own point in time to be “motivated” to the next step.

Did you ever try to teach a child a special topic but I didn’t want to listen or to work on it? If you have never experienced that you are probably one in a million are you have no children…Even if you don’t like to compare your child with others, you eventually will do. Parents many times try to make their children learn the alphabet or numbers before elementary school and nicely fail because the child just isn’t interested. The reason is that the child has not chosen to work with numbers or the alphabet yet. But how shall I then teach my child?

Learning  and teaching  differently

Disclaimer: As I am not a trained montessorian teacher I can only reflect what I think is important and I hopefully have understood the right ideas within her pedagogy.

As I said before, children do not need the motivation to learn, they need the right environment. Maria Montessori noticed that children learn by viewing and by mimicking others behaviours and techniques. When you have the chance to experience how a child learns something new from its montessori kindergarten “teacher” you would see a lot but you wouldn’t hear anything. Everything is shown in an exact order of steps but it is not explained verbally. The spoken word would only distract the child from mirroring the action in his own mind for later replicating the same thing. The child then starts working on that task and only when it needs help and asks for help, the teacher jumps in again (for those who are montessorians I know that this is a simplified description). “Help me, do it myself”.

The highest degree of concentration on a task a child performs is called “normalization“. You all have experienced this one situation: A child is sitting in a sandbox and lets the sand flow through its fingers for minutes and minutes without noticing anything around it This is a totally concentrated “normalized” child. Many adults try to achieve a similar mood by doing meditation!

To support this, the children have a well-defined tidy environment with well-defined rules (far from laissez-faire!). Everything has its place and having done the work, it has to be put back to where it belongs. If you ever went into a montessori room (which is where the children “work”), it is amazingly quiet - not that nobody speaks but in a room where many work it is obvious that here not everybody should scream around disturbing and distracting the others.

This reminds me a lot to our working condition. We, as a team, wanted a room where we all would be able to sit together and work to keep communication very much integrated within the room. However with sometimes 12 people in one room there has to be discipline not to distract the others too much. Again the “tidy rule” is something that makes it easier for everyone to work in the project. Of course tidyness not only relates to the room but to the whole work: Put the documentation back to where it belongs, keep the source code in a tidy state (remember the boy scout rule!) and so on.

One of the really nice things is the way the children in Montessori go through the years of learning. Kindergardens are typically grouped. Within Montessori kindergarden and schools(!) children stay in the one group for three years which has children of three years of age. In the first year they are they youngsters and are being helped by the older, the next year they become the aquainted and help the younger ones, the third year they are the oldest who feel responsible for the one- and two-yearers. Then, they “move up” into the next group and the cycle restarts: They are becoming the young ones again! This iterative way indirectly boosts their learning process of becoming a self-confident, helping and understanding person.

I often noticed in schools or kindergardens that children enter the building and at “some” point the day or the lesson starts (I may be unfair to some institutions here, though). Not so in Montessori: Every child is being greeted in the morning with a little talk (and when it leaves) and politeness and social competence is very important to the whole group. The children are not treated as adults but they are taken seriously and everyone is respected.This should remind us that everyone in our team should be respected and taken seriously. I good social competence is very important to everyone of us.

Weekly Kids conference

Just lately I heard about the “weekly kids conference” in the child house. It is a weekly meeting of the children at friday where the group looks back what has happened, where children present what they did and where special topics can be talked about. Wow, I thought, isn’t that what we call a Sprint demo and Retrospective in the agile world?

What role plays the kindergarden teacher?

What is the role of the personnel in the child house or in Montessori schools? Really different to what you have experienced in traditional institutions. There are much more like mentors and guides to the children than teachers. There aim is to listen to the child, recognize what they are open for and assist them to learn what they currently interested in and most open to, while they make sure the rules of the groups are followed. Doesn’t that remind you to a well-known role? The ScrumMaster! He/she is a mentor who guides the group to makes sure the aims of the projects are met, tries to move away impediments and supports efficient ways to improve. Very similar, isn’t it?


Maria Montessori has not invented all the things by herself. She, as science person (she was the first female pediatrician in Italy), put together many good ideas from others and added some parts by herself. This is the similar to Agile. Many techniques have been there all along, just the philosophy and the way the ideas and techniques have been put together with a nice name (“agile”) made it so successful.

There are still a lot disbelievers  who doubt Agile works as because it is  so different to the traditional project management approaches which is comparable to the pedagogy of Maria Montessori as many have no clue what it is about and cannot image that learning and teaching could work without pressure and without a totally controlled way.

The longer I think about the pedagogy of Montessori the more commonness I find to Agile. I leave the rest to you if you like to dive deeper into both worlds. I promise you it is worth it.

Further information on Maria Montessori

If you like to learn more about Maria Montessori, her ideas on pedagogy and her life, I highly recommend to recommend the summary on wikipedia and the little 4-minute-film called MARIA MONTESSORI: HER LIFE AND LEGACY that can be seen on google-videos.

the above image was taken in our child house and shows the well prepared environment with the prepared working material for the children

Testing in Agile

1. February 2010


Testing within an agile project for some people seem to be an issue. How can a team be able to keep up with testing while it delivers every second week. Instead of describing how you should do testing in general in an agile project (many have written about that already), I like to describe how we do testing in our current project. Many projects that work with iterations actually drove test teams crazy because the test team couldn’t keep up with the delivered product increments anymore. One of my past project almost ran against the wall because we delivered too fast and the test team escalated to their management and blamed us to be fast…

The project setup

Before we go into testing, it should be understood how the project actually delivers and what quality is to be expected. The current project runs biweekly sprints. With every sprint we deliver a “potentially, shippable product increment”. It is therefore important to define what we mean by potentially shippable. To us it means that the development team tries as hard as possible to produce as less defects as possible, hence deliver good quality.

Quality driven development

We therefore have established the following quality actions:

  • Each developer is asked to write unit tests for the service layer and code that includes rather non-simple logic or algorithms.
  • Each developer who writes a new screen or form is required to write a new frontend-smoketest that is possible to be run automatically.
  • Each user story that is implemented must be reviewed by at least one developer who was not involved in that user story. Found issues must be solved before the iteration is completed. Reviews and task that come out of the review have to be done in time to finish up the user story as fast as possible.
  • Tasks get the status “closed” when done. User stories only get the status “resolved” as they can only be closed by a tester (See below)
  • Known issues that have been found after a sprint has been delivered and have an impact on the quality of the software have to be fixed in the next iteration. Therefore we do not fully book the developers with user stories but leave some capacity for bug fixing. The decision which issues have an impact and when they have to be fixed is made by the product owner right at the start of the sprint

Testing during sprints

All these actions and rules increase the quality of delivery but do not guarantee error-free software. Therefore the team has decided to spent some capacity on rigid testing on the software before it is actually given to the client for usage. Testing is done in parallel with development, i.e. whenever a user story is resolved the person who is currently in charge with testing takes the latest build and checks the user story as a whole. If an issue is found, the user story is re-opened and given back to the developer who developed the story or closed if anything is okay. Because the tester is currently monitoring if a new user story has been resolved, only very few testing is done at the very end of a sprint.

Our sprint always ends on Tuesday. The team has decided to finish the last user stories on Monday evening, giving another day to assure quality for the delivery. This also typically gives the tester enough time to test all remaining user stories. Even found issues during that test are solved right away by the developers. If the developers run out of work, they can either fix remaining issues from previous sprints (all of which have been prioritized) or can work on FIXMEs or TODOS.

All in all this already delivers quite a good quality in a complex project. However there is still a major issue:  Even if all user stories are tested with care, noone can make sure they will not have side-effects. To reduce  side-effects that are easily overlooked we have established automated frontend smoke tests (which you can only efficiently do to a certain degree). Additionally as all stories are demoed more issues will typically come up during the demo because more eyes examine the software!

Testing sub-releases is the quality gate for production

Also normally not all sprints are actually delivered into production. You knew, there was a catch, didn’t you? Remember, the sprints are potentially shippable product increments. We could deliver as all user stories are done and are tested but we don’t because we want to raise the quality bar. Therefore we group sprints into sub-releases. Each sub-release must be thoroughly testet. While iterations are tested by user stories, sub-releases are tested by use cases which have their related test cases. Everytime new user stories are created they are either linked to related existing use cases or new cases are created, followed by adapting the related test cases. Only after the sub-release-test that is based on use cases and therefore has a different view on the product has been finished, the product is allowed to be delivered into production.

The above stamp was produced by Kriss Szkurlatowski and can be downloaded freely at

Happy new year and project

8. January 2010

Happy new year

How many times did you leave your project for vacation with a bad feeling about what would be when you come back especially when the old year is about to end and a new year is about to begin? To be honest, too me this happened more than I would actually like to admit. However, this year something had changed. Neither I had a bad feeling when I went nor when I came back. What a surprise?

Not really. What did we change for that? Let’s look what main three reasons are there why I did not feel bad when I left the project to go on vacation.

The project mood

This time I am running an agile project and it is based on a team that feels happy and responsponsible. Some of us went earlier and came back later from vacation, though there were a few people left to do the job in the meantime. Everyone of us though knew they would take care of the things that have to be done. Granted, we decided to slow down the pace around Christmas but still there was enough work to do.

The work to be done in one or three weeks? or two?

Through the last weeks and months like in every project there are things that kind of pile up that everyone of us wanted to do. Even though they had value some other things were somehow more important. Also we noticed that we had collected  some bugs over time that we wanted to be taken care of. While we do have a sprint of two weeks and we never have changed it, it turned out that the latest sprint would start only one week before christmas. We now had the possibility to extend it over christmas but that would have lead to an end that would have been around new years eve where noone would have been there to come together for a sprint review. We could even further extend it until the 5th of January making it even three weeks. So, are we allowed to change the sprint from two weeks to one or three weeks? Keeping in mind that this is an exception to the rule and we wouldn’t like to blindly obey  rules, this time we decided not to shorten but to extend the sprint – but in a planned manner: We had fewer people on board with an extended period and again planned every thing like before. Looking back this was a good decision because Agile is about a sustainable pace and why not slow down a bit at the end of the year.

Doing the right things

However, if many leave the ship for some time there is the tendency that everything slows down a lot. A team consists of different archetypes of people. There are experts, workers, thinkers, drivers, genies etc. When most of the drivers are off, the team “drive” changes. Besides that we decided to name this sprint a “quality assurance sprint” which mostly consists of bug fixing and todos. The danger was that the team would “just” go along and would work on one thing after the other without really knowing where they would finally finish. Especially in this situation it was important that everything that should have been done was planned like in any other spring before thoroughly. People tend not to plan bug fixing which is extremely dangerous (especially when a team changes a lot). Therefore we did one trick:

We wrote down user stories that bundled bugs into topics like

  • fix bugs in the area of the frontend
  • fix bugs in the area of topic 1
  • fix bugs in the area of topic 2

Each of those user stories contained links to multiple bugs that had to be done. This way we achieved the following results

  • People were efficient in fixing the bugs because they were all in the some business or technical domain
  • People didn’t get distracted by the amount of two small work portions to be done
  • The bundles were like user stories because the business value is that a certain business domain was again fully functional
  • As the bundles became much more similar to user stories they turned out to be easier to be estimated

One tip at the end

In this kind of a QA sprint make sure that even the bug fixes that become like tasks for the “bug bundles” are actually all completely estimated. Even though it is harder to estimate bug fixes than new features it is still very important for the team to understand its status quo during the sprint.

As I came back all bugs were fixed (or questions were asked because of unclear circumstances as the product owner was on vacation too – hence, make sure that you talk about the user stories thorougly before starting the sprint) and the team was (almost) done. Everyone had a good feeling. We were again up to great quality and everyone was happy about a fresh start into a new year…

The above illumination was taken in a mall on the german island Usedom in the city Heringsdorf during a night shopping tour.

Looking closely – TO REview OR NOT REview

16. December 2009

Looking closely

Lately in our project we discovered a little bit of a quality issue. Actually it was more kind of luxury problem we noticed as we thought that the quality of our current release is pretty good already but we had been better before. While we had only three to four issues after a sprint the number of tickets have gone up into the twenties to thirties.

Therefore this fact was brought up in the retrospective and the time thought about what the cause is and how we go about it. One of the causes was that in fact the software has grown, hence the likelyhood to fail has become higher. Also the mix of experienced and rather unexperienced developers has changed. We were a bigger team now and have more unexperienced developers (especially within this application). Therefore the testing guys were kind of annoyed of the sudden quality loss – on the other hand you could say they had been to spoiled of the last sprints. So be it – but still the team wanted to something about it.

One of the proposals that came was to do more code reviews before it leaves development. A lot of discussion came up the the developers would like to substitute the tester’s work while the testers said their tasks wouldn’ be to test quality into the software – they were here for quality assurance. Finally the team decided to setup some rules how the review should be done and how much time and work should be put into it. The following is an excerpt of the teams ideas and rules.

  • What exactly should I review?
    • Do we have unit test, frontend unit tests?
    • Is the userstory implemented as written?
    • Is the code documented?
  • Frontend
    • Can all forms/screens be opened?
    • Are the validations implemented?
    • All menus/context menus are done?
    • Are shortcuts applied?
    • ….
  • Backend
    • Did we use the right architecture / software design pattern?
    • Is the persistence correctly implemented?
  • How should I document my review?
    • Every review should result into a comment to the user story in our tracking tool, which gives the testing people and the product owner feedback what QA we did in development.
    • For every review we add an estimated task to the user story
    • If rework has to be done we add another task
    • Tell if changes may have an effect on other not so obvious areas to be additionally tested

The above list only should give you an idea how we moved forward. Those ideas that – of course – were written to the wiki (thanks to Eric who wrote down and collected these ideas) and work as a guideline for the team.

How long?

One question that we discussed was how much time each developer would invest as they thought they shouldn’t substitute of what the tester would do. First of all, tester test differently: They have learned not only to look at the user story itself but also have a look at the some other areas in the surrounding. So developers will never make testers obsolete.

We then decided to relate the work to be invested to the review to the size of the user story, ie. to the story points. We defined 5 minutes per story points which of course is different in each project as points are only relative values and we surely will eventually adapt that number too. Just make sure you put that time into your original estimation – you would have needed typically that time (or even more) anyway for unexpected rework.


We quickly noticed that every review resulted into rework. Most of the time the rework had to do with fixes in the software because some part of the required functionality had been missed. Hence, we would have gotten back to that user story anyway.

Another tip would be not to procrastinate reviews. Do them just in time! Try to review not only more than a few hours after the user story has been finished

Finally make sure the reviewer and the developer should change as it turn out every (developer/reviewer) pair tends to have its own review pattern. Some even hardly wrote any review documentation (like only “user story was reviewed”) which helped nobody. So we mixed the experienced with the non-experienced, the un-motivated with the responsibility-driven people and so on…

Finally: the quality definitely went up again.

These binoculars are those of my son. The glasses contain some code from our project that was photoshopped into the picture. Thanks to Gerhard for the right trick to do that efficiently

Agile Estimation

1. December 2009

People are important

One of the questions that I am asked mostly is about planning and estimation. Therefore a recent question of a colleague led me to today’s episode:

Why do we distinguish story points on users stories and hours on tasks?

The reason is granularity and accuracy and also the relation to people and the efficiency of estimation.

Specifying and estimating the requirements:

  • First we prepare the product vision of our product to be built. This is something like a short essay what the key features of the product are.
  • When we start with the project, we actually specify use cases – but not all of them before we started developing. Only the most important features and only enough to get started. Of course we continue with them over the project
  • Now, we extract user stories. Fine grained “use cases” that build small features that can be implemented. These user stories are linked to the use cases. One user story can be used in multiple use cases to fulfill the use cases requirement. (This is need to for setting up testing)
  • With the user stories that have been dropped into the product backlog, we start estimating those based on story points
  • Based on product backlog user stories and their points and based on the team’s velocity (see below), which is measured in story points per sprint, we take the number of stories that sum up to the velocity and move those into the sprint.
  • Only now the team starts to break down each user story of the sprint into detailed technical tasks that can be implemented. The main difference here is that we have decided that those developers that are most likely (but not necessarily) to implement the tasks should do the estimation. However estimation always should take into account that someone else in the team should be in that range of estimated hours.
  • After all estimations have been done, the hourly total of the user stories’ tasks is compared with the hours of available development capacity (minus some overhead)
  • Only now the team is asked for commitment to the sprint.

Why do we estimate story points first and how is it done?

  • The main point here is that estimation of story points is about SIZE. A story that has three points is three times bigger than a story of of one point. A story of five point is almost twice as much as a story of three points.
  • All story points are estimated by the whole team. As such the points (and therefore the size) are related to the whole team. We estimate the size of the stories for the whole team, so it is not person-related.
  • The teams velocity for a sprint is easily measured: Just take the number of story points that have been performed by the end of the sprint. The average number of the last three sprints make up the velocity.
  • Based on that velocity the next amount of user stories are taken and put into the next sprint.
  • To put it into a nutshell:
    • User story points are size (not effort) only.
    • Points refer to the whole team not an indivual
    • Points can be quickly estimated (we strive to estimative on average in two minutes)
    • Points are used for mid and long term planning

Why do we estimate tasks in hours?

  • As stated further up tasks are technical details that have to be implemented during the sprint.
  • As a best practice and to be more efficient we do not estimate each user story with the whole team. The team distributes the user stories to smaller teams or pairs who then split down the user stories into tasks. The people who take care of this work are most likely but not necessarily those who do the implementation. Thereby the accuracy of definining the tasks, the preciseness of the hour estimation and the commitment is pretty high. We experienced an accuracy of about 5% for the team for a sprint on avarage which is extremely good.
  • To put it into a nutshell:
    • Tasks are tied to Sprints
    • Tasks are estimated on hours to get effort  not size
    • As a best practice we try to let those estimate that are most likely to implement the tasks (though is not a rule)
    • Hours are compared to the available capacity


  • Commitment is therefore a two step process
    • The first part of the commitment is when the velocity meets the number of the story points for the sprint. Thus the team feels a realistic setting for the task building and estimation
    • The second part is when the hours are estimated and compared to the capacity
    • ONLY THEN, the team commits.

The above picture shows a close-up of one of our candles.

People ARE important

16. November 2009

People are important

This is the start of some episodes based on theAgile Manifesto. Even though a little bit aged (it is from 2001!) it is such a nice treasure in terms that it puts the idea of the agile methodlogy in only four taglines:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Please, not again…we know them by heart already. I know, we do but I learned that many times they are totally misunderstood. There are many false interpretations and myths about them which is why I like to add my five cents to them. In today’s post I will write about about Individuals and Interactions over processes and tools, which is the first tagline of the manifesto.

How do you read it?

Most people “overread” the word “over” – at least, this is what I notice. So the tagline becomes “All about people” but don’t care about tools and process. People ARE important, actually very important, but processes and tools, too!

Do we need processes?

Yes, we do. The process is one thing what the ScrumMaster is for. The ScrumMaster is not the project lead (again something quickly misinterpreted) but the coach and mentor to make sure the Agile Process (here the scrum idea) is undertaken the right way. Compared to approaches like RUP, CMMI, Waterfall, Catalyst or others Agile Methodologies are rather thin and lean approaches. Still they give guidelines that of course should be followed in an adaptable manner. SCRUM is a process that is important to be understood and followed but not blindly.

Do we need tools?

Yes, we do. Tools ARE important as they do make projects more efficient. You shouldn’t use tools only because they are fancy, you should use them to make them team more productive and underpin the aims the team likes to achieve. Not only if you are a developer you should use tools, the whole team can find tools that help to work in a more fun way. Don’t think only in software, paper and walls are fine, too.

There is a lot of discussion in the agile world whether electronic tools should be used for the process (like for project planning and tracking). There is less discussion when it comes to development like in Continuous Integration, Automated Testing, Wikis, Bugtracking.

Use what is most applicable to your team. My current team has chosen electronic tools over the wall (for project planning and tracking) to manage userstories and the storyboard and automatically generated burndown charts and the like it but as always, everything has its pros and cons. In our situation the pros far outweigh the cons.

People’s attitude

Having said that, people ARE more important than processes and tools. So much of the sucess of the project is about the people. But remember the tagline doesn’t say “People and Interactions” but “Individuals and Interactions”. Quite some time we forget that we are all different. People are far from being the same.

We all have different

  • experiences
  • social competencies
  • motivation and engagement

It is very easy to think that the ideal team consists of ideal humans that form the ideal project. Whoosh! Back to reality! There are no ideal people and no ideal teams.

The book says the team member should chose the project and not the project the team member but often we cannot chose to staff the member we want – the situation just dictates who will belong to the team. Differences in expectations and aims of the members are the typical situations. In my current project I had the opportunities to do the staffing for the majority of the members. I was happy to be able to do interviews. I told everyone about the upcoming project and then asked them why they would think they would be perfect for the team. Thereby I learned a lot about that person and his or her attitude towards the project. The technical skill actually was secondary to me!

Experience, social competency, motivation and engagement are very important for the project but don’t expect all the same amount from every member. Some will be drivers, some will be driven. Some are the extroverts, some will be the introverts.

The ideal team manages itself

How often have we heard that. I do believe it is true but not realistic. We are individuals and the team changes from time to time, so it will have its storming phases. My experience is that the team needs someone who guides them. Of course, this can someone “inside” the team. It could be a well-experienced member who has a distinct social competency.

Beware of one fact though:

Grassroots Democracy sometimes becomes

Grassroots Democrazy

This is one think the chicken are afraid of: The team does what it wants. It doesn’t listen anymore to anyone outside the team. The pig team in itselfs perspective becomes the most important – having forgotten that they are actually a service provider for the chicken. Don’t let the agile democracy become grassroots democrazy! As a ScrumMaster guide the team to a performing team that is happy to deliver what the product vision is.

We need tools and processes but Individuals and interactions are still more important

The above picture was taken at the beach on a german island called Foehr. It shows the shadows of a very good team – my family!

Opening the portal to become agile

8. November 2009


This is start of my new blog. It thought it may make sense to begin with a starting topic

How could one actually start to become agile?

Most people think it is a major challenge and that they need to dive deep into agile “methodologies”. Even though I wouldn’t recommend to start all alone without help of someone experienced, you still can start small without calling it agile. Let me describe how I started to become agile.

I think it is important to distinguish two areas:

  • The agile methodology and process
  • Agile techniques or practices

I started to become agile without even knowing I was following the agile ideas. That was far from following an agile process. I must admit that I even didn’t really understand what agile meant when I signed the “agile manifesto”. There the term agile was coined  to give a common name to those ideas that were floating around for years already.  So what was I doing by that time?

Use techniques
I was using techniques that are widely adopted in agile teams like the following

  • Write and automate unit and functional tests to improve quality
  • Establish Continuous Integration to reduce integration issues of developers software units
  • Talk to each other frequently and efficiently to improve communication
  • Be efficient about documentation
  • Produce the most important things first, the unimportant things never
  • Understand what it means to be a team – spread responsibilities and get commitment from all

I was implicitly mainly using Agile techniques and practices without knowing or understanding the agile mindset (yet) but who cares? It eventually led my to the idea of studying the whole agile mindset. Only much later I started reading about Scrum and understood that there is a more comprehensive approach to all of the different practices and a framework that puts these and other ideas into perspective.

Start using these techniques and try to understand them by talking to someone who knows and cares.  That way you begin with a small toolset to eventually master the bigger thing to become agile in terms of the Agile methodology and process.