Tag Archives: scrum

scrum

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.

Scrum – additional resources

scrumThe basics of Scrum can be found in the Scrum Guide. Besides that there are loads of resources available on the subject. In this post I’ll share a few Scrum resources with you I recently discussed with my colleagues:

Besides these the online lean and Scrum resources library of one of my colleagues gives some other great hints. You might also like to read his selection of 10 from ‘Corps Business: The 30 Management Principles of the U.S. Marines’.

Lessons Learned from (Scrum) Coaching sessions

Working at a customer in recent months I was on the receiving end of a Scrum coaching project. Unfortunately this ended early. And I started thinking about what I could learn from my angle as a team member. I came up with the following cases and hope they can be helpful for you as well.

Stick to your role and deliver value

If you take the role of coach in a certain expertise field, stick to the that role. This will give you focus and a higher probability of success in the field in which you perform really well. In addition to that, this is the thing/trick you are hired for. It is great if you can deliver additional value, and get the team of organization you are coaching to a higher level, only after you are delivering what you should deliver.

For example you’re coaching in SCRUM, and there is loads of work to do to get the Product Backlog in good shape, getting the documentation up to par, and help the people with the SCRUM way of working; it might not be the time to debate all kind of possible coding issues, try to remove commit hooks from SVN (requiring an JIRA issue number) and other stuff like that.

Should you as a coach decide to be a part of the team, you also have to commit to results delivered by the team (that now includes you). After you check out the code it doesn’t shown you value individuals if the only thing you do is place remarks and object without not delivering anything yourself (let alone things perceived as value by the product owner).

Stick to your role.

Focus

Focus on your assignment and the results you have to deliver. In the case you are coaching a team in the world of SCRUM it is not necessary to start a debate on all design, technical, technology and frameworks choices that are made in the first week. When valuing individuals and interactions over processes and tools, also keep in mind that it is the team of those individuals that made a range of choices. Some of them could very well be the result of much (heated) debate.

Focus on your assignment and the results you have to deliver. Don’t (re)fight every battle.