Lean Beliefs

Tag Archives: Continuous Delivery

30 mins 1 on 1 discussion (more or less) with Mary Poppendieck

Agile, Lean, Software Engineering / , ,

Last week I attended the optionalconference.org event that was again a great opportunity to meet Agile-minded people and hear about lots of interesting and useful stuff. Clearly the biggest highlights were the keynote speech by Mary Poppendieck and the 30 minutes I could spend later on talking to her, first 1 on 1, and later in an ever growing group of people.

The speech was a funky combination of talking about scaling organizations (probably this was the part that she was “ordered” to talk about), and some really cutting edge topics around Continuous Delivery and DevOps.

In our 1 on 1 coffee-break discussion of course she emphasized how pull-based Lean systems are much better than having backlogs and sophisticated planning activities. This one was not really surprising, given that she “invented” Lean Software Development. The interesting part was, however, when she started to talk about databases. In her theory, big central databases (no matter how fast and efficient or “distributed” they are) are bad, because they enforce tight coupling of business logic functions built on top of them. In the era of microservices, you can react to customer demand of new functionality (“pull”) fast enough only if your services don’t have to be integrated into a big system all the time, but they can work quite independently. Of course data integrity should be kept, and for that, eventual consistency mechanisms exist.

So no matter how good DevOps you have, if your architecture is too complex, it can be the other (dark) side of the Continuous Delivery coin.

Agile: How different and still how similar…

Agile, Lean, Software Engineering / , , ,

Recently I’ve met several people from a small software company. As lots of startups in my country, they used to start their business in the professional service area, but building on more and more similar successful projects, they have started to productize their software.

They are just in the beginning of adopting an Agile process, and talking to them revealed to me (in spite of being in a quite different area of the software industry and having a company 2000 times smaller than the one I work for) how similar challenges do these people have compared to what I’ve seen in the last 10 years:

  • Struggling with upfront estimations often proving to be wildly wrong
  • Learning that hundreds of pages of specifications are worth much less than frequent feedback from customers
  • Priorities of features changing frequently, both needing to serve a long-term product roadmap and short notice requests
  • Stakeholders having vastly incorrect assumptions about complexity of software engineering work
  • Finding the right balance between perceived speed and real speed, like spending overhead effort on removing technical debt and doing test automation for continuous delivery (utilization vs lead time)

Surprise, surprise…

The year of…

Agile, Software Engineering / , , , , , , , , , , ,

Happy New Year Everyone!

I thought I would write my first blog post this year about what you may have read plenty around this time of the year: the “year of” topic. Not just the upcoming year, but the last few ones as well, from a completely subjective standpoint.

2010: The year of SMARTPHONE – I got my first BlackBerry, WHOA! We also started to work with iPhone, and experiment with Android. A whole new world, definitely.

2011: The year of TABLET – BOOM! The iPad came and conquered. I still don’t know what tablets are good for, besides the kids playing games, and me watching a movie with my lovely wife in the evening, and I especially don’t have a feeling for phablets (they are not big enough, but they also don’t fit into your pocket), but I don’t have to sympathize with everyone, after all half of the world has an IQ lower than 100 (by definition), and I have at least 101 – how humble I am :).

2012: The year of HTML5 – Peek of the cross-platform mobile app development struggle. Even though developing software for iOS and Android and Windows is 1x + 1x + 1x == 3x effort, and developing cross-platform software with JavaScript and various HTML5-based frameworks is 5x due to the technology being not only premature but having been invented for a completely different purpose, and the result being highly inferior, some very smart people like the idea very much, so we live with it, fact accepted.

2013: The year of ENTERPRISE BIG DATA – People realized that hardware is cheap and good enough for completely redefining corporate system architecture (forget data warehouses and batch processes), so we in SAP ended up being in the HANA-fever. We still run ahead with 41 °C fever, and eventually the whole world will be heated up (further global warming granted).

2014: The year of CLOUD – Instead of emphasizing how much the business model of the whole software industry is turning upside down, I would take two examples from my private life. CDs can be retired, listening to music while driving is by now Spotify-only. What else. Grocery shopping is done via Out of Milk, the whole family cloud-synced all the time (and btw, speech recognition finally became mainstream (when I say something into my iPhone or my wife’s Samsung Galaxy with my Hungarian accent (and btw2, even in Hungarian), it recognizes well)). Life will never be the same again.

2015: The year of…
– NOT IoT – I think it’s not there yet, lots of edge use cases available, but no mainstream killer apps predicted for the upcoming year. Maybe in 2016.
– ESPECIALLY NOT wearables – If you are not a runner, what are they good for, honestly?
– EVEN MORE NOT AI – just take language translation for example: Try out Google Translate and you’ll see what I mean. Bad joke still.

So what then?

I think 2015 will be The Year of DevOps in my little world of software engineering. In 2013 Continuous Delivery was a nice thing to hear about, in 2014 it was something we wanted to experiment with, and in 2015 it will be a matter of life or death. We should forget about the distinction between developers, testers, release engineers and operations. We have to work together on fully automated solutions that build, test deploy and monitor software, and thus provide the dynamics everyone expects from software that runs the whole world in 2015.

Sustainable self-destruction of software development projects

Agile, Lean, Philosophy, Software Engineering / , ,

Sustainable self-destruction is the golden mean lifestyle of most of us as individuals, the way we balance between too short term and too long term thinking and behavior.

We don’t like extremes. One of these extremes is total self destruction. If someone doesn’t care about the future and only considers having fun in the present or the short term, it certainly leads to serious negative consequences in the mid/long term. Consider hard drug addiction (that leads to dying young) or robbing a bank for having lots of money “easily” (that usually leads to spending a very long time in prison).

The other extreme is constantly pursuing ethical or religional perfection (and I’m not speaking about which religion is “right” and which one isn’t). If someone has total temperance and always behaves according to strict moral rules, it is definitely a short term competitive disadvantage, but in the long term it is perceived to lead to bigger harmony in life (and/or afterlife, whatever). Most people don’t like this philosophy either, as it is perceived to be less fun.

Most people usually try to balance this out, and have a lifestyle that I call sustainable self-destruction. Try to gain as much as possible (money, power, popularity, amusement etc.) as easily as possible, preferably not breaking the law in a very visible way and not hurting other people at least as much as our somewhat still existing conscience is still OK. Consider the health of ourselves and our planet. Sometimes even donate our time, energy or money to a noble purpose. For some people this balance can be quite a stable thing, some others keep going back and forth, but it’s basically the same thing: we aim for avoiding both too short and too long term thinking.

You may have guessed from the title: here comes the analogy with software development projects.

First extreme: too short term focus – We run towards burnout, technical debt, sacrificing our private life, code maintenance hell later on etc. for the fun of gaining quicker promotion or just getting bigger credit for delivering an enormous amount of features too much in a hurry, not caring about good architecture, code quality or having a great team.

Second extreme: Agile / Lean perfectionism – Always do pair programming, TDD, don’t release anything until all the 42 elements of the Definition of Done are fulfilled, this way most probably losing credibility with top management, failing to use windows of opportunities, not meeting customer expectations regarding deadlines (yes, deadlines), exceeding project budget and so on.

Traditionally, most good developers would prefer something closer to the second extreme, while project managers would vote for something closer to the first one. So in the end we arrive to some kind of a golden mean here as well. When we have to rush towards deadlines and accept ambitional project scopes based on aggressively (or even arrogantly) estimated backlog items, we do these to keep customers or product managers happy. However, when we don’t have to hurry too much, we “do our best” to increase automated test coverage, decrease technical debt, do more code reviews, improve the documentation etc.

This is again usually a constant struggle of back and forth. My theory (and wish) is that as we move towards continuous delivery, the amplitude of these back and forth waves decreases to an acceptable level.