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.

“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

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

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.

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

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

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

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

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

How long?

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

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

Experience

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

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

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

Finally: the quality definitely went up again.

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

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

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

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

Specifying and estimating the requirements:

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

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

• The main point here is that estimation of story points is about SIZE. A story that has three points is three times bigger than a story of of one point. A story of five point is almost twice as much as a story of three points.
• All story points are estimated by the whole team. As such the points (and therefore the size) are related to the whole team. We estimate the size of the stories for the whole team, so it is not person-related.
• The teams velocity for a sprint is easily measured: Just take the number of story points that have been performed by the end of the sprint. The average number of the last three sprints make up the velocity.
• Based on that velocity the next amount of user stories are taken and put into the next sprint.

• To put it into a nutshell:
  • User story points are size (not effort) only.
  • Points refer to the whole team not an indivual
  • Points can be quickly estimated (we strive to estimative on average in two minutes)
  • Points are used for mid and long term planning

Why do we estimate tasks in hours?

• As stated further up tasks are technical details that have to be implemented during the sprint.
• As a best practice and to be more efficient we do not estimate each user story with the whole team. The team distributes the user stories to smaller teams or pairs who then split down the user stories into tasks. The people who take care of this work are most likely but not necessarily those who do the implementation. Thereby the accuracy of definining the tasks, the preciseness of the hour estimation and the commitment is pretty high. We experienced an accuracy of about 5% for the team for a sprint on avarage which is extremely good.

• To put it into a nutshell:
  • Tasks are tied to Sprints
  • Tasks are estimated on hours to get effort  not size
  • As a best practice we try to let those estimate that are most likely to implement the tasks (though is not a rule)
  • Hours are compared to the available capacity

Commitment

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

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

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

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

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

How do you read it?

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

Do we need processes?

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

Do we need tools?

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

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

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

People’s attitude

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

We all have different

• experiences
• social competencies
• motivation and engagement

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

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

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

The ideal team manages itself

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

Beware of one fact though:

Grassroots Democracy sometimes becomes

Grassroots Democrazy…

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

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

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

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

How could one actually start to become agile?

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

I think it is important to distinguish two areas:

• The agile methodology and process
• Agile techniques or practices

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

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

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

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

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