Agile in Practice

Stefan 14. August 2015

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

• Uncategorized
• no comments

Stefan 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?!

Summary

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!

• Uncategorized
• no comments

Stefan 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..”

and

”

• 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!

• Uncategorized
• no comments

Stefan 5. November 2012

• Uncategorized
• 1 comment

Stefan 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)

Intent

* 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:

Unit:

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

• Uncategorized
• no comments

Stefan 11. July 2010

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 Developers – This 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.

• Uncategorized
• 1 comment

Stefan 28. February 2010

“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?

Conclusion

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

• Uncategorized
• 2 comments

Stefan 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 http://www.sxc.hu/profile/hisks

• Uncategorized
• no comments

Stefan 8. January 2010

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.

• Uncategorized
• no comments

Stefan 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:

• Uncategorized
• no comments