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

angielsku

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="http://farm3.staticflickr.com/2215/2400098202_959e2ea6a2_m.jpg" 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="http://farm4.staticflickr.com/3306/3610880025_fe860e9f5e_m.jpg" 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="http://farm5.staticflickr.com/4112/5154087532_b746ee8458_n.jpg" 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="http://farm9.staticflickr.com/8163/7323643076_21c0394060_n.jpg" 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 - http://i.ytimg.com/vi/3MiBj6ETZq4/0.jpg
Strange Filament - http://www.flickr.com/photos/jdn/2400098202/
Washington State Cage Fighting Championships - http://www.flickr.com/photos/kellbailey/3610880025/
Rest in Peace - http://www.flickr.com/photos/mooglet/5154087532/
With a little help from your friend ... - http://www.flickr.com/photos/jinterwas/7323643076/

You May Also Like

Micro services on the JVM part 1 – Clojure

Micro services could be a buzzword of 2014 for me. Few months ago I was curious to try Dropwizard framework as a separate backend, but didn’t get the whole idea yet. But then I watched a mind-blowing “Micro-Services Architecture” talk by Fred George. Also, the 4.0 release notes of Spring covers microservices as an important rising trend as well. After 10 years of having SOA in mind, but still developing monoliths, it’s a really tempting idea to try to decouple systems into a set of independently developed and deployed RESTful services.

Micro services could be a buzzword of 2014 for me. Few months ago I was curious to try Dropwizard framework as a separate backend, but didn’t get the whole idea yet. But then I watched a mind-blowing “Micro-Services Architecture” talk by Fred George. Also, the 4.0 release notes of Spring covers microservices as an important rising trend as well. After 10 years of having SOA in mind, but still developing monoliths, it’s a really tempting idea to try to decouple systems into a set of independently developed and deployed RESTful services.

Multi module Gradle project with IDE support

This article is a short how-to about multi-module project setup with usage of the Gradle automation build tool.

Here's how Rich Seller, a StackOverflow user, describes Gradle:
Gradle promises to hit the sweet spot between Ant and Maven. It uses Ivy's approach for dependency resolution. It allows for convention over configuration but also includes Ant tasks as first class citizens. It also wisely allows you to use existing Maven/Ivy repositories.
So why would one use yet another JVM build tool such as Gradle? The answer is simple: to avoid frustration involved by Ant or Maven.

Short story

I was fooling around with some fresh proof of concept and needed a build tool. I'm pretty familiar with Maven so created project from an artifact, and opened the build file, pom.xml for further tuning.
I had been using Grails with its own build system (similar to Gradle, btw) already for some time up then, so after quite a time without Maven, I looked on the pom.xml and found it to be really repulsive.

Once again I felt clearly: XML is not for humans.

After quick googling I found Gradle. It was still in beta (0.8 version) back then, but it's configured with Groovy DSL and that's what a human likes :)

Where are we

In the time Ant can be met but among IT guerrillas, Maven is still on top and couple of others like for example Ivy conquer for the best position, Gradle smoothly went into its mature age. It's now available in 1.3 version, released at 20th of November 2012. I'm glad to recommend it to anyone looking for relief from XML configured tools, or for anyone just looking for simple, elastic and powerful build tool.

Lets build

I have already written about basic project structure so I skip this one, reminding only the basic project structure:
<project root>

├── build.gradle
└── src
├── main
│ ├── java
│ └── groovy

└── test
├── java
└── groovy
Have I just referred myself for the 1st time? Achievement unlocked! ;)

Gradle as most build tools is run from a command line with parameters. The main parameter for Gradle is a 'task name', for example we can run a command: gradle build.
There is no 'create project' task, so the directory structure has to be created by hand. This isn't a hassle though.
Java and groovy sub-folders aren't always mandatory. They depend on what compile plugin is used.

Parent project

Consider an example project 'the-app' of three modules, let say:
  1. database communication layer
  2. domain model and services layer
  3. web presentation layer
Our project directory tree will look like:
the-app

├── dao-layer
│ └── src

├── domain-model
│ └── src

├── web-frontend
│ └── src

├── build.gradle
└── settings.gradle
the-app itself has no src sub-folder as its purpose is only to contain sub-projects and build configuration. If needed it could've been provided with own src though.

To glue modules we need to fill settings.gradle file under the-app directory with a single line of content specifying module names:
include 'dao-layer', 'domain-model', 'web-frontend'
Now the gradle projects command can be executed to obtain such a result:
:projects

------------------------------------------------------------
Root project
------------------------------------------------------------

Root project 'the-app'
+--- Project ':dao-layer'
+--- Project ':domain-model'
\--- Project ':web-frontend'
...so we know that Gradle noticed the modules. However gradle build command won't run successful yet because build.gradle file is still empty.

Sub project

As in Maven we can create separate build config file per each module. Let say we starting from DAO layer.
Thus we create a new file the-app/dao-layer/build.gradle with a line of basic build info (notice the new build.gradle was created under sub-project directory):
apply plugin: 'java'
This single line of config for any of modules is enough to execute gradle build command under the-app directory with following result:
:dao-layer:compileJava
:dao-layer:processResources UP-TO-DATE
:dao-layer:classes
:dao-layer:jar
:dao-layer:assemble
:dao-layer:compileTestJava UP-TO-DATE
:dao-layer:processTestResources UP-TO-DATE
:dao-layer:testClasses UP-TO-DATE
:dao-layer:test
:dao-layer:check
:dao-layer:build

BUILD SUCCESSFUL

Total time: 3.256 secs
To use Groovy plugin slightly more configuration is needed:
apply plugin: 'groovy'

repositories {
mavenLocal()
mavenCentral()
}

dependencies {
groovy 'org.codehaus.groovy:groovy-all:2.0.5'
}
At lines 3 to 6 Maven repositories are set. At line 9 dependency with groovy library version is specified. Of course plugin as 'java', 'groovy' and many more can be mixed each other.

If we have settings.gradle file and a build.gradle file for each module, there is no need for parent the-app/build.gradle file at all. Sure that's true but we can go another, better way.

One file to rule them all

Instead of creating many build.gradle config files, one per each module, we can use only the parent's one and make it a bit more juicy. So let us move the the-app/dao-layer/build.gradle a level up to the-app/build-gradle and fill it with new statements to achieve full project configuration:
def langLevel = 1.7

allprojects {

apply plugin: 'idea'

group = 'com.tamashumi'
version = '0.1'
}

subprojects {

apply plugin: 'groovy'

sourceCompatibility = langLevel
targetCompatibility = langLevel

repositories {
mavenLocal()
mavenCentral()
}

dependencies {
groovy 'org.codehaus.groovy:groovy-all:2.0.5'
testCompile 'org.spockframework:spock-core:0.7-groovy-2.0'
}
}

project(':dao-layer') {

dependencies {
compile 'org.hibernate:hibernate-core:4.1.7.Final'
}
}

project(':domain-model') {

dependencies {
compile project(':dao-layer')
}
}

project(':web-frontend') {

apply plugin: 'war'

dependencies {
compile project(':domain-model')
compile 'org.springframework:spring-webmvc:3.1.2.RELEASE'
}
}

idea {
project {
jdkName = langLevel
languageLevel = langLevel
}
}
At the beginning simple variable langLevel is declared. It's worth knowing that we can use almost any Groovy code inside build.gradle file, statements like for example if conditions, for/while loops, closures, switch-case, etc... Quite an advantage over inflexible XML, isn't it?

Next the allProjects block. Any configuration placed in it will influence - what a surprise - all projects, so the parent itself and sub-projects (modules). Inside of the block we have the IDE (Intellij Idea) plugin applied which I wrote more about in previous article (look under "IDE Integration" heading). Enough to say that with this plugin applied here, command gradle idea will generate Idea's project files with modules structure and dependencies. This works really well and plugins for other IDEs are available too.
Remaining two lines at this block define group and version for the project, similar as this is done by Maven.

After that subProjects block appears. It's related to all modules but not the parent project. So here the Groovy language plugin is applied, as all modules are assumed to be written in Groovy.
Below source and target language level are set.
After that come references to standard Maven repositories.
At the end of the block dependencies to groovy version and test library - Spock framework.

Following blocks, project(':module-name'), are responsible for each module configuration. They may be omitted unless allProjects or subProjects configure what's necessary for a specific module. In the example per module configuration goes as follow:
  • Dao-layer module has dependency to an ORM library - Hibernate
  • Domain-model module relies on dao-layer as a dependency. Keyword project is used here again for a reference to other module.
  • Web-frontend applies 'war' plugin which build this module into java web archive. Besides it referes to domain-model module and also use Spring MVC framework dependency.

At the end in idea block is basic info for IDE plugin. Those are parameters corresponding to the Idea's project general settings visible on the following screen shot.


jdkName should match the IDE's SDK name otherwise it has to be set manually under IDE on each Idea's project files (re)generation with gradle idea command.

Is that it?

In the matter of simplicity - yes. That's enough to automate modular application build with custom configuration per module. Not a rocket science, huh? Think about Maven's XML. It would take more effort to setup the same and still achieve less expressible configuration quite far from user-friendly.

Check the online user guide for a lot of configuration possibilities or better download Gradle and see the sample projects.
As a tasty bait take a look for this short choice of available plugins:
  • java
  • groovy
  • scala
  • cpp
  • eclipse
  • netbeans
  • ida
  • maven
  • osgi
  • war
  • ear
  • sonar
  • project-report
  • signing
and more, 3rd party plugins...