ABE 2013 – coverage

In the middle of October we (Karolina Bojdak, Agata Winkler, Sławek Bryk, Kamil Sowa, Paweł Pustelnik) took part in Agile By Example 2013 (ABE) conference in Warsaw. This well-organized event took place in a very climatic cinema auditorium (old Kino Praha), which, in my opinion, was really great idea. So here we go – our notes and conclusions.

DAY 1

Jeff Sutherland – keynote

The idea of Jeff’s presentation was to show how Scrum became real, what happened earlier, and  finally evolved into Scrum. First, he showed few examples from his past, when scrum has not only been used in IT projects (poor farms in Africa, churches in US). The first Scrum team delivered Agile product in 1993, so it was 20 years ago and things have changed dramatically during the last 20 years. Jeff presented the number of Scrum jobs opened in the past and now – just to show how much this has grown in those years. Recently, US Department of Defense also mandated agencies to use Agile [http://www.projectmanagement.com/blog/Agility-and-Project-Leadership/5742/]. It confirms that generally, Scrum and Agile are in demand right now. What is so special about them?

Jeff believes that people’s happiness is the main factor indicating  whether  you are succeeding in your business, and Scrum just helps people to achieve happiness at work. Using Scrum in a right way makes your organization much more efficient.

Jeff said that we can even look at Scrum in terms of most important values stated in the United States Declaration of Independence: Life, Liberty and Happiness.

He also recommended Ben Shahar’s book ’Happier’. What we should focus on is making things in a way that makes us happy tomorrow. People often try to apply prescriptive processes to something which is unpredicted and requires adaptive methods. Because of that things can go wrong and  this is where adaptive methods, like Scrum, prevail.

Jeff showed us the past, where Scrum and Agile were evolving: Xerox PARC, The New New Product Development Game by Takeuchi and Nonaka, Small Talk – it was a bit orthodox for me when he said that all agile came from this…

He also talked about Lean values, which were also significant in defining Scrum. Jeff mentioned Lean Enterprise Institute and books about lean in production:

• Managing Flow
• The knowledge creating company
• Lean thinking
• Toyota Kata
• The machine that changed the world
• Extreme Toyota

When we look at Toyota lean product development we can see that it is like Scrum for product creation. 9th hidden turning point in history – Plan, Do, Check, Action – all in Scrum. Scrum can help teams to systematically achieve hyper productivity as Scott Downey writes in his paper. There is a pattern language for hyper productivity and it can be used as a Scrum Starter Kit – a collection of patterns created by Jeff to help Scrum Teams be more successful. If this is something new for you, I strongly recommend to check this site.

Jeff also mentioned project switching problem and immediately gave us a quick solution to this – The Interrupt Pattern.

Scrumming the Scrum – kaizen in the backlog with acceptance tests. This is another pattern for getting into hyper productive level.

Another thing worth to mention is Definition of Readystrong as most of us only knows about Definition of Done.

At the end, Jeff gave us another example of Scrum in IT and non-IT projects. SAP, Microsoft or new successful companies such as Spotify, Salesforce or Valve – they all work in Agile. However, the most surprising example was from the Netherlands where we can find a school using Scrum as their teaching methodology: self-organizing class, teachers as product owners, discipline and motivation problems disappeared. It shows that Scrum and, I think Agile too, can be used in many other environments, not only IT projects.

For me the main message from this presentation is: if you don’t have fun doing Scrum, you are doing it wrong. The reason why you should do Scrum is that once it is done in the right way, people are happier and this is the key to the success of your business. As one of the slides showed – 55% of people are unhappy at their work. Are your people one of these 55%?

Paweł Brodziński – Building Teams: We Got It All Wrong

If you read Pawel’s blog then his presentation wasn’t very surprising for you. First of all, collective intelligence is not connected with individual intelligence (Anita Woolley research). What is more, teams trump the group of individuals, in terms of intelligence (ability to learn).
Another important fact given by Pawel is that software development is not equal to writing code. It is definitely more than this, and we should focus on following factors (indicators of collective intelligence):

• Social Perceptiveness
• Communication Quality
• Moderate Cognitive Style Diversity

Another interesting research shows that the more women the better collective intelligence. I think that, generally, it is connected with types of personality and the fact that more women are „better” in this field than most men.

In general, bigger teams have also better collective intelligence. What does bigger mean? Well it is an issue people always like to discuss about. I think that we can assume 5-9 people should be ok, however, I don’t say it is the only accepted truth. As Paweł was indicating, teams having up to 11 members have similar efficiency to smaller teams, but might have better collective intelligence.

To sum up Pawel’s presentation – technical skills are not the most important while building a new team. Software development is a team sport, and we should focus on collective intelligence indicators first. Last but not least – more women!

More information can be found in Pawel’s post.

Tomek Włodarek – Are we agile yet?

Tomek Włodarek is well known in Poland for his Agile adaptation success stories. He showed how we should implement Agile in organization, mostly focusing on the areas which are the most important during the process:

• Measure Productivity
• Measure Quality
• Value Domain
• Enterprise Domain (investment in agility)

For each of them Tomek gave us exemplary metrics, which we can use. What is also important, we should remember that our teams are obliged to know these metrics too. One might ask whether it is possible to prepare just one simple index showing the level of agility. The answer is No, not really as Tomek said. We just need to experiment with agile, measure the most important things for our organization and continuously improve as we are never agile (agile means continuous improvement).

Tomek mentioned Agility Path, a framework which can be managed to adopt Scrum.

He also recommended book „Software in 30 days„.

Jakub Szczepanik – Five-Spice Scrum in Allegro Group

Jakub Szczepanik from Allegro Group told us about his company experiences during Scrum adaptation in the whole Allegro Group (60 Scrum teams right now).

First of all, organization should know why it wants to become agile and if the reason is because other are, because it is popular, then the risk of failure in Agile adaption is very high.

Secondly, is to change the mind-set from doing a project to developing products.

Next key conclusion – learn from the masters – hire external consultants, let them be agile coaches, let them train your own agile leaders (pair coaching) and then they can teach the rest in the company. Interesting experience here is that they found better Scrum Masters in non-IT departments (Marketing, Customer Care etc.) and what is more, most of new Scrum Masters are women.

It is useful to apply walking skeleton approach to learn scrum masters’ process (one week sprint of learning – basic knowledge in one week).

Initial enthusiasm for agile might vanish and it is also important to be focused during the adaptation process (they organized Scrum Transition Team).

General conclusion is that we should avoid reinventing the wheel, reading the books (with no additional external consultants and their knowledge). We ought to hire real specialists who can help us with adaptation process.

Michał Prządka – Get agile and don’t die trying

Michał said that implementing Agile is not an easy task. First of all, we should know why we want to do it.

We should start small, maybe with an agile/scrum team first, then another one. Michal strongly advised us against starting with Kanban, which seems to be an easy choice, but when it comes to details it is harder to implement.

We definitely should get help, because training our own people is not enough and external coaching is necessary.

Agile is about experimentation, but we should also stay focused (respect your time), especially because agile framework is very fragile.

We should be aware that some people just won’t fit in it. That is why, instead of convincing opponents and wasting our time we should focus on people who are already excited and help them.

Going into agile also means new culture implementing to recruitment process.

Starting with new projects is better than changing existing ones.

The last advise – don’t use separate artifacts (only stand-ups, only planning etc.) – dive into the framework, implement it by the book, and respect your time (of course you need to experiment, however, don’t forget what and when you want to achieve with agile).

This presentation was quite complementary to the previous one (Jakub Szczepanik) and most of the conclusions were the same.

Joy Kelsey – Scrum Buts – and how to remove them

Joy Kelsey presented 10 examples of Scrum…Buts (we use Scrum but we don’t use this artifact because…). The areas where scrum…buts often occurs:

• Communication
• Planning
• Testing
• Sprinting
• Reporting
• Retrospectives
• Planning sessions
• No Product Owner
• Adding items during the sprint
• No Testing

Examples for the aforementioned list:

• Sprinting – team does waterfall, calling it sprinting (incremental work instead of iterative – analysis > design > coding etc.)
• Planning sessions – team splits the stories into the smallest possible tasks and the session takes hours
• Reporting – team reports the progress by hours, not stories (burning down the time, not really finished / done stories)

This presentation just quickly went through typical mistakes Scrum teams might make, however there was nothing new, rather obvious results of breaking rules too early (without understanding the consequences).

Sandro Mancuso – Software Craftsmanship

It was the first presentation, which focused on a technical part of product development. Sandro told us about software craftsmanship movement and reasons for creating it.

Sandro Mancuso is passionate about software development and we all could feel his passion during this presentation. I think that this was the most energetic 30 minutes (actually, a bit more) in these two days.

Sandro said that our understanding of Agile is focused on people and interactions, but it means that we forget about technical practices and treat them as something less important. As a result we not only have product backlog, but also technical backlog and whereas the first one is elegant, the second one is a trash for everything.

Sandro notices that developers have wrong notion of time and put pressure on themselves. We forget that it is developer’s responsibility to have the system prepared to be expanded with new features. Every time QA finds a bug – it is developers’ fault (if QAs were paid by bugs, they should starve to death), they haven’t done their job well „I haven’t done my job”. This is often a result of breaking common-sense rule saying to „do work to be happy today AND tomorrow„.

Sandro explained how he sees Agile manifesto statements:

• Not only working software, but also well-crafted software
• Not only respond to change, but also steadily adding value
• Not only individuals and interactions, but also a community of professionals
• Not only customer collaboration, but also productive partnerships

Sandro said that as a developer he is one of stakeholders, because it is his career, his reputation.
He added that you don’t have to use XP practices if only you get something with higher value – don’t discuss practices, discuss value.

Summarizing software craftsmanship attitude:

• Passion
• Owning our careers
• Practice
• Boy scout rule (make things better = fix the code)

Sandro gave us interesting comparison – if you go to the doctor, does he say that he just needs money for training or book, and once you give him money, he will be better professional and will help you? So how can you call yourself a professional behaving this way?

He also told us the story about his career. Beginning with his meeting with a great mentor who helped him evolve as a professional and he still remembers his words:

„How it is done is as important as having it done”;

It is not always possible, not all of us had that chance. However, if you already know a lot, if you see yourself as a professional, be a mentor for others. Especially that many of these young developers believe in their excellence (Youth and knowledge often leads to arrogance as Sandro said about himself in the past).

Lightning Talks

Piotr Burdyło – How to speak at an international conference

1) Find your courage (get out from your safety zone, get feedback from people you know)
2) Prepare your content (title & abstract – killer staff + story (everyone has a story)
3) Broadcast your content (Agile Lean Network – submit your staff to all conferences…)
4) Earn a little bit of credibility earlier (local community etc.)

Jurgen Appelo – Money

Jurgen’s presentation was a bit similar to this one. Generally, money itself is not the most important motivation factor, however motivation is very low without them. A good example of this is ALE or STOOS initiatives, which had great goals but nobody really wanted to make them real. Making money is like breathing the air – we first need to breathe and then we can do other things, and be proud of yourself by making money.

Kate Terlecka – about leadership

Kate told us a little bit about good characteristics typical for a servant leader: patience, calmness, self-confidence. This should give better results than simple giving orders or permissions.

Mariusz Czenko – Planning for uncertainty

This presentation started with explanation of what chaos and complexity are, and which one of them is deterministic, and which one is not (mostly on the basis of Ralph Stacey’s research). Just type Ralph Stacey diagram/matrix in Google or read about it at Jurgen Appelo’s site.

Then, Mariusz told us about estimation, planning poker, definition of ready- nothing new and there is no reason to go into details. However, there is one thing I want to mention – the general idea behind his presentation was that organizations unready for agile won’t change and they have to die so we should let them do it. It wouldn’t have sound so naive if only there were any strong arguments confirming this, but the only one Mariusz had, was that they don’t understand agile they estimate and this is a waste and guessing. I have found the right answer at Glen Alleman’s blog.

Antti Kirjavainen – Technical Excellence: Why does it not stick even now?

Antti had quite a difficult task – his presentation was the last one and the topic was mostly covered earlier by Sandro.
Antti presented three most important factors causing that the majority of organizations is still not making effective management decisions to ensure their technical excellence:

1) Processes & Policies – example: Antti told us about the team having high test coverage (80% or something). However, going into details, we could see that most of the test was nonsense (doing nothing, just passing).

2) Contract Clauses – example: Company signed a new contract with one vendor with warranty period. It didn’t help because the solution was so bad that even after warranty period a new vendor was hired to rewrite it totally.

3) Business Value Prioritization – example: Backlog contained many features, also architectural ones. However, they were treated less seriously.

Then Antti explained why organization makes the same mistakes. He told us about intrinsic motivation (just see Jurgen Appelo’s book „Management 3.0” for more details). The conclusion was that we should let organization grow in circles or guilds (see Spotify example).

More details can be found here.

DAY 2

Jurgen Appelo – Champ Frogs

Champ Frogs is about intrinsic motivators and it is already published at Jurgen’s blog:

Curiosity

Honour

Acceptance

Mastery

Power

Freedom

Relatedness

Order

Goal

Status

Jurgen discussed all these motivators, and if you are interested in details the best way to get them is to read his blog, where Jurgen explains them regularly, starting with this one.

Why is it important? Well, Jurgen explained why change is important and whether we need changes. Then we need business transformers – people willing to make these changes in their organizations. How are they going to achieve this? That’s where we need intrinsic motivators.

Generally speaking, fear is stronger than appreciation of opportunity and changes are hard. What is also interesting is the fact that people spend 40% of their time on persuasion (how we can influence others). The chance for being a successful transformer is higher for optimists. If you are rather pessimist than you can change it – Fake it until you make it – which means start believing in being optimist and eventually you will become one.

Another thing worth mentioned is that we shouldn’t focus on facts, but rather on feelings.

Paul Klipp – My first five years with Kanban

Paul Klipp told us about his mistakes in Kanban.

1) No WIP limit
With no WIP limit we might have a lot of work in progress and nothing done.
Then team added WIP limit and the result was better.

2) There were still many other problems and team introduced retrospectives. Each retro meeting presented areas shown below on the plot and the team was experimenting with new changes after retro.

3) Another problem was incorrect DEV / QA ratio – it caused typical bottleneck in the process. One of things team could do was simply solving bugs (wrong spacing, title misspell etc.) by all members of the team. Following idea was to prepare public computer with installed application and everyone from the company could click the application, check it (in their slack time, coffee time etc.). And it helped. Useful metric used here was bug per feature.

4) The last idea was about measuring cycle time.
If someone is new to kanban, then this presentation quickly showed and also explained where first problems might occur.

Malcolm Peacock – Are we there yet? Or what a release plan is for

One of the most frequently asked questions by product owners and passengers in your car is „are we there yet?” or „when will I get my release?”. Malcolm showed in his presentation the number of analogies between family car journey and product delivery, and it was really valuable comparison, also funny in many moments.

From the release point of view satellite navigation is like a release plan – it shows you how to get to the goal, what possible paths are, what obstacles can be found and as we move towards the goal we get information about the weather, road traffic etc. Of course we make decisions based on these information.

Product Owners in your journey are passengers, to make it a bit harder – your kids as they love to ask whether we are there yet.

If we look closer into plan, it contains set of objectives: starting point, velocity, route, arrival time, distance. Well, if we compare it to our product delivery we also have a starting point, we measure velocity, our route is the number of steps, arrival time can be translated into number of sprints, and distance is number of weeks.

When we are already travelling then the speed might fluctuate, which means, in our analogy that we might have sick days, holidays, trainings etc.

When we drive we listen to the radio, update our navigation application with newest data. It allows us to anticipate. The same should happen in the project – listen to your team, your stakeholders.

Another interesting analogy is being aware of speeding up. We all understand how bad effects this could have in car journey. Again analogy to the project – loss of quality, team burn out.

Last but not least – don’t blindly follow the plan. It is just a plan, you should expect changes and tailor your plan (Plan like a Sat Nav). If the plan looks wrong it probably is wrong. What is also important and mentioned by Malcolm – Release planning is not about predicting future it’s about providing estimates.

To sum up, it was very interesting comparison and it might help in conversation with the product owner, stakeholders, team or just people new to scrum.

Wiktor Żołnowski – Stickies on the wall will not help you if you are building crappy software

Wiktor started his presentation with analogy – there are many different types of metal music and there are many different types of „agile”, but they mean the same – it is all about collaboration with the client. Well, for me saying that scrum, kanban, lean, agile is all the same is a strong simplification.

Then he said that we don’t deliver projects, but products, and there is no more place for project managers in Agile. I suppose we understand the role of project managers differently, because there are projects realized in Agile and with project managers.

Next Wiktor mentioned the passion which should appear in all departments, not only IT. I do agree.

Then he stressed again that agile doesn’t work for big projects and the only solution for scaling agile is to divide products into smaller independent sub products like Spotify does (it is all about decomposition). Well that’s ok – I agree that we should decompose, but there is a point where all these sub products /subprojects connect and this is the key point – here is the role of project managers, business visionary, architects etc. Those big projects might be done in agile way with those roles at the top. DSDM is a good example of that.

In conclusion, Wiktor presented himself as a passionate in one of the first slides but there was no passion in his presentation at all. At least I didn’t feel it.

Michał Ostruszka – Code Review, do you speak it?

Michał told us about code review, so it was rather technical talk.

First of all, we should understand why we need to review the code.

Then, we ought to find our own review style.

We must be aware that it is not easy to make code review right and good tips for us: review code, not an author; praise good stuff, balance feedback and just play with it – experiment, change.

Tomasz Borowski – How I Became a Spaceship Commander

Tomasz is a man with passion – I can definitely say that after his presentation. He really loves gamification concepts. Tomasz told us about his experiment with implementing gamification into their development process.

The main idea was to promote best practices within the team with gamification. Tomasz noticed problems in two areas:

• Motivation (different expectations, lack of appreciation, boredom)
• Communication (big, untraceable tasks; tasks not updated)

As a leader, he wanted to fix these problems and help the team to work better. This is where his passion – gamification came to help. He started experiment – connected their software lifecycle tool – YouTrack with YouGame – his game engine. I don’t want to go into details but generally, users were supposed to accumulate points. Points were given for accomplishing mission objectives (splitting big tasks, updating tasks, completed tasks, helping others). Another thing worth mentioning here is that YouTrack probably has a very interesting and friendly API, which allowed Tomasz to feed his YouGame software with all necessary data.

And of course it didn’t work as expected immediately. In the beginning, Tomasz noticed that bad behaviours occurred:

• Pointification instead of gamification
• Evaluation (because of ranking)
• Competition instead of collaboration (everyone wanted to be the number one)
• Missing fun and no progression

Tomasz improved game with better rules and personalized ranking and it caused:

• Sharing same goal
• Personal player profile
• New rank visibility – player can see only himself and two closest player (one below and one above)

Summarizing, it was really interesting presentation, although I am not playing games passionately. If you are interested in this topic you might try Gamification Course at Coursera – Tomasz recommended this. myYouGame created by Tomasz is also available at github.

Marek Kirejczyk – Building agile office with passion

Marek Kirejczyk took us for a virtual trip through his office. They are small company working on start-up projects and all try to work in agile at every organizational level – so they have task boards not only for software projects but also for their internal departments (marketing, accounting etc.). The whole office is organized in agile way – information radiators everywhere and everyone knows what is going on in the company.

Tom Gilb – Agility is the Tool, not the Purpose

Tom Gilb is the oldest agilist I have ever seen:) He has been doing agile since 1960! Tom is a bit controversial and it was a great pleasure to hear such experienced man. It was the first speaking showing us that not everything is so cool in agile, that we might understand it wrong.

Tom believes that agile manifesto has its heart in the right place, but he is worried about 'mind’. As it was created by developers and the practices are far too 'programmer centric’, and far too little 'stakeholder value’ centric.

Tom said that traditional agile is not useful for business purposes, his Evo method connects IT and business, and allows to deliver real business value to stakeholders. Tom described Gilb Agile Principles 2010 agilerecord03_Gilb, which are necessary in value management process.

He explained that, as David Rico said, Agile is naturally lean and based on small batches. Agile directly supports principles of lean thinking and we can connect agile to flow.

To sum up, there was a lot of information, the presentation itself was a bit chaotic, however the main message is very interesting and worth further consideration.

Iwona Cymerman – Agile in the lab

Iwona Cymerman was a special guest of the event and I am positively surprised by her appearance. Iwona is a scientist working in laboratory team. One day she joined Agile Warsaw group meeting and this is how her adventure with agile started.

She started with pomodoro technique and she was very consistent with it and now the whole team uses pomodoro. Then, she introduced stand-ups and it also worked very well. Another interesting agile artifacts:

• Figure Driven Development – known as TDD in software…
• Pair Pipetting – known as Pair Programming

Implementing agile in such a specific environment is not easy, but as Iwona said – there are constraints (quality, time, budget) but there is also one variable – scope. This is the thing which allows scientists to work in an agile way. What is more, there is even Agile Manifest for Science.

Summary

Kamil Sowa

I had very high expectations when I was going to the Agile By Example 2013 conference. Jeff Sutherland and Jurgen Appelo were to give keynote speeches. I thought: „that is going to be something!” However, in hindsight, I can say that I’m a little disappointed, but nonetheless, the trip to Warsaw was definitely worth the effort. I’d like to briefly outline what I brought back with me from the conference, what I believe is of greatest value for me and what influenced me the most.

Being in Warsaw gave me a chance to hear about other’s experiences, learn a couple of new things and reassure myself, that technical expertise is just as important as „stickies on the walls”. Good processes, interactions, people, values and other rather soft areas of agile project management are valuable and are definitely a must for a project to create astonishing results. But is it enough? Certainly not. The very core ingredient for a high quality product driven by business value is a group of highly skilled, passionate professionals with a good grasp of software development technical practices (software craftsman if you will). Of course, this is the best case scenario and there isn’t much more we could get in a project than that 🙂 But just as we expect high performance from teams, regular inspection and adaptation to improve efficiency, to remove waste, we should always expect our cross-functional teams to strive for becoming best at those practices.

Sandro Mancuso with his passionate talk inspired me a lot to continue promoting not only functional quality of the product, but also its structural quality. This is why I write here about Software Craftsmanship. Sandro’s performances should be heard by every single developer. Those of us who are young and arrogant (which usually is natural), claiming to be professionals a little too soon, should stop for a moment and read Manifesto for Software Craftsmanship. What it promotes is proven by experience of hundreds of thousands of experienced Agilists and developers. It describes indispensable ingredients for a valuable product. Now read the Manifesto, please… And think what you need to change to become software craftsmen.

To wrap things up: The talk was true and a lot of the audience, including me, saw shocking resemblance between Sandro’s experience and our own. He described problems we struggle with, sometimes even on a daily basis (which is sad). But we are not lost, because we know what our goal should be, thanks to the Manifesto (and that is reassuring).’

Sławek Bryk

Jeff’s speech was great. Assuming that all that he said is true, Agile methods can be used to solve most of world’s problems – and not (or particularly not) only in the IT sector.

Sandro partially restored faith in developers. His talk should be seen by everyone, who has the courage to call themselves „seniors” and still think that the best way of writing code is to write it as complex as possible.

Talks about the idea of bringing the Agile to upper management level kind of scared me – as it looks like the process of making a company to run really pure-Agile projects is a very difficult task. It won’t be that easy to convince our Clients to agree on an Agile project, if they aren’t willing to cooperate (and often transform) to achieve this goal.

The biggest inspiration was really the fact I truly believe in that we (FP) would’ve been able to lead few very interesting speeches ourselves. We should definitely try to put our speakers on next editions of such conferences.

Karolina Bojdak

I started scrum mastering my team, 6 iterations (which makes 18 weeks) ago. When I first heard about ABE conference I thought that it might be something for me, to give me more knowledge and more ideas about how to work with my team. In the meantime it also appeared that my second team – Culture – is interested in agile and in knowing more about how it works and would like to hear couple of words about what it is exactly. So I had two major things I wanted to focus on during the conference. Was ABE 2013 helpful with gaining the knowledge I wanted to have? I think yes.

Lectures by Jeff Sutherland and Iwona Cymerman ensured me that discussing agile practices with non-it teams is the right direction to go.

When it comes to more technical point of view, I was counting on more ideas and thoughts connected to the process and examples of working with the team, rather than guidance on introducing agile to teams. I definitely didn’t expect that the lecture I would like most would be about technical excellence. But I need to admit that Sandro Mancuso and his Software Craftsmanship was the lecture I remember best – maybe because Sandro is a really good speaker and you can’t keep your eyes and ears off him during his speech.

I appreciate the fact that I had the opportunity to go on such conference. It was well organized and the majority of speeches was interesting and gave me some new ideas to think about. It had also this side effect that on our way to the lectures, or when we were sitting together in the evening we had an opportunity to talk to each other and compare processes in which our teams work. It turned out that we all have something interesting to say and that even in our small FP agile world we have lots of knowledge, which should be exchanged between the teams.

Paweł Pustelnik

Going to Warsaw at this conference I had a few expectations:

• Learn something new
• Be inspired by something new
• Be inspired by other people

Did I learn something new?

Honestly saying the way we can think about agile projects (presented by Tom Gilb) was very interesting especially because, for me, the subject seemed overlooked until now(with DSDM / APM framework exception).
Jeff Sutherland’s Scrum Starter Kit is very interesting idea and I didn’t have a chance to read about it earlier.

Was I inspired by something new?

Agile Engineering by Tom Gilb – it is hard to say whether I was inspired but I definitely want to know more about it and understand Tom’s point of view.

Building teams by Paweł Brodziński and presentations about implementing agile within the organizations (Jakub Szczepanik and Michał Prządka) were inspiring for me (where we can find best scrum masters in our organization, how to build teams, how to train our people etc.).

Was I inspired by someone?

Definitely, Sandro Mancuso is the one here. I am not inspired to go back to developer’s path:) But I am inspired to be a professional in my current position. We all have better and worse days and Sandro’s show is one of these which help us recharge batteries.

Final word

Summarizing, I think it was worth going to Warsaw. I came back with new ideas, which now I am going to share with other people.