Tag Archives: scrum

scrum

Presentatie op LAC congres – De architect tussen 35 scrum teams in de 90e sprint…

Op woensdag 25 en donderdag 26 november is de 17e editie Landelijk Architectuur Congres. Net als vorig jaar ga ik in de track Agile Architecting een presentatie geven over architectuur en architecten in een Agile omgeving. De titel van de presentatie dit jaar is: De architect tussen 35 scrum teams in de 90e sprint…

De realisatie van software gebeurt steeds vaker agile. Dit vraagt ook iets van de architect en de architectuur. Software wordt steeds sneller en frequenter naar productie gebracht. Wat betekent dit voor de architect? De hoeveelheid data die verwerkt moet worden door de IT systemen blijft groeien. En nu? Bij bol.com zijn we op weg naar de 100e sprint met inmiddels zo’n 35 scrum teams. Aan de hand van voorbeelden laten we zien hoe we hier bij bol.com mee omgaan en hoe de architect en de architectuur steeds meer volwassen worden.

Bij bol.com hebben we inmiddels heel wat ervaring opgedaan met scrum, Agile architectuur en het schalen van scrum en Agile. In de presentatie zal ik ervaringen delen uit de realisatie van een nieuwe voorraadservice, Logistiek via bol.com, Vandaag Ophalen en de lopende realisatie van ons nieuwe fulfillment center.

Business Intelligence en Big Data bij bol.com

Naast mijn presentatie over Agile architectuur, verzorgt mijn collega Wieneke Keller een presentatie over Business Intelligence en Big Data bij bol.com in de track data science voor architecten:

bol.com groeit stevig door. In onze (micro) service architectuur proberen we deze groei te faciliteren. Belangrijk is dat we inzicht houden in de kwaliteit van onze processen. Bij bol.com doen we dit door big data technologieën in te zetten binnen het BI domein. Zo kunnen we de groeiende hoeveelheden data en databronnen eenvoudig toegankelijk en beheersbaar houden. In deze presentatie wordt toegelicht hoe we dit doen. Ook zullen andere toepassingen van big data bij bol.com worden besproken.

Presentaties februari 2015

Voor februari 2015 staan er diverse presentaties op de planning met name op het gebied van architectuur en agile:

Kennissesies agile architectuur bij Ordina

Op 5 februari organiseert Ordina een kennissessie over agile architectuur in de praktijk. Net als op het LAC zal ik een presentatie houden over de waarde van architectuur en time-to-market. Waarin ik laat zien dat juist architectuur waarde en snelheid kan bieden bij de time-to-market. Dit aan de hand van voorbeelden uit de praktijk bij bol.com .

Symposium Move IT – Logistieke optimalisaties mbv Big Data

Big Data machinesOp 11 februari organiseert studievereniging Inter-Actief Symposium Move IT. Een symposium waarop transport, logistiek en distributie centraal staan. Thema van de presentatie die ik samen met een collega van de afdeling logistiek geef is: Wat is de rol van IT en big data bij het optimaliseren van de performance in de logistieke keten?

Bol.com heeft ruim 5 miljoen klanten in Nederland en België. Met ruim 9 miljoen artikelen en 15 miljoen kliks per dag is bol.com het schoolvoorbeeld van een big data omgeving. Om alle klanten optimaal te kunnen bedienen, moeten onze IT-systemen optimaal werken. De IT-organisatie neemt daarom een cruciale rol in, met 31 scrumteams die worden ingezet op alle organisatieniveaus.

Door deze multidisciplinaire teams worden continue verbeteringen geanalyseerd, ontwikkeld en live gebracht. Dit allemaal in nauwe samenwerking met bijvoorbeeld de logistieke afdeling.

De afdeling Logistiek is verantwoordelijk voor het betrouwbaar en stabiel houden van de supply chain. Daarnaast worden logistieke oplossingen bedacht en uitgewerkt. Dit betekent dat voortdurend alle logistieke processen en systemen onder de loep genomen worden en vernieuwen. Samen zorgen IT en Logistiek dat systemen en applicaties van bijvoorbeeld het ordermanagement optimaal functioneren.


Architectuur in agile omgeving

Daarnaast zijn er twee presentaties / Q&A sessies gepland met bedrijven uit diverse sectoren waarin we laten zien aan de hand van praktijkvoorbeelden hoe binnen bol.com architectuur wordt ingevuld in een agile omgeving. Daarbij gaan we zeker in op hoe je scrum gebruikt in een software ontwikkelomgeving met meer dan 30 teams.

Sometimes development is just work

No matter how cool your job is, no matter how many people are looking at you or your company for best practises, sometimes developing software is just work 😉 On this blog I’ve shared examples of companies that people nowadays see as successful, like Netflix, Twitter, Spotify, or the online retailer bol.com.

To prove my point I’ve checked the release notes of Netflix and Spotify apps. Here is what they show for recent updates:

Software development at Spotify is just work

You can find recent release notes for Spotify. For future reference here is a screenshot of how these looked today:
Software development at spotify is just work

As you can see it is mainly fixes and a new translation… Where did all the fun stuff go. Think the cat took it? So crafting software could be “just” improving and step by step creating a great product!?

Software development at Netflix is just work

Now lets look at Netflix. Just looked up the release notes of Netflix in the iTunes store. Here is how they looked today:
Software development at Netflix is just work

Wow! Updates and bug fixes. That sounds really cool. That must be loads of fun. So could it be that even working on awesome apps for great companies is (at least for a part) just work?

Success needs work

So sometimes software development is just work. Just don’t forget:
The only time success comes before work is in the dictionary.
Could have said it better Harvey: The only time success comes before work is in the dictionary.
Fun and play are a part of you as a person. Work is just a way to make it flow…

Book – The Phoenix Project

Book The Phoenix ProjectThe Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win is written the by Gene Kim in the tradition of The Goal (1984, by Dr. Eliyahu M. Goldratt). The Goal is a management novel explaining the Theory of Constraints. This book, The Phoenix Project shows how the theory in The Goal works in an IT environment.

The Goal – Theory of Constraints

In simple terms the Theory of Constraints is about:

A chain is as strong as its weakest link.

In this theory the first step is to identify the constraint. Step 2 is to exploit the constraint. In other words, make sure that the constraint is not allowed to waste any time. Only by increasing flow through the constraint can overall throughput be increased. This to the extend that improving something anywhere not at the constraint is an illusion.

Because of the need for flow, work in process (WIP) is the silent killer. Therefore, one of the most critical mechanisms in the management of any plant is job and materials release. Without it, you can’t control WIP.

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win

The Phoenix Project describes the problems that almost every IT organization faces, and then shows the practices (based on the Theory of Constraint, Lean and more) of how to solve the problems. The main character Bill, is thought how to deal with these problems using the Socratic Method. Each dialogue a question is posed to which in turn causes Bill to think and to talk to his colleagues to come up with a solution to their problem.

Bill starts to see that IT work has more in common with manufacturing plant work than he ever imagined. Leading to the application of the Theory of Constraints in terms like:

The First Way helps us understand how to create fast flow of work as it moves from Development into IT Operations, because that’s what’s between the business and the customer. The Second Way shows us how to shorten and amplify feedback loops, so we can fix quality at the source and avoid rework. And the Third Way shows us how to create a culture that simultaneously fosters experimentation, learning from failure, and understanding that repetition and practice are the prerequisites to mastery.

Work in process in IT perspective

Until code is in production, no value is actually being generated. It’s merely WIP stuck in the system. By reducing the batch size, you enable a faster feature flow. In part this is done by ensuring the proper environments are always available when they are needed. Another part is automating the build and deployment process. Here we recognize that infrastructure can be treated as code, just like the application that Development ships. This can enabled to create a one-step deploy procedure.

Besides the parts mentioned before this requires removing a unneeded (since no value is created) hand off between Development and Operations. For this to work the two have to be integrated, not separated.

Like in a manufacturing plant, in IT, it is crucial to manage the release of work to the shop floor / development and to track the work in process. There are a lot of visual aids available to support this, like Kanban or scrum boards. All have their origin in lean or agile ways of working.

No need to say that in the novel this all works out pretty well 😉 In real life we see that these principles work, however more iterations are needed to really improve things. These iterations at first look like failures because of the acceleration of entropy. They are needed in the learning process of people and organization. Reduce the feedback cycle and learn fast!

On the relation between business and IT

There are some interesting statements in the book, that are heard more often in the industry.

IT is not just a department. IT is a competency that we need to gain as an entire company.
We expect everyone we hire to have some mastery of IT. Understanding what technology can and can’t do has become a core competency that every part of this business must have. If any of my business managers are leading a team or a project without that skill, they will fail.

And:

In ten years, I’m certain every COO worth their salt will have come from IT. Any COO who doesn’t intimately understand the IT systems that actually run the business is just an empty suit, relying on someone else to do their job.

Personally i think they hold at least some value. Please share your ideas in the comments.

Presentatie op LAC congres – Agile architectuur presentatie

verleiding - Agile architectuur presentatieWoensdag 26 november en donderdag 27 november is het jaarlijkse LAC congres. Dit congres voor architecten in de wereld van organisatie en IT heeft dit jaar als thema: “Architectuur in Actie“.

Presentatie Afweging waarde van architectuur en time-to-market

Op donderdag zal ik een Agile architectuur presentatie geven in de track architecuur in actie: “Afweging waarde van architectuur en time-to-market

Zo’n beetje iedere architect of ontwikkelaar komt op het minst in de verleiding: een snellere time to market realiseren ten koste van de architectuur of de kwaliteit van de implementatie. Het komt voor in software-aanpassingen, maar ook meteen bij de introductie van nieuwe technologie. Aan de hand van voorbeelden uit de afgelopen twee jaar, laten we zien hoe we hier bij Bol.com mee omgaan. Bij een bewuste keuze kan architectuur of de architect wel eens de factor zijn die de versnelling kan realiseren.


Het complete programma van het LAC congres.

Lessons of product development at Netflix

Just a month after sharing my post on Spotify engineering culture, I found a post on Startup lessons from Netflix. That was written inspired by a talk on fast delivery devops by Adrian Cockcroft. Who spent a long time building up Netflix’s cloud infrastructure and spearheaded the development of many new cloud-related technologies and techniques at the company.

Adrian Cockcroft’s lessons of product development at Netflix

Adrian’s lessons of product development at Netflix are summarised in this sheet:
Lessons of product development at Netflix
Besides from the different angle and focus on cloud, I think that there is quite some overlap with the Spotify presentations. If you have a different take at this, please leave a comment or meet me at the LAC congres where I will be presenting on time-to-market vs architecture…

Spotify engineering culture part I & II

I’ve been reading quite some article on engineering culture and ways of working. The videos on Spotify Labs are among the best sources I’ve watched or read in the last year on the subjects of agile and culture. Recently the second part of their series on Spotify’s engineering culture was released.

Spotify engineering culture part I


Important take aways for me were:

  • Agile over scrum
  • Principles over practices
  • Servant over master

Spotify engineering culture part II

Very cool that one of my favorite quotes by Mario Andretti was used in the video:

If everything seems under control, you’re not going fast enough.

To cope with this aspect you need a fail friendly environment and a limited blast radius. For the first focus on fail recovery instead of an fail avoidance. For the latter focus on a decoupled architecture.

A healthy culture heals broken processes! Growing organizations have growing pains. Culture can either magnify or heal them.

Update: Henrik Kniberg on Scaling agile at Sporify

The hour talk that Henrik Kniberg gave on Scaling agile @ Spotify is also available on vimeo:

.

Lean, agile and Software development reading list of 2013

In this blogpost I’ll share a list of books I read during the first six months of 2013.

Hadoop – The definitive guide

Hadoop the definitive guideThis book proved very useful to get an introduction and solid background in Hadoop. I was reading it a little before starting an enhancement of MapReduce code. This made it possible to better understand the production code and how to make the changes.

Hadoop The Definitive Guide (amazon) is recommended for anyone interested in Hadoop stuff.

Essential scrum

Essential ScrumWanted to read Essential Scrum to renew and deepen my theoretical knowledge of Scrum. This is a great read for that purpose!

I like the visuals that are used and set it apart from other books on the subject. Besides that I liked the MindMap-like figures that support the stucture in the chapters.

The scope goes beyond the core of Scrum and does that well. It also touches on subjects like Multilevel and Portfolio planning, The role of managers in Scrum context, and Product Planning.

This is a great follow up read for anyone with basic Scrum training or certification. It doesn’t just offer the big picture but both details and examples on how to become more agile. It will help you deal with the complexities of implementing and refining Scrum.

Thinking Fast and Slow

Thinking Fast And SlowThe aim of Daniel Kahneman the author of Thinking Fast and Slow is to enrich the vocabulary of people talking at a watercooler, where opinions and gossip are exchanged. He wrote this book to influence the way they talk about judgements and choices of others. He has succeeded. As Economist has put it: Kahneman shows that we are not the paragons of reason we assume ourselves to be. When you realise this it put you and the world around you in a different perspective.

Mr. Kahneman is a person that understands like no other on the planet how and why we make the choices we make. He knows how to share his insights! This is a great read for any curious mind, escpecially those with an interest in how and why we make choices.

This book will change the way you think.

There is an interesting talk on Thinking Fast and Slow by Mr Kahneman at the The Long Now.

Seven Databases in Seven Weeks: A Guide to Modern Databases and the NoSQL Movement

Seven databases in seven weeksThe book Seven databases in seven weeks will take you on a tour visiting some of the hottest open source database today. This is typical software development reading.

It has a progressive style of offering insigts to databases and their capabilities. The open source databases covered are PostgreSQL, Riak, Apache HBase, MongoDB, Apache CouchDB, Neo4J, and Redis. These were chosen to span five database styles or genres: Relational, Key-Value, Columnar, Document and Graph.

This book is recommended for anyone looking for a solid introduction fo databases besides the traditional RDBMS. It will provide the knowledge you need to choose one database to suit your needs.

Scrum guide mind map

Just found out I forgot to publish the Mind Map I used while studying for my scrum master certification. The mind map is based on the scrum guide. Download the scrum guide mind map pdf.

Scrum Team

  • Product owner: Responsable for maximizing the value of the product. She manages the Product Backlog.
  • Development Team: Does the work to deliver the releasable increment. The team is self-organizing and because of that needs to be cross-functional. It’s size shoud be somewhere beteen 3 and 9.
  • Scrum master: A servant leader who makes sure scrum is understood and enacted.

Scrum Events

  • Sprint: Time-box (month) to create the useable, potential releasable product ‘Increment’. Can be cancelled only by the Product Owner
  • Sprint Planning Meeting: Or actually a part focussing on the What and part on the How. On the what side focus on Forecast functionality based on the Product Backlog, Latest Increment, Projected capacity of the Development Team and Past performance of the Development Team. The How boils down to the so called Sprint Backlog.
  • Daily scrum: is performed by the Development team and answers 4 questions in 15 minutes: What has been accomplished? What will be done next? What obstacles are in the way? And syncs activities and plan for next 24 hours.
  • Sprint Review: Held to inspect the increment and adapt the Product Backlog. Time-boxed at 4 hours.
  • Sprint Retrospective: Where the Scrum Team inspect itself on people, relations, processes and tools. Besides that it plans for improvements (adapt). Time-boxed at 4 hours.

Scrum Artifacts

  • Product Backlog: with description, order/priority and estimate. Maintained by backlog grooming.
  • Sprint Backlog: Monitor sprint progress on the (total) work remaining. Set of Backlog items selected for the Sprint + a plan for delivering the product Increment and realizing the Sprint Goal.
  • Increment: The sum of all the Product Backlog items completed during a Sprint and all previous Sprints.

Definition of done

The definition of done is used to have a shared understanding of “done”. You can find a good definition of done example on this blog.

Professional Scrum Master I Certification

Certificate Professional Scrum Master I

Certificate Professional Scrum Master I


Maybe you noted that there was a growing number of post on subjects like Scrum, Agile and Lean on my blog. Because of my renewed experience in this field. I decide to go for certification on the subject.

Besides the Scrum Guide and a training, you can find additional Scrum resources i like here. While studying I created a mind map using the scrum guide.
As you can see in the picture in this post I succeeded.

Congratulations on passing the PSM I assessment! You have demonstrated a fundamental knowledge of the Scrum process. This qualifies you for certification as a Professional Scrum Master I.