Agile Greece is a community for agile practitioners with a mission to promote the application of agile practices (Scrum, Lean/Kanban, XP, BDD, Agile Product Management) in Greece.

Should the scrum master have technical background?

Among other things, scrum is very “trendy” lately. Virtually any company that I know of has either adopted it or attempted to do so or at least considered it. The software industry needs change rapidly, evolving the scrum master in one of the most sought after roles. However, the inability of the offer to meet the demand and the absence of required technical skills to become a scrum master has made the role appealing to a number of people outside the industry, giving birth to an ongoing debate. Should the scrum master have a technical background? The scrum guide does not prescribe technical skills as a prerequisite for a scrum master. However, desired qualifications in vacancies range from concrete experience as a software developer to no technical requirements specified at all. Before we endeavor to address the topic, let’s take a step back and think a little bit of Agile. Why do all these people and companies favor Agile over waterfall? After all, waterfall was used for so many successful projects. This can be a surprisingly hard to answer question for a lot of people. In my opinion, the key benefit is the establishment of a short feedback loop. Daily stand-ups, open space offices and loads of sticky notes only serve to alter the process, being merely means to and end. The short feedback loop is an end in itself. Agile suggests that we leave behind the old days when the requirements were specified all upfront and the developers worked isolated for a few months only to deliver software needing change. A very short loop is established, allowing for... read more

Agile: The end of innocence

A study by 6point6 on April 2017, based on a survey o 300 CIOs (average company size: 1,300 people) shows that the perception of Agile is changing. CIOs are often disillusioned, finding (usually the hard way) that some (12%) agile projects fail completely, that Agile is not easy to scale, and that distributed agile teams are often underperforming. This is good news. Agile never was, and never will be a silver bullet. Struggles with Agile adoption and a decent share of failures, show us that Agile will work only when carefully customized for the specific organization. This should shift our focus from advocating Agile to making it work – without expecting/demanding that the organization changes its culture overnight to become ‘Agile’. Established Agile scaling Frameworks such as SAFe can help with that. The age of agile innocence is ending. Finally. The report For the massive effect it has had on the software industry, there are surprisingly few industry reports analyzing the extend of Agile adoption*, compared to Waterfall, the older standard. Moreover, we have little data on the perceived success of the adoption efforts. Is Agile considered successful by the companies adopting it, after all? Most reference reports (such as the ‘State of Agile’ or the ‘State of Scrum’) base their data on surveys conducted on people already interested in or practicing Agile, a fact which obviously limits the sample and creates a strong positive bias towards Agile. This report published recently by 6point6 (a UK consultancy), tried to measure the perception of Agile success and the most common adoption roadblocks, by conducting a study on 300 CIOs, half in the... read more

Interview with Jonathan Smart

Q. Could you briefly introduce yourself? I am leading on better Ways of Working across Barclays, a bank which is 327 years old, with 120,000 employees in 40 countries operating in a highly regulated industry. This includes the application of agile, lean, DevOps, flow, Lean UX, customer at centre, servant leadership, and so on, at scale, in order to deliver ‘Better Value Faster, Safer, Happier’.   Our focus is whole enterprise agility, end to end, not just agile in IT. This includes HR, internal audit, real estate, legal, etc.   We have and are implementing agility at scale across a diverse and complex organisation. One size does not fit all. I am a practitioner, having been applying agile principles and practices since the early 1990s, before it was called agile, spending the first part of my career as a developer on the trading floor in investment banking. This was a naturally agile environment, co-located with the customers, with ‘flow’: small iterations of work, fast feedback, small teams, all knowing the value stream in depth. Results were seen quickly. Later in my career, running business line IT departments, I’ve led many agile transformations in order to deliver better business outcomes. It’s awesome to now be servant leader on agility across a large, complex, old, diverse organisation. Lots of learning, which I will share. Q: What will your talk be about, exactly? Why this topic? I will start with sharing my top learnings from the organisational transformation to deliver Better Products Faster Safer Happier. Things that I wish I’d known about 3 years ago when we started. I will also share... read more

Interview with Klaus Leopold

Q. Could you briefly introduce yourself? I am computer scientist and Kanban pioneer with many years of experience in helping organizations from different industries on their improvement journey with Lean and Kanban. My main interest is establishing business agility in a very lean and inexpensive way by improving organizations beyond the team level, especially in large environments from 50 to 5000 people. Q: What will your talk be about, exactly? Why this topic? My talk is basically a case study about an Agile transition of about 600 people. They introduced Agile methods across the organization but no significant improvement could be seen, although almost all teams were using Agile methods. I will give answers why this is, what we did to improve the performance and what I would do if I would have to choice to start at the beginning. The whole topic is about local sub optimizing an organization by using a team focused approach. That’s what I see in so many Agile transitions where loads of money is burnt without any significant improvements. I love this topic because using a different approach would be so simple! Q: What do you think could be the main gain for participants in your session? Learn pitfalls of Agile transitions so that you can avoid it in your situation. Learn what you can do when you are in an Agile transition which is on the wrong track. Learn how to get business agility in a very lean way with very low budget compared to classical Agile transitions. Q: Can you give some advice to teams/organisations that are transitioning to agile? Optimize... read more

Interview with Jeff Gothelf

Q. Could you briefly introduce yourself? I am a coach and consultant working in the lean and agile space. I’ve written 2 books – Lean UX and Sense & Respond. I spend most of my times working companies helping them build better product development teams and organizations. Q: What will your talk be about, exactly? Why this topic? Scaling Lean in large enterprises. This topic is a key sticking point for most large organizations. They can get small teams to work together and experiment and learn but how do you scale that up to 50 or 500 teams? This talk will address this. Q: What do you think could be the main gain for participants in your session? Understanding that there are key principles, not necessarily processes, that are required for strong agile and lean growth in organizations. Q: Can you give some advice to teams/organisations that are transitioning to agile? Stick to the values, avoid blink adherence to the recipes. Q: How do you see the evolution of agile in the future? I hope it ends up simply as “the way we work” as opposed to a branded thing. Collaboration, customer-centricity and continuous learning is the only way to succeed in a digitally powered world. Q: You have given many interviews/presentations about agile. Is there a question you wish to have been asked but no one ever asked you? Hmmm….no one’s ever asked me that question.... read more

Interview with Jutta Eckstein

Q. Could you briefly introduce yourself? Hi, my name is Jutta Eckstein and I made my first experiences using Agile (to be exact XP) in 1997. Thus, my first experiences were as a programmer. In 1998 I got independent and started helping projects and teams in different roles – as a developer, architect, yet also as a consultant or coach. In 2001 I dared to scale Agile out of necessity and after some more experiences I published my first book on that topic in 2004. I always try to share the experiences I make in conferences like this one and e.g. in books. I’m currently co-writing a book on Company-wide Agility with Beyond Budgeting, Open Space, and Sociocracy. Q: What will your talk be about, exactly? Why this topic? I will talk about Increasing Productivity by Uncovering Costs of Delay. Very often it is the small things that are slowing us down and these are the things I want to point out. So my talk is full of concrete suggestions you can first consider if they would make a difference in your setting and if yes, try them out. A lot of people in our community have heard (or bought) Don Reinertsen’s book on The Principles of Product Development Flow. Yet, not many people have read (or finished reading) the book. The reason is it is not an easy read. In this talk I want to provide a way that is easy to understand and apply that topic. (And if you want to know: Johanna Rothman and I wrote a small book on that topic –Diving for Hidden Treasures: Uncovering... read more

When do we consciously slip from Scrum

Scrum is an agile framework with very strict boundaries and plenty of freedom and flexibility within these boundaries. Scrum does have solutions to most team dysfunctions. Slipping from scrum should be a conscious decision taken by mature agile teams only! Daily Scrum starting time (Daily Standup) Scrum strongly suggests to never change the time and place of the Standup in order to reduce complexity. One of Standup’s main benefits is synchronization between team members. If a team member can not make it to the Standup, for any reason, its value obviously is less than optimal. We consciously choose to change the time of the Standup to ensure full attendance. This is easier to do in small teams, since in larger teams the effect of changing everyone’s schedule may outweigh the benefit of full participation. Dangers when slipping: On a non mature agile team, delaying the Daily Standup occasionally, may be seen as if it’s not required to be on time. Also, delaying the standup may de-motivate and confuse people who are always on time. Events Maximum Duration All events in Scrum have a maximum duration, strictly set based on the Sprint duration. For 2 week Sprints, the suggested timeboxes are: 4 hours for Planning, 2 hours for Review, 1.5 hours for Retrospectives. We have multiple Scrum teams, that share many common stakeholders. We consciously reduced the timebox of Sprint Reviews in 1 hour, and have all 8 Sprint Reviews from the Scrum Teams of the Department happening in the mornings of 2 consecutive days every 2 weeks. This way it is easier for many stakeholders to attend all sprint reviews. We... read more

Adopting Agile Testing Practices

This case study can be considered the result of adopting the Scrum framework without applying the suggested Agile testing practices and the impact after actual embracing them. Below you can find issues that were found and the practices that helped to overcome those issues. The main changes where the formation of cross functional teams and the use of test automations. From what it seems, we made one of the most common mistakes as a new Agile team that previously worked with incremental methodologies and tried to use Scrum. After creating multiple projects of different scope, size and technologies, the problem was visible when we went to enterprise level with a platform of 14 different applications, with more than 300K lines of code and near to 10k unit tests. This platform was about to go live but it should be stabilized first. Trying to add functionality on the platform we got in to a spiral of massive bug fixing rounds that worked as an alert, informing us that something did not work as it was supposed to. By this spiral effect it was obvious that something went wrong with the processes that we followed. How we worked Working with Agile methodologies is about building small increments in small iterations, one to four weeks top. At that time, besides the XP engineering practices, the team had adapted partially the Scrum framework by using some of the events such as sprint planning, daily scrum and sprints, but the collaboration between the testing and the development seemed more like a mini waterfall. The developers build a complete functionality (user story) or even a whole sprint... read more

Η ημέρα που σταμάτησα να ζηλεύω τους συναδέλφους μας στο εξωτερικό

Πάντα με ενθουσίαζαν οι συνάξεις εραστών της πληροφορικής. Θυμάμαι μικρός στις εκθέσεις «Μηχανοργάνωση» να ψάχνω ανοιχτά τερματικά υπολογιστών για να πειραματιστώ με το λειτουργικό τους σύστημα. (Η εντολή HELP μπορεί να σε πάει αρκετά μακριά.) Ως φοιτητής στα συνέδρια USENIX Technical Conference είχα την τύχη να θαυμάσω τους (συχνά εκκεντρικούς στην εμφάνιση) μάγους προγραμματιστές των συστημάτων που απολαμβάνουμε σήμερα θεωρώντας τα ως δεδομένα. Μετά ως επαγγελματίας γνώρισα τη ζωντάνια και τη δίψα για γνώση που χαρακτηρίζει τα επαγγελματικά συνέδρια: ACCU, GOTO, OOP. Έχοντας ταξιδέψει πολλές ώρες για να βρεθώ εκεί, ζήλευα τους συναδέλφους που έρχονταν σ’ αυτά το πρωί κατευθείαν από το σπίτι τους. Στις 16 Σεπτεμβρίου, περπατώντας από το σταθμό του Θησείου προς το Σινέ Κεραμικός για να παρακολουθήσω το Agile Greece Summit, συνειδητοποίησα ότι αυτή τη φορά δεν είχα τίποτα να ζηλέψω: μια έξοχη εκδήλωση πραγματοποιούνταν στην πόλη μου. Το συνέδριο είχε όλα τα στοιχεία μιας επιτυχημένης επαγγελματικής διοργάνωσης: πολύ ενδιαφέρουσες ομιλίες, πλήθος συναδέλφων που το παρακολουθούσαν με όρεξη, πλούσιες ευκαιρίες για συζητήσεις στους διαδρόμους και την εκπληκτική αίσθηση ότι δεν είσαι σε ένα στημένο περιβάλλον για να διεκπεραιώσεις άλλη μια επαγγελματική υποχρέωση, αλλά σε ένα φιλόξενο σπίτι για να συζητήσεις με τους φίλους σου. Η μεγάλη συμμετοχή έδειξε το έμπρακτο ενδιαφέρον που υπάρχει από εταιρίες στην Ελλάδα για ευέλικτη ανάπτυξη λογισμικού. Η πλειοψηφία των ανθρώπων δήλωσαν ότι προέρχονταν από εταιρίες άνω των εκατό ατόμων. Αυτό είναι επίσης πολύ θετικό, διότι σημαίνει ότι υπάρχουν και στην Ελλάδα αξιόλογες ευκαιρίες για επαγγελματική εξέλιξη στο χώρο μας. (Όσο ενδιαφέρον και συναρπαστικό κι αν είναι το περιβάλλον των νεοφυών επιχειρήσεων, ένα οικοσύστημα εταιριών πληροφορικής χρειάζεται και μεγάλους παραγωγικούς παίκτες για... read more

Το Nexus Guide στα Ελληνικά (a.k.a. The Nexus Framework in Greek)

Με μεγάλη χαρά, ανακοινώνουμε άλλη μια μετάφραση από τα μέλη του Agile Greece. Μετά το Scrum Guide στα ελληνικά, μεταφράστηκε και το Nexus Framework. Νομίζουμε ότι είναι εξαιρετικά σημαντικό μιας και το Nexus είναι ένα μεθοδολογικό πλαίσιο για την ανάπτυξη και τη συντήρηση προϊόντων και λογισμικού σε μεγάλη κλίμακα. Αποτελείται από τους ρόλους, τις δραστηριότητες, τα αντικείμενα και τις τεχνικές που συνδυάζουν τη δουλειά περίπου τριών έως εννέα Ομάδων Scrum που εργάζονται πάνω σε ένα κοινό Product Backlog. Βασίζεται στο Scrum και αναπτύχθηκε από τον Ken Schwaber και το Στο επίσημο site του μπορείτε να μάθετε περισσότερα για το Nexus Guide. Ακολουθήστε τον παρακάτω σύνδεσμο για να κατεβάσετε το Nexus Guide στα Ελληνικά ή σε άλλες γλώσσες. Για άλλη μια φόρα είμαστε ιδιαίτερα περήφανοι για τα μέλη της ομάδας του Agile Greece. Διέθεσαν πολύ απο τον πολύτιμό τους χρόνο και κατάφεραν να προσφέρουν άλλο ένα σημαντικό κείμενο για το Scrum, στην κοινότητα του Agile στην Ελλάδα. Following the translation of the Scrum Guide in Greek, members of Agile Greece have translated The Nexus Guide. Nexus is a framework for developing and sustaining scaled product and software development initiatives. It is a framework consisting of roles, events, artifacts, and techniques that bind and weave together the work of approximately three to nine Scrum Teams working on a single Product Backlog to build an Integrated Increment that meets a goal. It uses Scrum as its building block, and has been developed by Ken Schwaber and Find out more about the Nexus Guide here.  Download the Greek Nexus Guide here. Once more we are really proud for the members of our team. They offer much of their valuable... read more

Scrum Guide (in Greek)

Agile Greece has translated the official "Scrum Guide" in Greek and this is the result. Hope you like it. Any comments or additions are welcome.
Download link:

Ο Οδηγός του Scrum

Upcoming Events

There are no upcoming events at this time.

Get Involved

If you want to share your experience and knowledge about Agile, this is a great place to do so!
Agile Greece is an open-space organization where every interesting thought can be shared with others.

Submit your post now

Our Sponsors

Agile Actors

Covering cost for location, sandwiches & beers


The Cube Athens
The Cube Athens They give us the place to meet

O'Reilly User Group Program

Review copies, discounts, donations, newsletter


the place that hosts meetups at Thessaloniki