Trifork Blog

Category ‘Agile’

GOTO Nights Amsterdam, Join & Learn!

March 8th, 2016 by

As an introduction to the GOTO Conference in June, we organize a monthly meetup to introduce you to the topics of the conference. These meetups are called GOTO Nights and are totally free to attend and food and drinks are included.

At the start of the GOTO season we gather together to decide which topics are interesting for developers to learn more about. For these topics we try to find the best speakers for the conference and for the GOTO Nights.

Read the rest of this entry »

Recognizing commercials using the Alphonso API

September 21st, 2015 by

Liberty Global organized the Hack & Play Appathon in Ziggo dome on September 15th and 16th. More than 20 teams of hackers, designers and programmers were invited to create an app or a game for the Liberty Global product Horizon set-top box. Team Trifork joined with Dennis de Goede (Design & Frontend), Tony Abidi (Devops) and myself (Front & Backend).

Alphonso added another challenge to the appathon: Create the best integration with the Alphonso platform. Integration challenge? Sounds like a Trifork challenge to me.



Read the rest of this entry »

Large organizations are just not set up to be agile

September 21st, 2015 by

There is something going wrong in the organization I am currently part of an onsite project, yet I can’t get my head around the specifics.

This very large governmental organization is growing agile initiatives all over the IT department. Development teams are having fun talking to their customers and are trying to create the best solutions to the needs of their stakeholders, yet everything agile about Agile halts when a shippable increment is ready to begin its journey through the rest of the organization.

A few weeks back I received an email from the team that is tasked with the becoming agile of our organization, asking me to fill out a form so I could show how SCRUM we were. I know it was meant to let us see for ourselves how agile we were, but to me it felt as if we were proving our agility through a checklist.

I know I checked every box there was, so according to the person sending it we were 100% Scrum. I just knew we weren’t agile, so there must be a flaw in checking of the Scrum checklist to see if you are agile.

Read the rest of this entry »

My Goto Amsterdam 2014

July 17th, 2014 by

Trifork Logo

People who have worked with me know I’m a bit of a technical conservative. I’m very wary of quickly adopting the latest fads and trends because I’ve seen the collective hype and the following disillusionment too many times, including software being built with the then-latest-hype framework or platform and a year later being stuck with now-obsolete technology that only the original developers and a handful of other people still have any real experience with.

For the same reason I’ve avoided software tech conferences in the past years. A few visits to conferences several years ago on each occasion left me with feeling that I’d heard a lot about a lot, but that it wasn’t really going to improve my daily software development work.

Luckily, Goto Amsterdam 2014 was different.

Many, if not all, of the talks were relevant to my actual, day to day, software development job. I learned about looking at Agile in a different way. I heard people speak on real life problems being solved with actual, current, widely adopted technology. I even listened to talks that weren’t really that much about software development at all.

So let me walk you through my Goto Friday.

Read the rest of this entry »

Scrum: Just follow the solutions provided below!

May 8th, 2014 by

Doing Scrum is easy! Just follow and implement checklist below and everything will go well, right?

  • Deliver in cycles of two to six weeks
  • Work in a team sized six plus or minus three
  • Every day stand together answering what was done since the last standup and what will be done before the next
  • The standup should take no more than 15 minutes
  • Every sprint you have to review your process in a retro
  • The length of your retro should not exceed the length of the sprint in hours divided by 40
  • Stories in sprint should not take more effort than a team can do in two days
  • The stories should be broken up in tasks that can be completed in two hours max

Read the rest of this entry »

Lessons learned how to do Scrum in a fixed price project

August 22nd, 2013 by

As a Scrum Master my opinion on doing Scrum in combination with a fixed price, fixed functionality and fixed deadline is somewhat tricky to grasp. However, it still common that in many projects fixed price is just simply the norm. For instance, this is often the case in public tenders for government or education institutions for various projects such as the procurement of a new software system to name an example.

So if you and your company win the tender it’s up to you and your team to deal with the “fixed everything” aspect of the project. Interested in how to deal with some of the ongoing aspects of changes in the requirements, deadlines and how to keep both the customer and the team happy? Read on, in this blog I will share with you our experiences with fixed price projects and Scrum.
Read the rest of this entry »

QCon London 2013 – Agile in Actuality, Open Data, Latin as a Programming Language

March 13th, 2013 by

After an exciting few days at the QCon conference in London last week, I am slowly recovering from all the new input I got, and decided to do this by writing a little summary of “all things agile” from the Thursday as well as the highlights the other two days too.

Cherry Picking Wednesday

On the first day of the conference I didn’t follow a complete track, but rather cherry-picked talks the ones that sounded interesting. The day started with the keynote from Barbara Liskov about the basic software engineering research which influenced current languages and design. Stefan Tilkov talked afterwards about how to do web development right. He challenged many commonly-held assumptions about how to best develop web applications. Furthermore he gave his insights on how to really use the web core languages like HTML, CSS and JavaScript and the Web’s core standards, HTTP and URI. After that I heard Alvin Richards from 10gen talking about MongoDB schema design. Our colleague from Trifork, Janne Jul Jensen, gave interesting insights about the development of the Danske Bank mobile banking application: how do you do user experience testing if your project is top secret and you can’t give it to real users? Mark Nottingham finally informed us about the current status of the Google SPDY-based HTTP/2.0 specification, which gave interesting insights of the shortcomings of the HTTP/1.0 implementation and how HTTP/2.0 addresses them without becoming incompatible.

Damian Conway, the inventor of Perl gave, after a little beer break (that’s England, I guess) an unusual closing keynote: Fun With Dead Languages. He presented a little toy problem, which he solved with three different languages. First, he used PostScript, then he rather misused C++ and finally he showed us his own implementation of the Latin programming language. Latin? Right, Latin, the old roman language! There was, however, a serious background. Most of us develop software only with Java and/or C# and some SQL and JavaScript. His key message was that with a much broader knowledge of various kinds of programming languages we’re programming better and easier-to-read/-extend software (which probably excludes Perl) even if we only use Java/C# in production.

After the keynote, we warmed up with a couple of beers, before we left the conference center to join the conference party at the truly cool Central Hall Westminster.

Agile Thursday

On Thursday I only visited the presentations in the agile track. Most speakers reported that one thing makes it really difficult to be agile these days: project teams do perfectly implement “Scrum by the book”. Sounds good, but… Having a look at the agile manifesto we see that agile teams should value individuals and interactions over processes and tools. Doing Scrum (or any other agile method) by the book unfortunately leads to situations, where teams value the written down process in the book over interactions with the team mates (“you have to do it like this, because otherwise it’s not Scrum, I read it in the book/heard it in some talk”). Ward Cunningham said during a chat: “Kent Beck and me wrote the extreme programming book, but we’re not doing it like described in the book. It’s just a point to get started. You have to understand what makes you tomorrow better than today. That should influence and drive your process”.

The first talk from the agile track was from Glen Ford, explicitly talking about People over Process. He shared his experience from being a tech lead at a start-up. He recognized that his team’s doing Scrum as a ritual act, without asking why they’re doing certain things. They discovered that a process isn’t a rule of law, but rather a set of concepts. Instead of following rules, they formed a team vision and a why for everything they do. If you don’t find a why, don’t do it.  In their specific context, they couldn’t find a why for estimations, so they skipped it. Finding a why also encourages communication and the more communication they had, the less process they needed. The best and most open communication is among team members, which know each others strengths, weaknesses and quirks. So they decided to do not break teams apart, but rather to form long-running teams, which eventually got hyper-productive.

Hyper-performing without the hype by Dan North was seen as the highlight of the day. Indeed, it was the expected hour of entertainment paired with agile expertise. Dan explained the things he saw in the past, which made teams performing extremely well. I won’t mention all, but only those I learned as well in the past: developers should also be absolute domain experts., e.g. you can only be a great team developing trading software, if every developer of the team knows the trading business well. Developers have to participate in trading classes and you should seed your team with domain experts the developers can practice with. In times of Lean Software Development everyone is seeking for value, but we should nevertheless prioritize risk higher than value. Even if a solution promises high value, the question remains how much uncertainty we have to face for that solution. He then moved on to a classic: planning is everything, plans are nothing. Plan as far as you need and adjust along the way. He also strongly recommended to try out technical things regularly, even if you’ll never use them in production: languages, programming concepts, etc (I personally get stomach ache when writing for-loops in Java filtering or mapping list content since I learned functional programming…). Finally he recommends to release often, if possible daily, even if you think the software is not ready. It sounds weird to show the customer something which isn’t ready yet, but if you give the customer the chance to use the software, you’ll get feedback from real use, which is extremely helpful (think about opportunity costs).

Besides the presentations, we also had the opportunity to chat two hours with Ward Cunningham about Technical Debt (beyond the current hype and all the misunderstandings around that) and Agile Software Development (also beyond the hype around Scrum and all the misunderstandings around that). All agilistas completed the day with a fire-site chat with Dan North and Ward Cunningham organized by the Agile London user group.

Big Data and Architectures of the small & beautiful on Friday

The opening keynote from Damian Conway was one of the highlights of this conference. He talked about how to do interesting and fun technical presentations. He gave a great example, because the 45 minutes with him were super-entertaining and we all got very valuable take-a-ways for preparing presentations.

Cool talks about MongoDB, Hadoop and Riak followed the keynote. Since Hadoop and Big Data are a big hype, the speaker Jamie Engesser from HortonWorks pointed out, that we should really, really do Big Data for a reason and not because it’s cool 😉  Matt Asay from 10gen gave a nice talk about the past, present and future of NoSQL. He pointed out, that there is a set of exclusive use cases for document-oriented, column-oriented, key/value-oriented and relational datastores. But: there are many overlaps, where either one of them could be a good solution. He questioned polyglot persistence, because he’s not sure if an organisation can really deal with several different databases in operation. Andy Gross from Basho gave an honest talk about the problems Riak faced the last 5 years and how they solved them.

For me, the absolute highlight of the day was the presentation about the Triposo travel guide architecture. The presenters, former Googlers and ThoughtWorkers are avid travelers and wanted to know, if they can do better then the common travel guides like Lonely Planet & Co. So they started what they learned at Google: crawl the web, aggregate, match, and rank. They send their crawlers to fetch gigabytes of travel related content from all kinds of sources like Wikitravel, Wikipedia, Facebook, Open Street Maps, Flickr and some more.

Once they have all the data, it’s time to parse. From each source they extract information about the places like villages, cities and countries, and the points of interest (restaurants, museums, shops, trees, etc). They’re looking for patterns to create one bucket of information for a particular place from all the various sources they crawled. After this phase they end up with exactly one record for each place or point of interest that has all the information from any of the sources they’ve used. Now it is time to rank and these ideas were pretty cool. Among other things, they extract meta data from Flickr pictures like where and when the pictures were made. That brings them interesting information about possible events, e.g. there are many pictures around 52°38’N 4°45’E, but only from April to September and only Fridays between 10.00–12.30 a.m. There must be something interesting! That’s the cheese market in Alkmaar. So, if your on a trip in Amsterdam, your Triposo travel app proposes you a day trip to Alkmaar on Friday (with my Lonely Planet book I usually see that only when it is already too late). I don’t know if their app will revolutionize the way we travel, but it is an interesting idea how to use the huge amount of publicly available data (=Open Data).

Since not only the idea is nice how to use Open Data, but also the available languages and services they use (Python, Google Spreadsheets, Amazon S3, Amazon Mechanical Turk, automated deployment into the App Store with a browser remote control, etc) we invited them to give a presentation at one of our GOTO nights.

QCon London was absolutely worth it this year and hopefully I’ll be back for more inspiration next year. I was really impressed by the quality of the conference – tracks, speakers, keynotes, chocolate cakes and the selection of international beers. QCon London is one of the best technical conferences I’ve participated in and I recommend it for anyone interested in enterprise software development (It’s almost as good as GOTO Amsterdam ;-)).

Beyond classical contracting

February 19th, 2013 by

There is an interesting approach from the German IT service provider Adesso AG and the Ruhr Institute for Software Technology on how to balance project risks between service providers and their customers within a new contracting model, which is a combination of fixed price and Time & Material approaches. I want to give a brief overview of the work they published.

The problem with contracts within (agile) software development
Projects typically overrun time and budget constraints, missing requirements and quality expectations. These problems mostly arise from insufficient communication between business and technology experts or users and developers. Additionally, customers initially have a rather coarse grained idea of the system they need, but controversially they have to negotiate a fixed price contract or a budget ceiling to control the costs for project, because the purchasing department forces them to do that. This cost estimation can be done best by a service provider based on a complete specification of the system to be build. However, such a complete specification is neither economical (it requires considerable effort on both sides) nor is it helpful (nobody in the world can express all requirements in sufficiently complete and consistent detail up front).
In practice, service providers trying to make a best guess of the price and to balance the expected effort with the price the customer is willing to pay. Additionally, a service provider is sometimes forced to under-bid competing providers, since some customers have only one criterion: the price. This usually results in a too low amount, and the service providers will struggle for sure with the low bid. Many of them became therefore experts in the then following inevitable game of overly expensive change requests (and gone is all the cost control for the customer…). Neither constellation is helpful for a lasting customer relationship.

Fixed price or time & material aren’t the solution, too!
Agile software development replaces voluminous specifications by short iteration and (end-user-) feedback cycles, which makes it virtually impossible to set a fixed price upfront. The scope of the project generally emerges gradually during the project, so the actual effort is not foreseeable. In case of an agile software projects, a fixed-price contract exposes the service provider to the complete project risk. A pure time and material (T&M) contract is on the other side a high risk for the customer, since the service provider can now blow up development effort and neglect quality on the customer’s expense. Since fixed-price and T&M are not satisfactory for both parties, it is desirable to find a contracting model that has a built-in risk limitation mechanism for the service provider and a built-in cost limitation mechanism for the customer.

A fair pricing model?
The adVANTAGE model combines elements of fixed-price and T&M contracting models. It strives to provide some idea of the overall project scope (in terms of requirements, time and budget) as you know it from fixed-price projects. Also, the customer pays the complete effort to the service provider as you know it from T&M projects. The commercial principles behind this are risk distribution and efficiency incentives for both parties for the whole project duration. In the following sections we’ll see how these commercial aspects tie in with the sprints and deliverables of an agile process model.

Step 1: Collect and estimate. To get an initial overview of the project scope, we collect all the customers requirements before the first iteration, typically “must-haves” as well as nice-to-haves, business goals and business ideas with a coarse, non-technical description on the business level. The service provider then estimates the required effort for each requirement. Due to its coarse nature, these estimations have some level of uncertainty. This uncertainty is not expected higher than the uncertainty of a “normal” estimation of a fixed-price bid. Nothing really new here, but in contrast to traditional contracting models, the total of all estimations is not used to calculate a fixed price, but rather serves as a plausible point of orientation for the upcoming steps.

Step 2: Prioritize, plan and implement. Based on the estimate and the customers internal budget ceiling, the customer can now prioritize, eliminate or add requirements. In doing so, he transparently balances the importance of each requirement with his available budget and the time frame. Based on the prioritization, the customer and the service provider can now agree on the contents of the first sprint. At the beginning of a sprint, its requirements are refined together by the service provider and the customer into more detailed specifications. For the subsequent step of inspection and billing it is necessary, that all requirements are thoroughly integrated and tested (= production ready software, automated deployment).

Step 3: Inspect and pay. Now it’s getting interesting! The adVANTAGE model ties the billing very closely to the sprint. Depending on whether all user stories were satisfactory implemented or completed, we’ll have different billing scenarios:

  • Underspend sprints are really good for the customer, because only the actual effort will be billed. There’s no additional gain for the service provider of being cheaper then expected.
  • In overspend sprints the customer will be billed with the extra effort by a considerably reduced rate that penalizes the service provider. This is fair for both sides, because the customer is only billed for the actual effort and the service provider still gets paid for his extra effort.
  • Incomplete/unaccepted requirements can be moved to the next sprint, where the required extra effort will be penalized like described above.

Step 4: Plan the next sprint or terminate. After each sprint, the customer has the option to start the next sprint, where he can re-prioritize all requirements as well as add or remove new requirements to keep the focus on the overall project goal and constraints. Change requests are treated as new requirements. The customer can also terminate the project, when he feels it has reached the required functionality and/or its budget limits. Since every sprint results in a running system, this exit strategy is risk-free for the customer.

Although Trifork is not currently using the adVANTAGE model, it does contain a lot of benefits for both the customer and service provider;

  • The model provides what an agile project needs: a fixed scope during sprints and the ability to change the scope of the next sprints. With a fixed price approach this cannot happen without the more/less work discussion;
  • No additional fixed price margin is added to the price, which potentially ends up with the customer paying too much;
  • The IT service provider is given a fair incentive to deliver the promised result in a timely manner;
  • Running out of budget in a fixed price project will always imply cutback on other means, mostly quality. Since the estimations are done on detailed requirements, the risk of cutting corners on quality is much less.

From a customer perspective, it makes sense to give it a try, when you ended up several times in the cheapest-wins-but-they-have-bled-you-dry-with-change-request loop and ask service providers to go for the adVANTAGE model. This kind of project cost control seems to be better than the traditional one. What do you think?