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.

Job Titles in an Agile Company

14. August 2015

Obscure meaning

Around 2 years ago¬† I moved to a new company (AOE) which has almost tripled in size within the last years. As we are an agile organisation we were asking ourselves whether we needed titles or not?! We came to the conclusion that we don’t like titles but for some of us it makes sense to have business cards and we didn’t want the cards only to hold the name but also tell the recipient what area the person is working at. So of course I was thinking what my area would be.

Well, it became a bit complicated because I am experienced in Agile Methodologies (which I am coaching) and my second sweet spot is development and architecture. Two completely different areas I thought and I didn’t intend to write both onto the business card like “Agile Methodology, Architecture and Development”. I thought that was a kind of too “extravagant” and “boasting” and also it is just too long and not catchy enough. After a few days one my colleagues (actually it was my CEO) proposed “Why don’t you just call it >Agile Architecture<“?


In the beginning I wasn’t too sure but in the meantime I really love it because it has many meanings if you think about it:

1) It is not a title but describes an area I am capable to work in
2) It tells that I am aware of agile stuff
3) It tells that I know something about architecture
4) It makes people curious about architecture management in an agile environment. Something that is often questioned by people in the traditional world because they think that agilists don’t really care about architecture too much.

But I really started loving the title when I noticed the fifth meaning:

5) It also describes something in a figurative way that I wasn’t too sure about at first: I not only work as an agile coach in the development area but I also help forming our new agile organisation. That’s also an agile architecture but in a social sense.

So, sometimes idea need to mature until you detect the real meaning behind it.

So here is Triple-A-Stefan: Me working at Agile Architectures at AOE ! ūüėČ


Note: The blog was also published here in german

The distant ScrumMaster

17. July 2015


I am back

First of all I need to apologize for not having written for so long. There’s always excuses for everything, so let’s just call it “prioritization”, which is something that we (agilists) do a lot. So I had to do myself. In the meantime though I have prepared some blog posts but I never got down to really publish it, which I will now do over the next few months. Let’s see how long I can keep up with it….

The first story I like to write about is about the “distant scrum master” and be warned as it is gonna be a very long blog post!

Most of us probably have an idea what a ScrumMaster should do. While this is nicely understood in a co-located team it is interesting what ideas people come up with when undertaking a Scrum approach in a distributed way. I have seen quite a few ideas how to set up teams but this one really astonished me. Before I really dive deeper into the topic, I like to mention that I really appreciate those people who are currently in the role of the ScrumMaster!

The setting I encountered

Imagine a development team that is not co-located with the Product Owner. Even though this is definitely not the intended way of doing scrum, this happens more often than we like it to be – you could question reality or rather find good solutions for it. So what happened and what is not seldom to find (though not ideal) is that Dev-teams are not co-located with their PO and therefore you would find something like that

  Location 1    -> 100 miles away ->            Location 2
     PO                                                                 Dev-Team

But what about the ScrumMaster? I don’t want to start the old question new whether the ScrumMaster is >part< of the Dev-Team or not but most of us are probably of the same opinion that the ScrumMaster works intensively with (and for) the team. So, what do you think of the following situation?

           Location 1                         -> 100 miles away ->                Location 2
     PO / ScrumMaster                                                                     Dev-Team

Honestly I was pretty surprised because I hadn’t seen this kind of distribution of roles before. How should this work? How is the ScrumMaster able to deal with the team? I had seen situations before where the PO was distant but the “distant ScrumMaster” was new to me. Well, before we question this more, we should understand how the dev-teams work (it is actually not only one SM/PM/DEV = Scrum Team but we have several of them).

Each Scrum-Team runs on a same length sprint. At the end or beginning of the sprint (depending on how you perceive this) and on one day we undertake the sprint review, the retrospective and the planning. It should be noted here that the location at which the ceremonies take place is not always at the same location but it switches back and forth between location 1 (home location of the PO) and 2 (home location of the dev team) on every other sprint. That means the Scrum-Team meets on each of the sprints at alternating locations – sometimes the PO/SM travel, sometimes the whole dev team. Also they run dailies on a virtual basis using latest video conferencing techniques to make sure “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” is met. I am only mentioning this to show that the ScrumMasters are very engaged and motivated and thus manage the dailies efficiently, they prepare the retrospectives very creatively and run organized sprint demos in a very good way. They are really doing great (I mean that!)

Anything wrong with that?

Well, you could argue that unless everything works fine, there is nothing wrong with that. And, to their “defense”, many things actually work pretty well. They are well trained and motivated ScrumMasters and do the best they can. And that’s the point: They do the best they >can<. When I entered the scenario (on the dev team location) we were currently scaling up. Only a few months ago we had added a second team and were approaching the third team. No wonder, the teams were under a lot of storming influences (and we as company grew alike which added further stress to the environment). So there was a lot of storming (which brings along conflicts) that had to be taken care of. Enter the ScrumMaster! However, there is almost no way that a “distant ScrumMaster” can be aware of the team vibrations. Sure he (or she) talks with the team (via Skype or Webex) on a daily basis and they meet bi-weekly in person but the real personal behaviours and subtle gestures a team member does cannot be perceived from distance.¬† It is even harder to solve those conflicts as people usually need a close relationship over weeks and months to build trust. So of course it is not their fault if they don’t notice conflicts nor is it easy for them to solve. They really tried but from my perspective even though they had some success they actually had no real chance to support efficiently.

The Scrum hardliner would probably say that the solution is easy: Just move the Product Owner, ScrumMaster and Dev Team to one location but of course in many situations this is just not that easy. We have a great team and great POs and SMs. Moving people lifes to one or the other location makes things worse and replacing one or the other with on-location people is not really what we want. So living by the Scrum book is not always an alternative.

Our solution?!

Like in any realistic scaling environment you have to think about pragmatic solutions knowing that everything we do is a compromise to the ideal situation. One option would have been to move the ScrumMaster to the dev team, where he actually belongs too but that’s as bad as moving the dev team because the Scrum Masters home location is in a different city and we care about work-life-balance a lot. Besides that those people take care about removing impediments at the clients side which is most efficient there and almost impossible from remote while being with the dev team. So moving is not an option.

Our proposal was actually to establish a local ScrumMaster. To no surprise this led to a lot of misunderstandings on the ScrumMaster side and hesitation because¬† they felt it would question their work (and especially the fear their line manager would question why they would not be able to do their work as there would be now a “second ScrumMaster” at the dev team side). Honestly even bringing up the idea led to quite some “uproar”. It didn’t really make it better when we kind of stepped backed a bit by proposing to “just” add an Agile Coach on the dev team side who trains and coaches the team on self-organization, conflict management and self-improvement. The doubts on the ScrumMaster side prevailed. Anyway it was decided to try out the latter and give it try (Thanks for the trust!).

So we did. We established a coach with the idea to support the dev teams to mature and help establishing their self-organization. After some time more and more the “distant ScrumMasters” (from now on I like to call him the main ScrumMaster as this term is more esteeming) noticed that their work they had done until now was still highly appreciated which built trust into the new idea. What was still missing was

1) some dedicated space/place where the 3 teams could communicate about topics that were spanning the teams but even more important
2) a ceremony where they could talk about topics and conflicts that were not only related to the client but to their own company.

Hence, the team decided to run an internal retrospective that spans the whole teams before they would go into the single team retrospective that was run by the main ScrumMaster. Honestly again this lead to some degree of mistrust by the latter as they felt something was hidden from them and they were not really a trusted person. It took many months until he noticed that this is not the case. In fact the teams became even more open on their side while they were able to talk about internal affairs upfront. Even better the dev teams entered the single team retrospective very well prepared. If you would think that the team retrospective would now become just a replay of the internal retrospective you may be surprised to hear that this is not the case at all. The teams run the team retrospective as team related as before but adding spanning topics to it which adds a comprehensive view on the project and the team. Scaling is not about making one team better but all of the teams together.

All the above helped the teams a lot to move through the storming phase when they had to scale so quickly but still I felt that it would be nice if we could improve the teams even more.

I asked the teams and they came up with the idea to actually only now establish the internal ScrumMaster.

But why and why now? Let’s answer the second question first: Only now because it took months to build up trust with the main ScrumMasters that they understood that the team very much appreciates their work. But why: One reason is that the main ScrumMasters have a lot to do on their side to work on impediments and of course to take care of tasks at their location. So the idea was to establish ScrumMaster who organize only topics that have to be done during the sprints (this excludes explicitly all ceremonies like dailies, sprint planning and retros which are still undertaken by the main ScrumMasters!). They would look after the dev team only on their and support the main ScrumMasters.

From my perspective this really matured the team. The Proxy-ScrumMaster (PSM, if we want to call them like that) really enjoyed to become more responsible in supporting the team and familiarize with Scrum (we train them extensively) while it takes some burden from the main ScrumMasters shoulders. It also facilitates the communication between the colocated teams because PSMs communicate with each other (and with the main ScrumMaster) on a regular basis what’s going on in the team. Besides that they would automatically take over the leadership role of the main ScrumMaster if he would be absent which automatically mitigates the problem of the ScrumMaster being indispensable (which relates to every Role that is only appointed to one person) which even more counts cross functionality of the team.

One might doubt about the overhead that this concept would generate. Personally I think it is negligible but leads to a lot of nice improvements at the side of the distant dev team because finally you could actually ask who is distant: the PO and SM or the dev team?!


I am aware that this concept will always be under discussion, some people even think it is not really necessary (sometimes) and maybe someday we do not need it anymore or responsibilities will change. Anyways, during the time of growth it matures and supports the teams and also gives some of the team a way to grow on their social competencies. Agile is about trying out new ideas and do experiments, which is why I wanted to share this experiment to you.

And again: The distant/main scrum masters have always done and still do a great job!

We only show Finished Stories in the Sprint Review, do we?

12. July 2015

Lately I heard the statement that a team would only show stories that had been finished during the sprint which kind of puzzled me. Why would some team come up with that idea? Well, I asked back and got: “That’s what Scrum says”! I honestly heard that statement many times before and you know the reason why? Because every ScrumMaster has at least heard that statement once if not multiple times without actually providing a real proof. If you then ask back where this would actually have been stated, us Scrum Masters get something like “in the internet” – arghhh. Now the ScrumMaster has to proof otherwise – that’s not fair, is it? ūüėČ Enough with that rant, let’s get back to the main point:

Should the team only present finished or “done” stories?

Let’s first look at the reasons why this would make sense:

  • The team is proud of what it has done so it likes to present the things that went nicely.
  • The stakeholders get a good view on what is potentially shippable.
  • The team doesn’t like to blamed not to have finished what they have committed (or forecasted) to.
  • The team doesn’t like to talk about unfinished stuff as there might be a lot of things that are still in the works and are subject to change.

Honestly, the third one in my opinion is the one the comes mostly near to the truth, which actually is pretty understandable. Many times teams have experienced in the past that they are questioned why something didn’t turn out as planned and people are looking for failures and then blame others for it. Not so in the agile mindset. Remember “fail fast”? And that we want to learn from the past?

Now let’s see what Scrum says and the root of what is officially is said in Scrum is the Scrum Guide (or maybe the Agile Manifesto). Here is a relevant excerpt of what is said about the sprint review:

“A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration..”


  • The Product Owner explains what Product Backlog items have been ‚ÄúDone‚ÄĚ and what has not been ‚ÄúDone‚ÄĚ;
  • The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
  • The Development Team demonstrates the work that it has ‚ÄúDone‚ÄĚ and answers questions about the Increment;

Why it actually makes sense to show everything

Actually the above Scrum-statements are pretty clear that we do not only show something that is completely done.

  • A sprint review is about inspection and transparency. It is about “what was done in the sprint” and not in the sense of having been finished but what has been worked on! How can we understand to adapt if we not look of what has gone wrong (besides of course what worked well! – let’s not forget that of course!)
  • More precisely it is stated that the PO explains what Product Backlog items have been ‚ÄúDone‚ÄĚ and what has not been ‚ÄúDone‚ÄĚ. This is more than clear – the PO talks as well about things that have NOT been done!
  • The Dev Team is also asked to tell what went well and what problems it ran into and how those have been solved. How can this been explained without talking about non-finished work which definitely is a part of the whole sprint “story”.

I personally feel that

  • it doesn’t feel good to only have a show of success stories. It is just unrealistic and everybody knows that. Ups and Downs are part of life, so it is in sprints. Telling many good and some bad experiences feels much more serious than presenting “a show” to the stakeholders.
  • the Dev Team should be proud of what it has achieved and therefore also show or tell about it (which kind of differs to the above statement that [only] the PO should explain… of course the team can also do that!);
  • the Dev Team should tell stories and anectodes what it experienced and learned within the sprint. Many times these learnings come from surprise, the unexpected, failures and misunderstandings they ran into. Many times this is much more exciting and interesting to hear for the stakeholders than all those great success stories;
  • the Scrum Team should be honest with their stakeholders as this finally will build trust and keeps them much more engaged over time.

So be brave

and tell it how it is: Tell about the good stories and don’t hide your learnings. Paint the full picture and you will be rewarded by stakeholders that will eventually trust you much more than you would ever think!




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.

Raising the bar

23. December 2009

is exactly what is mentioned at the Manifesto for Software¬† Craftsmenship. Well, you may say, I know about the Agile Manifesto but what in the world is the one about sotware craftsmenship?¬† To be honest I wasn’t aware until recently when I listened to a podcast on Software Engineering Radio with Bob Martin (see Episode 150). I like to repeat here because I think many of us aren’t aware of it:

Not only working software, but also well-crafted software
Not only responding to change,
but also steadily adding value
Not only individuals and interactions,
but also a community of professionals
Not only customer collaboration,
but also productive partnerships
So check it out and raise the bar of your expertise, quality and commitment.

next »