Agile w biznesie 2012 – podsumowanieAgile in business 2012 – a review

On Dec, 6-7 I attended the second edition of a new agile conference that took place in Warsaw, Poland. This conference, in contrary to every other I have seen so far, is (in theory) not targeted at software developers. It is called “Agile in business”…

Dostępne po


On Dec, 6-7 I attended the second edition of a new agile conference that took place in Warsaw, Poland. This conference, in contrary to every other I have seen so far, is (in theory) not targeted at software developers. It is called “Agile in business” and aims at helping people working in various business departments to understand and benefit from the agile movement. This short post presents my review of the event.

Venue & organization

The conference took place in the Businessman Institute, a conference centre located on the outskirts of Warsaw. The place itself was ok. There is just one problem about it – it’s far… and I mean far. It took me almost an hour to get there. I think quite a few people had some issues with getting taxis to get out from there. And, as some folks stayed in hotels close to the venue and some others – closer to the city centre, it was quite hard to arrange any kind of an evening party. On the other hand, the second day of the conference started with some snowing which allowed me to have some drifting fun on the parking lot ;). Regarding the organization – I missed three things: a large screen with twitter stream around the venue, a conference party for networking and some kind of speakers dinner to get to know each other better. Besides that – all went smoothly.

The talks Frankly, I missed hell lot of talks during this event. Due to traffic and other morning stuff I didnt make it for opening talks on both days. Others I missed on purpose - there was quite a lot going on in the hall.</h1> <h2>Day one Day one started with</h2> <p><strong>John Styffe</strong> introducing the Stoos network, a pretty new initiative in the lean agile world that is aiming at agility at organizational level. This definitely is something I am interested in, but on the other hand I have no regrets about missing the talk as the general opinion was that John didn’t present anything revolutionary. <img class="alignleft" style="margin-right: 15px;margin-bottom: 15px;margin-top: 7px" title="Lightbulb" src="" alt="" width="283" height="211" />I arrived just as <strong>Jurgen Apello</strong> started his key note. Again - I didn’t hear anything revolutionary, but this time only because I have had an opportunity to see Jurgen before. He is a great speaker and I highly recommend googling his talks and spending one or two hours watching, for those who haven’t done it already. Jurgen mentioned quite a lot of interesting stuff, just to name a few: Beyond Budgeting, Design Thinking, Lean Startup (I really believe that people working for established enterprises that want to start a new product line should start with reading this book). An idea that the most powerful force preventing agile adoption is management resistance will be eye-opening for some (I hope). Later, Jurgen presented an idea of innovation that is particularly appealing to me - innovation is not inventing new things, it is (very often) inventing new ways of using old things. I extremely liked the idea of “management is too important to be left to managers”, again something very close to the way we try to run TouK. I could write about this talk on and on, but the conference continued and... The Oracle talks started... <strong>Tomasz Warchała</strong> started talking on some Ora product... Guys sitting next to me are witnesses - I really did my best not to comment and to actually listen. It must have been some kind of a black hole that sucked all my energy :). I left and I spent almost two hours (missing next session and almost missing lunch :D) around, having interesting discussions and talking to people... Thanks to Oracle guys, I was not alone... After lunch two separate tracks had started. I focused on track one with a primary topic of customer-vendor contracts - I was to be speaking at the end of the day here, so I wanted to know which ideas I will be referring to and which fallacies I will be refuting. The track started with <strong>Piotr Wąsikowski</strong> sharing his thoughts on agile contracts. Retrospecting on his talk I really struggled to find an idea I couldn’t agree with and I think that’s mainly because I struggled to understand what Piotr’s main message was. I think Piotr tried to convince us that when signing large contract it is necessary (for a customer) to introduce some kind of success fee that must be related to business goals of the project. And I think that if you can (as a customer) get this kind of contract - good for you. But as a software vendor I think that, first - it will not allow for or prevent project agility (success fee has nothing to do with agility) and second - this really reminded me of the first bidding for the second line of tube in Warsaw - at first the business goal defined was to make it operational before the start of Eurocup (June 2012). None of the bidders considered it realistic so all of them added around 1 bln PLN extra in their offers for penalties (and 1 bln PLN equaled more or less 15-20% of the whole contract price). This bidding eventually got cancelled. <img class="alignright" style="margin-left: 15px;margin-bottom: 15px;margin-top: 7px" title="Quarrel" src="" alt="" width="150" height="121" />Anyway, quite a few people in the audience started a heated discussion with Piotr, so the organizers had to interrupt to let <strong>Radosław Nożykowski</strong> start his part of the show. Radosław is an attorney and he presented his take on contracts. And again, I find it hard to come up with a particular point that I disagree with. The thing I remembered was that Radosław was suggesting to use frame contracts instead of project contracts to allow a series of small subproject orders. This is a good advice, we use frame contracts all the time, but I really believe this is neither a solution for problems the audience was expecting to be addressed, nor in any way related to agile or waterfall projects at all. After that, guys from a competing (with TouK) company came on stage. <strong>Krzysztof Gradek</strong> and <strong>Mariusz Wieteska</strong> gave four or five case studies of Pentacomp’s software projects in different industries. They covered one or two ideas from my own talk, what saved me some time. I believe that their main message was “It is possible!” and I liked it. Their cases showed the key benefits of doing agile projects - short delivery cycles with focus on working software over documentation and customer collaboration over contract negotiation. There was one thing those three presentations had in common. Lots of text on slides. And I really believe this is a basic mistake many (or almost all) presenters do, even some experienced ones. My own first rule of presenting (stolen from Martin Fowler) - don’t do a slide with more than five words on it. Five. And if you really, really need bullets (in any form) then please please please - animate them so that they don’t appear all at once. Eventually, the time has come for me to stand on stage. Thanks to a friend from TouK my talk was recorded - after editing and syncing with slides it will be available somewhere online. And I will write a separate blogpost on the ideas I tried to cover in my talk as well as some more discussion with ideas presented by other speakers that I cannot agree with. The day finished with a smalltalk at the venue restaurant, an additional chance for networking used extensively. The only real issue about day one was lack of a/c during second part of the day... this, along with heated dispute made staying there until the end a little burdening.</p> <h2>Day two Day two started with some snow... When I got to the venue someone caught me in the hall, discussion quickly involved more people and I didn’t notice when time came to get to the restaurant for lunch.</h2> <p><img class="alignleft" style="margin-right: 15px;margin-bottom: 15px;margin-top: 7px" title="RIP" src="" alt="" width="100" height="151" />After that I went to see <strong>Andy Brandt</strong>. I had wanted to get introduced to Andy for some time and I was not disappointed. Andy is an experienced speaker and, in terms of the art of presenting, his presentation was well prepared. I agree with most of his points, but the one I cannot agree fully (even though I understand Andy’s point of view) was his main one. I agree that from a personal perspective of many people letting corporations die would benefit their personal life a lot. But in the same time I, as a software vendor, need these corporations as my customers and I want to help them the best I can (to become better organizations). Andy’s presentation reminded me of what our mutual friend Wiktor was saying during our journey to Agile Eastern Europe in Kiev few months back: “if you cannot change your company, change your company”. Good memories from this trip... Right after Andy <strong>Sebastian Christow</strong> from the Ministry of Economy talked about practices you could call agile used on a daily (or weekly) basis in an environment as far from agility as you could get. Nice talk showing that “you can” even if the organization doesn’t let you. <img class="alignright" style="margin-left: 15px;margin-bottom: 15px;margin-top: 7px" title="Friends" src="" alt="" width="320" height="213" />Almost at the end the Allegro team came in. <strong>Michał Rączka</strong> and <strong>Jakub Szczepanik</strong> talked about introducing Scrum in their organization, and those guys rocked. Really a good presentation, with visible amount of practice put into it. Michał, as a PMO manager, focused more on project management aspects of Scrum adoption and Jakub gave a few stories on the team level. Three points I did remember: first one was a story of a project sponsored by a member of the board who after not showing up for two sprint planning/reviews due to lack of time was faced by Michał with a choice of either closing a project (as clearly some other project was more important) or sticking to the rules. A brave decision of a PMO manager but it is courage that is one of the founding values of Scrum, isn it? And the board member finally truly commited. Another point was a general report of Allegro’s Scrum adoption based on valuing entrepreneurship. Any decision made by Product Owner should be rooted in entrepreneurship and they actually managed to get out of project scoring, artificial metrics, etc hell. Last but not least, I noticed that those guys are talking all the time about customer satisfaction, user satisfaction and market satisfaction. Those are the things that drive project decisions, be it starting a project, closing a project or defining goals. Not a moment they talked about shareholders, stock value, reports, etc. And, even though I strongly believe that shareholder satisfaction is important, I believe it is an effect, not a driver for running a company. Finally the conference was getting to its end. It finished with a panel discussion swiftly moderated by Bartosz Górczyński. He started by asking a profound (hence the name of the conference) question: “how about having a discussion on agility in business”. It was an interesting hour, even though some people started leaving trying to catch trains, planes, etc. The general summary was that the speakers represented widely understood e-business. How to use agile and lean in more traditional industries like energy, finance or insurance is not obvious. I have my own opinion on that, but I will leave it for another post.

In the meantime Besides presentations there have been quite a lot of talking around the venue. And honestly, that was the better part of this conference. As a general advice to anyone participating in a similar event, having participated in quite a few conferences this year, I really recommend using this time well to meet new people, listen, share ideas, listen, get linked in and listen. I slightly regret that the organizers didn’t think about any kind of a party in the evening, but even without that I have more new people in my address book that I would like to get back to than I will ever have time to get back to.

Recap Line up wise, it wasn’t the best conference I have attended this year, but it wasn’t the worst either. The talk of Allegro guys, Michał and Jakub, filled me up with a lot of positive energy, they easily won my personal best talk award, with Jurgen and Andy following close by. All three represented a strong, european level. In terms of networking it was probably my best event this year. Met loads of people, got loads of ideas. I have two blogposts to write, at least a dozen of followup calls to make. Finally, I think this is a kind of conference the community really needs. There’s lot of agile events around that mostly focus either on the level of a team or the technical issues of creating software. This one is an attempt to address a different group of people, in my personal opinion, a group of people that could have more impact on the industry than the development community so far. And this is something I am really looking forward to…

Photos used:
Audi S5 -
Strange Filament -
Washington State Cage Fighting Championships -
Rest in Peace -
With a little help from your friend ... -

You May Also Like

33rd Degree day 2 review

Second day of 33rd had no keynotes, and thus was even more intense. A good conference is a conference, where every hour you have a hard dilemma, because there are just too many interesting presentations to see. 33rd was definitely such a conference, and the seconds day really shined.

There were two workshops going on through the day, one about JEE6 and another about parallel programming in Java. I was considering both, but decided to go for presentations instead. Being on the Spring side of the force, I know just as much JEE as I need, and with fantastic GPars (which has Fork/Join, actors, STM , and much more), I won't need to go back to Java concurrency for a while.

GEB - Very Groovy browser automation

Luke Daley works for Gradleware, and apart from being cheerful Australian, he's a commiter to Grails, Spock and a guy behind Geb, a  browser automation lib using WebDriver, similar to Selenium a bit (though without IDE and other features).

I have to admit, there was a time where I really hated Selenium. It just felt so wrong to be writing tests that way, slow, unproductive and against the beauty of TDD. For years I've been treating frontend as a completely different animal. Uncle Bob once said at a Ruby conference: "I'll tell you what my solution to frontend tests is: I just don't". But then, you can only go so far with complex GUIs without tests, and once I've started working with Wicket and its test framework, my perspective changed. If Wicked has one thing done right, it's the frontend testing framework. Sure tests are slow, on par with integration tests, but it is way better than anything where the browser has to start up front, and I could finally do TDD with it.

Working with Grails lately, I was more than eager to learn a proper way to do these kind of tests with Groovy.

GEB looks great. You build your own API for every page you have, using CSS selectors, very similar to jQuery, and then write your tests using your own DSL. Sounds a bit complicated, but assuming you are not doing simple HTML pages, this is probably the way to go fast. I'd have to verify that on a project though, since with frontend, too many things look good on paper and than fall out in code.

The presentation was great, Luke managed to answer all the questions and get people interested. On a side note, WebDriver may become a W3C standard soon, which would really easy browser manipulation for us. Apart from thing I expected Geb to have, there are some nice surprises like working with remote browsers (e.g. IE on remote machine), dumping HTML at the end of the test and even making screenshots (assuming you are not working with headless browser).

Micro services - Java, the Unix Way

James Lewis works for ThoughtWorks and gave a presentation, for which alone it was worth to go to Krakow. No, seriously, that was a gem I really didn't see coming. Let me explain what it was about and then why it was such a mind-opener.
ThoughtWorks had a client, a big investment bank, lots of cash, lots of requirements. They spent five weeks getting the analysis done on the highest possible level, without getting into details yet (JEDI: just enough design initially). The numbers were clear: it was enormous, it will take them forever to finish, and what's worse, requirements were contradictory. The system had to have all three guarantees of the CAP theorem, a thing which is PROVED to be impossible.
So how do you deal with such a request? Being ThoughtWorks you probably never say "we can't", and having an investment bank for a client, you already smell the mountains of freshly printed money. This isn't something you don't want to try, it's just scary and challenging as much as it gets.
And then, looking at the requirements and drawing initial architecture, they've reflected, that there is a way to see the light in this darkness, and not to end up with one, monstrous application, which would be hard to finish and impossible to maintain. They have analyzed flows of data, and came up with an idea.
What if we create several applications, each so small, that you can literally "fit it in your head", each communicating with a simple web protocol (Atom), each doing one thing and one thing only, each with it's own simple embedded web server, each working on it's own port, and finding out other services through some location mechanism. What if we don't treat the web as an external environment for our application, but instead build the system as if it was inside the web, with the advantages of all the web solutions, like proxies, caches, just adding a small queue before each service, to be able to turn it off and on, without loosing anything. And we could even use a different technology, with different pair of CAP guarantees, for each of those services/applications.
Now let me tell you why it's so important for me.
If you read this blog, you may have noticed the subtitle "fighting chaos in the Dark Age of Technology". It's there, because for my whole IT life I've been pursuing one goal: to be able to build things, that would be easy to maintain. Programming is a pure pleasure, and as long as you stay near the "hello world" kind of complexity, you have nothing but fun. If we ever feel burned out, demotivated or puzzled, it's when our systems grow so much, that we can no longer understand what's going on. We lose control. And from that point, it's usually just a way downward, towards complete chaos and pain.
All the architecture, all the ideas, practices and patterns, are there for just this reason - to move the border of complexity further, to make the size of "possible to fit in your head" larger. To postpone going into chaos. To bring order and understanding into our systems.
And that really works. With TDD, DDD, CQRS I can build things which are larger in terms of features, and simpler in terms of complexity. After discovering and understanding the methods (XP, Scrum/Kanbad) my next mental shift came with Domain Driven Design. I've learned the building block, the ideas and the main concept of Bounded Contexts. And that you can and should use a different architecture/tools for each of them, simplifying the code with the usage patterns of that specific context in your ming.
That has changed a lot in my life. No longer I have to choose one database, one language and one architecture for the whole application. I can divide and conquer, choose what I want to sacrifice and what advantages I want here, in this specific place of my app, not worrying about other places where it won't fit.
But there is one problem in here: the limit of technologies I'm using, to keep the system simple, and not require omnipotence to be able to maintain, to fix bugs or implement Change Requests.
And here is the accidental solution, ThoughtWorks' micro services bring: if you system is build of the web, of small services that do one thing only, and communicate through simple protocol (like Atom), there is little code to understand, and in case of bugs or Change Requests, you can just tear down one of the services. and build it anew.
James called that "Small enough to throw them away. Rewrite over maintain". Now, isn't that a brilliant idea? Say you have a system like that, build over seven years ago, and you've got a big bag of new requests from your client. Instead of re-learning old technologies, or paying extra effort to try to bring them up-to-date (which is often simply impossible), you decide which services you are going to rewrite using the best tools of your times, and you do it, never having to dig into the original code, except for specification tests.
Too good to be true? Well, there are caveats. First, you need DevOps in your teams, to get the benefits of the web inside your system, and to build in the we as opposite to against it. Second, integration can be tricky. Third, there is not enough of experience with this architecture, to make it safe. Unless... unless you realize, that UNIX was build this way, with small tools and pipes.
That, perhaps. is the best recommendation possible.

Concurrency without Pain in Pure Java

Throughout the whole conference, Grzegorz Duda had a publicly accessible wall, with sticky notes and two sides: what's bad and what's good. One of the note on the "bad" side was saying: "Sławek Sobótka and Paweł Lipiński at the same time? WTF?". 
I had the same thought. I wanted to see both. I was luckier though, since I'm pretty sure I'll yet be able too see their presentations this year, as 33rd is the first conference in a long run of conferences planned for 2012. Not being able to decide which one to see, I've decided to go for Venkat Subramaniam and his talk about concurrency. Unless we are lucky at 4Developers, we probably won't see Venkat again this year.
Unfortunately for me, the talk ("show" seems like a more proper word), was very basic, and while very entertaining, not deep enough for me. Venkat used Closure STM to show how bad concurrency is in pure Java, and how easy it is with STM. What can I say, it's been repeated so often, it's kind of obvious by now.
Venkat didn't have enough time to show the Actor model in Java. That's sad, as the further his talk, the more interesting it was. Perhaps there should be a few 90min sessions next year?

Smarter Testing with Spock

After the lunch, I had a chance to go for Sławek Sobótka again, but this time I've decided to listen to one of the commiters of Spock, the best thing in testing world since Mockito. 
Not really convinced? Gradle is using Spock (not surprisingly), Spring is starting to use Spock. I've had some experience with Spock, and it was fabulous. We even had a Spock workshop at TouK, lately. I wanted to see what Luke Daley can teach me in an hour. 
That was a time well spent. Apart from things I knew already, Luke explained how to share state between tests (@Shared), how to verify exceptions (thrown()), keep old values of variables (old()), how to parametrize description with @Unroll and #parameterName, how to set up data from db or whatever with <<, and a bit more advanced trick with mocking mechanism. Stubbing with closures was especially interesting.

What's new in Groovy 2.0?

Guillaume Laforge is the project lead of Groovy and his presentation was the opposite to what we could see earlier about next versions of Java. Most visible changes were already done in 1.8, with all the AST transformations, and Guillaume spent some time re-introducing them, but then he moved to 2.0, and here apart from multicatch in "throw", the major thing is static compilation and type checking.
We are in the days, were the performance difference between Java and Groovy falls to a mere 20%.  That's really little compared to where it all started from (orders of magnitude). That's cool. Also, after reading some posts and successful stories about Groovy++ use, I'd really like to try static compilation with this language
Someone from the audience asked a good question. Why not use Groovy++ as the base for static compilation instead. It turned out that Groovy++ author was also there. The main reason Guillaume gave, were small differences in how they want to handle internal things. If static compilation works fine with 2.0, Groovy++ may soon die, I guess.

Scala for the Intrigued

For the last talk this day, I've chosen a bit of Scala, by Venkat Subramaniam. That was unfortunately a completely basic introduction, and after spending 15 minutes listening about differences between var and val, I've left to get prepared to the BOF session, which I had with Maciek Próchniak.

BOF: Beautiful failures

I'm not in the position to review my own talk, and conclude whether it's failure was beautiful or not, but there is one things I've learned from it.
Never, under none circumstances, never drink five coffees the day you give a talk. To keep my mind active without being overwhelmed by all the interesting knowledge, I drank those five coffees, and to my surprise, when the talk started, the adrenaline shot brought me over the level, where you loose your breath, your pulse, and you start to loose control over your own voice. Not a really nice experience. I've had the effects of caffeine intoxication for the next two days. Lesson learned, I'm staying away from black beans for some time.
If you want the slides, you can find them here.
And that was the end of the day. We went to the party, to the afterparty, we got drunk, we got the soft-reset of our caches, and there came another day of the conference.

You can find my review from the last day in here.