We don't do sprints any more ...

... we do iterations instead.

A couple of month ago a client of mine started with an effort to work in an agile way – inspired by scrum, as far as possible.

One of the first things we agreed upon was to avoid scrum-speak whenever possible. For example we don't (yet) deliver (potentially) working software to the end-user at every iteration. So we do not call the iteration a sprint.

There are many other things –like not having a truly cross-functional team etc.– that would make it a plain lie to say that we are using scrum in this project, so we don't call it scrum. We don't call the process-coach a scrum master and so on.

The surprising by-product: better communication

The most fascinating thing here for me was the effect the wording had on upper management. "Cancelling a sprint because the sprint-goal is no longer attainable" is somewhat hard to discuss with people outside the agile world without some in-depth discussion of the terms. "It makes no sense to continue with this iteration because the thing we wanted to achieve with it is no longer achievable" is much easier to grasp.
[Language remark: And this was German by the way – for those who know the language "Wir müssen den Sprint cancelln, weil wir das Sprint-Goal nicht erreichen" is way harder to understand for outsiders than "Wir brechen die Iteration ab, weil das Iterations-Ziel unerreichbar geworden ist"]

There is an adage from Jerry Weinberg wich comes to my mind here:

«If you call the tail of a dog a leg – How many legs does the dog have? Still only four – just calling the tail a leg doesn't make it a leg!»

So, how about you? Do you do Sprints? Do you do Scrum? Do you have a Product Owner? Really?

Why not try an experiment? Instead of using vaguely fitting terms from a process framework, start using terms that describe what you’re doing in “layman's terms” and see what happens.

You might spark a whole new conversation.

till next time
  Michael Mahlberg

Don't neglect software craftsmanship

Even though the software craftsmanship manifesto doesn’t really stand on it's own (it just adds to each of the values from the first page of the agile manifesto) the general points made there are now more true than ever.

In Germany alone for example the number of people writing software doubles every 3 years. That means half of the people writing software in Germany have less than three years experience in doing so.

Three years is exactly the time it takes for a baker in Germany to get through his apprenticeship and become a “Bäckergeselle” (a journeyman baker). Same for a carpenter.

In the kind of crafts where there still is an apprenticeship-period those three years are spend honing the relevant craftsmanship-skills – is the same true for software-developers?

How much time do you spend on honing your craftsmanship?

Books like “The pragmatic programmer” or “Clean Code” do a great job in explaining how software craftsmanship can be embodied – but how often do we take the time to follow their advice?

I don't know for sure about other countries, but at least in Germany there is the non-profit organization softwerkskammer which is dedicated to fostering software craftsmanship through activities outside work but focusing of professionalism in the area of software development.

And with an area that moves as fast as ours and with respect to the Japanese mindset of keeping “A Beginners Mind” all of your life, for me it pays off to be active or at least participate in such an organization.

So – have fun with your local chapter of the closest software craftsmanship organization.

till next time
  Michael Mahlberg

Blocking it to get free

Product development can greatly benefit from the Kanban-practice of ‘managing flow’.

Let’s look into one aspect that seems counterintuitive, but helps a lot in managing flow – the option to mark ongoing work as blocked.

Even if only the first core property of Kanban – visualize the work – is implemented, the agreement to mark stuck items (items that can’t be worked on right now) in a highly visible manner sends a very recognizable message to anybody looking at the visualization.

Having a blocked Item in the system means that there ‘is a disturbance in the flow’ and thus work downstream – and upstream – of this blockage might be affected. When the disturbance is highlighted and openly visible, all parties involved can act in their own area of influence to handle this disturbance. They might decide to delay some work, swarm to get the blocked item unblocked, or find completely new ways to get rid of this blockage.

Therefore marking a work-item as blocked in a Kanban system is a powerful measure to get the system free again and get the ‘flow’ flowing – leading to less work in progress and thus to shorter lead times and effectively a shorter time to market.

How do you handle tasks you can't work on right now? How many people can really see that the flow is ‘impaired’?

till next time
  Michael Mahlberg

The difference between bugs and requirements – and how to handle them

What's seems evidently different for some people might appear identical to others. Let’s see how different bugs and requirements really are.

There are different ways to look at this question...

By definition

If you look up the definitions of at the terms “bug” and “requirement” they may seem only vaguely similar, clearly distinct

Bug: “A [...] bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.” Software Bug, Wikipedia

 

Requirement: “1) A […] capability needed […] to […] achieve an objective.
2) A condition […] that must be met […] by a solution component to satisfy a contract, standard, specification, or other formally imposed documents.
3) [omitted]” IEEE, via Wikipedia

By point in time

But if you look at them by the point in time when they become manifest, they become a bit more similar.

A thing (like maybe some ‘feature’) that is not ‘available’ now, is just a requirement: “Cars should have visible (blinking) indicators that show where they want go” was a requirement before indicators were invented.

A thing that has been there once, but subsequently has disappeared, sometimes is a bug "That car's indicator should blink" is a bug report for a car on the road today.

So in some cases whether you look at a bug or a requirement just depends on the point in time you're at.

By reaction

When one looks at bugs or requirements with regard to the possible ways to handle them it somehow pays off to be sure who is looking. For now lets focus on the customer (product owner, product manager etc. – the person who pays for the things that the development team spends time on).

I don't see any reason at all to react differently – except with regard to further context.

Given that a so-called ‘bug’ surfaces in an already published piece of software that is used regularly the fixing of a bug has to have some budget allocated. And obviously it needs to be prioritized. From a business point of view this means that fixing a bug just is fulfilling ’a condition that must be met to satisfy the formally documented desired behavior’ for this bug ... sounds familiar?

If, on the other hand, the bug surfaces during the acceptance phase of a feature (or ‘system capability’) the situation is straightforward. Since the error wasn't present in the previous version of the software the new feature can't be accepted. The instruments of the respective process should be used to remedy the situation. That could be blocking the work-item, swarming, stop the line etc. – each way the error has to be fixed before the new feature can be accepted. Not a bug – just a requirement that has not yet been met.

By common (agile) sense

Now if we believe in test driven development (tdd) we start implementing each thing by writing some tests that tell us when we are done. If we follow behavior driven development (bdd) we might be able to map requirements directly to one or more bdd-specifications. Which we write first, before we implement the capability.

The first thing we do with a bug is to check whether we can reproduce it. Some people then write a test that demonstrates the bug. (according to the rule, that you just don‘t write any code that isn't required by some broken test)

So bugs and requirements are both firstly described by a test that is ‘red’ (or breaking) and then implemented – not much of a difference here.

By work item type

Now this a thing that even in my opinion justifies to differentiate between a bug and a requirement – or isn’t it?

I think in some cases bugs (from a system that is already in use) are different from other requirements in the ratio between size and value. So while most system capabilities that can be described by user stories are comparatively expensive while bugs sometimes are cheap to (e.g. with little effort) fix and yield a high value by making the user experience much more enjoyable (for example if they don’t have to confirm erroneous error messages any longer).

There is no bug

In the end a bug just is special kind of requirement. And when and whether to fix it should be a business decision just like any other prioritization of requirements. For a web-based shop-system that has the bug “’stay logged in’ doesn't work” and a feature request “Add the capability to use the most commonly requested credit card” the decision what to do next might very well favor the feature over the bug. From a business perspective it might be acceptable for a while if users have to re-enter their credentials every time, even though they activated the “stay logged in” box while not having the capability to pay by credit card can be a real problem for the business.
Some bugs are quite easy to live with, while it’s really a nuisance to live with some unmet requirements.

So – how do you handle your so-called bugs?

till next time
  Michael Mahlberg

Keep your product in ship shape

Originally ship shape meant to adhere to the standards of tidyness and alertness necessary on seagoing vessels of the old times, where things tended to get turbulent from time to time.

Nowadays, with paradigms like ship it or the famous potentially shipable product increment another meaning emerges, at least in my perception.

Don't strip the headlights to get the tail lights working

When I was much younger than today I used to repair my cars myself. Partially out of interest, partially out of distrust towards the garages and partially because of financial restrictions. And of course, because in those days it was still possible to work on ones own car.

One of the things we used to do when some part didn't work was to exchange it with something that did. (duh!)

For example one time when the headlights where not working me and a friend tried a variety of things – after exchanging the bulbs and some tweaking with the wires we finally concentrated on the fuse which looked fine. But to make sure, we exchanged it with a fuse we knew to be in working order – the one that was wired into the headlight circuit.

And sure enough the taillight lit up. So we changed everything else back to the original state – bulbs and wires and all. Or so we thought.

The one thing we did not change back was the fuse. Silly – we simply forgot.

Happy to have working taillights again (the bug was fixed) I drove home. Almost. At least as far as the next police station, where a friendly officer motioned me to stop and explained that I could not drive with a car with only one headlight.

Today I see this happening with software all the time – people fixing just the problem at hand, without realizing what havoc they bring upon the rest of the system.

So please – whenever you “fix” a piece of software: Make sure that you can still ship the whole system.

My car was definitely not shippable at that time – make your software-craftsmanship better than the car-mechanic handywork of an untrained teenaged boy and keep your product in shipshape. In a state where it can be shipped to the real customer all the time.

till next time
  Michael Mahlberg

The next big thing...

... probably won't save your project.

If you have seen the Gartner hype cycle model you are probably familiar with the terms “Peak of Inflated Expectation” and “Trough of Disillusionment”

Gartner Hype Cycle Model

While the hype cycle model itself is heavily debated and criticized, I for one see that a lot of “new things” follow this kind of adoption curve.

But why is that? And why is it so common around things as diverse as programming languages (e.g. Java), Infrastructure (e.g. Build Servers), Methods (e.g. eXtreme Programming) and techniques (e.g. test driven development, TDD) to name a few?

What works for Early Adopters doesn't have to work for everybody

One reason I have seen for this is the simple fact that tools in the hands of experts can become menaces in the hands of laymen. This is not only true for things like the beautiful Katana (a Japanese sword) a friend of mine inadvertently used to cut an artery in his arm. No worries: he got treated real soon and has no lasting injuries. And the tatami (floor mats) got cleaned as well by now.
But back to the question at hand – other tools are also often quite dangerous in the hands of the “non-expert.” While it is hard to injure yourself on the sharp edge of the Java programming language, it still is quite possible to use it in a harmful way – for example by over-using mechanisms like reflection, a powerful feature that makes it possible to change the program from within while it is running or change the accessibility of parts of the software.

In my experience this is what happens when the tool reaches the “Trough of disillusionment” – badly trained people start cutting themselves too often and the effectiveness of this tool for the masses becomes a subject of discussion.

In Iado (an art of moving the Japanese sword) there are several ways to avoid the self-injury of the novice swordsmen. They either use a Bokken – a wooden sword look-alike – or a Katana-like thing with a blunt edge, the so called Iaito.

This, to me, seems to be what happens, when these tools reach the “plateau of productivity” – they get blunted down to make it harder to injure oneself.

And of course it works. In a way. With their blunted down instruments, it is much easier to let more people with less training do jobs similar to the ones that the early adopters did. Those early adopters whose efficiency with these tools made the tools so compelling.

But there is a drawback – with a Katana you can easily slice through a steel plate (for example). You just can not do that with a Iaito.

So please – if you use the blunted down version of a tool – don't expect it to still work like the real thing.

Adjust your expectations and always take into account who is wielding the tool.

till next time
  Michael Mahlberg

In Lean "Value to the Customer" actually trumps ... "Eliminate Waste"

A lot of people starting with lean think that the topmost goal is to eliminate waste.
Maybe it is just because the Poppendiecks started their first book on Lean Software Development with the principle "eliminate waste", or maybe it is because "Eliminate Waste" makes such an impressive battle cry.
The so called lean decision filter (described nicely by David J Anderson in an article on providing value with lean) makes it rather clear, that in most cases waste elimination is just a ‘minor’ priority, easily trumped by Value to the customer.

The whole chain of trumps in that decision filter is listed as

Value to the customer
    trumps
Flow
    trumps
Waste elimination

This list makes it way easier to decide what to work on next, as Yuval Yeret explained in an article at the leankit blog.

So, next time you ask yourself what to do next you might consider applying this filter instead of going by simple "always do x" rules.

till next time
  Michael Mahlberg

Breaking down the task-board

Have you ever experienced that dull task breakdown session, where you started with a couple of concepts (lets say street and phone and country) and ended up with a list of three or four tasks that somehow re-occured several times?

In this case perhaps:

• modify database schema to accommodate street
• modify ui to display street
• modify validators to validate street
• modify database schema to accommodate phone
• modify ui to display phone
• modify validators to validate phone
• modify database schema to accommodate country
• modify ui to display country
• modify validators to validate country

In these cases it might help to think differently about your work – perhaps those repeating categories are in faction stations that each of the concepts to be implemented have to go through.

Some people would model this as three different stations

• Database
• UI
• Validation

If you put them on the board as separate columns each item could be reduced to it's concepts core and just ‘flow’ through the system.

Database	UI	Validation	done
street
			phone
		country

So, perhaps it’s time to rethink task boards, put in some of the ideas from lean and kanban and add a couple of columns.

(of course not with the exact names from above ;-)

Disclaimer:
And no I don't recommend building db-, ui-, and logic-silos. But if you have them, be honest and acknowledge the fact. Change it afterwards. Start with what you do now as they say in Kanban.

till next time
  Michael Mahlberg

How to plan for iteration 35 in iteration 1

"But how can we make sure that we can incorporate all those things that we will only discover well into the future if we don't design the system with an architecture that takes all those things into account?"

Well....

You can't. But neither can you (or anybody else for that matter) look into the future with certainty.

We all learn only from things in the past. Even if we think about the future and ‘learn’ from those thought, the process of thinking is in the past, when we learn.

We just can not predict the future.

But we can learn from the past.

We can learn to build systems in such a way, that they are comparatively easy to adapt to new situations and requirements.

That’s what patterns are for

Software Design Patterns are proven approaches to common problems that have worked in the past. That is how the GoF-Book, which made the whole pattern movement available to a broader audience, states the idea of patterns. You've got a problem you want to solve? Perhaps there already is a proven approach. Look it up. Chances are that the approach encompasses sound design principles and makes later changes attainable.

That's what refactoring is for

Software is more easily changed and extended if it is well structured. Refactoring, as it has been defined originally, ensures that the system stays well structured and easily modifiable. Use it. Follow ‘red – green – refactor’ if you have the chance or at least ‘refactor mercilessly’

That's what SOLID is for

The SOLID design principles (SRP, OCP, LSP, ISP, DIP) provide guidance on how to build actually change-friendly and robust software.

That's what Clean Code is for

Robert C. Martin also inspired the whole clean code movement which is not only about writing good code, but also provides insights on how to keep your whole development ecosystem in such a way that change stays easy.

Conclusion

You don't need to think about the details of iteration 35 in iteration 1 – if you ‘just’ factor in a small portion of the effort that up-front planning for iteration 35 would have taken for refactoring and restructuring in each iteration and follow sound software design principles you should be fine. After all iteration 35 may turn out to be something completely different from what you think now that it will be.

till next time
  Michael Mahlberg

Add some PDCA-Spice to your “Inspect and Adapt”

My beef with “inspect and adapt”

According to legend agile software development almost would have been called “adaptive“ software development. And for a big part that is what agile approaches are about.
It is all about adapting the process, the tools, the interactions to the situation at hand. And most approaches out there have very well defined ways to handle such changes.
But – and it is a huge but – nowadays some people justify everything they would like to change by just invoking “inspect and adapt.” But in some cases (and those are the cases I'm so agitated about) it is only adapt. Or not. Actually sometimes it is only change. But without inspecting first, there is nothing to adapt towards!

What adaptation is, ...

... is for example put nicely by wikipedia:

Adaptation, in biology, is the process whereby a population becomes better suited to its habitat. (emphasis added)

It is not some random change. It is based upon circumstances. Actual facts and requirements. And if one aspires to adapt to something intentionally that just is not possible without knowing those circumstances. In other words: it is necessary to inspect the circumstances.

If you gotta do it, do it right

So yes, you should follow “inspect and adapt” – just don‘t call it a method or try to imply that every time you change some aspect of your process you‘re following the ideas of “inspect and adapt.” If you want to change the ways you work for the better, try employing some formal approaches.

Take some advice from the Lean and Kanban community and follow the so-called scientific method, which – [according to the university of Riverside, CA] – consists of the following steps

1. Observe some aspect of the universe.
2. Invent a tentative description, called a hypothesis, that is consistent with what you have observed.
3. Use the hypothesis to make predictions.
4. Test those predictions by experiments or further observations and modify the hypothesis in the light of your results.
5. Repeat steps 3 and 4 until there are no discrepancies between theory and experiment and/or observation.

One of the approaches that has the thinking behind this ingrained in its DNA is the Deming cycle, often called the PDCA cycle.
The four steps P lan, D o, C heck and A ct actually implement the scientific method for the context of process improvement.

Some things about the PDCA-Cycle come up in conjunction with Toyota’s implementation that seem noteworthy:

• Plan
  build a model of the expected changes to the process – a model also specifying the expected outcomes of the changes
• Do
  try the proposed changes on a small scale, if necessary with extra effort (that can be accounted for in the check step)
• Check
  Verify that the process changes deliver the expected outcomes
• Act
  Roll out the changes to a broader audience, including the automation of labor-intensive tasks or roll back the changes and go to square one (e.g. Plan)

(The rinse-repeat of the whole cycle is somewhat implied by the name cycle, and thus the fifth step – start again with the next idea – is not made explicit)

One more thing... in fact, PDCA is not the Deming cycle – PDSA is

At least according to a guy called W. Edwards Deming this cycle is called the PDSA cycle – and he really should know it...

Be that how it may – the question remains: will you just randomly change things and justify those changes by citing “inspect and adapt” or will you inspect and adapt by following a scheme like PDCA and “install” or “back out” changes based upon feedback collected on some experiment that provided you with real data?

till next time
  Michael Mahlberg

Scrum Master or Zen Master?

Another Scrum-Master Anti-Pattern

Well – of course there is not one Scrum-Master anti-pattern. There are dozens.

Let's look at a special one today: The Scrum-Master as the Ruler, the Projectmanager, the Sovereign of the project.

To cut it short – Scrum-Masters are not.
Originally weren't meant to be at least.
Maybe sometimes they actually are – but they should not.

It is about the verb ‘master’

Here is what the dictionary on my computer has to say about the verb master:

2 it took ages to master the technique:

learn, become proficient in, know inside out, know (frontward and) backwards; pick up, grasp, understand; informal get the hang of.

If you look at it that way, a scrum master becomes to scrum what a zen master is to zen: someone who has mastered scrum and now is able to help others – at their request - to become more proficient in what they do.

Of course he also has a lot of other duties as well, but the fundamental idea of ‘mastering the process framework‘ in contrast to being the 'Master of the team' is really a big difference in the attitude.

The Scrum Guide explicitly states that ‘The Scrum Master is a servant-leader for the Scrum Team’, perhaps this is worth taking into consideration from time to time.

till next time
  Michael Mahlberg

Effective daily scrums – and how to achieve them

In this case my advice is contrary to what I usually say. This time my advice is not to go by the book!

Remember the purpose of the daily scrum

The purpose of the daily scrum is to plan ahead for the next 24 hours. It is not about reporting progress. Of course it is an important part of the planning to know the current situation, but the focus should be on the things you are about to do.

"What did I do in the last 24 hours", "What will I do in the next 24 hours", "What hinders me in achieving the sprint goal?" – those (paraphrased) questions from the scrum guide, are there to facilitate a purpose as my esteemed friend and colleague Tom Breur points out. The purpose being constantly navigating the best way to achieve the business goal for the day.

It is like action planning for firemen

The daily scrum is more like firemen planning on how to tackle a burning house they are about to enter.

They don't talk about how they clung to the seats when the fire truck skewed around the corners – it is all about the future.
"I'll go to the left with hose", "I'll break the door open, so that someone can use the powder extinguisher" "As soon as you've broken up the door, I'll use the powder extinguisher to quench the flames in the hallway" etc.

Nobody want's to know how they quenched the last fire – it's the future that counts here. (I really love this example, courtesy of another esteemed friend and colleague, David)

Turn it around

The least you can do, to make the daily scrum more efficient and effective is to turn the questions around. Start with the future, mention any impediments you actually have and then talk a little bit about what you did. If there is anything left that the others don't know from the last daily meeting or the events in between.

It is not for 24 hours!

And what's more: You don't have to talk about your plans for the next 24 hours – all you have to do is to talk about your working time, and in most places this would amount to roughly 8 hours.

Talk about the future

If you have to tell your colleagues what you did in the last 24... sorry, 8 working ours, you probably didn't tell them what you planned to do in the last daily meeting. Or you had to diverge from your plans. If you had to diverge I very much hope you didn't wait till the deadline. After all the daily meeting is a deadline for the things you planned at the last daily meeting. You told your colleagues what you had planned to do between then and the following daily scrum. Usually it is a good idea to let everybody on the team know what has changed just as soon as you find out. It just might happen to interfere with the work of your colleagues as well. After all you would like to know if a co-worker changes his mind if your work depends on their result. Even – or especially – if they have a good reason for changing their plans.

So if you talk about the last 24 8 working hours you'll only end up telling people what they already know. Either from the last daily scrum or from observations and information during the last 8 working hours.

Instead, think of the firemen planning to extinguish the fire in a burning house – or the A-Team planning a mission.

till next time
  Michael Mahlberg

Iterations! “Done” does not mean "never to be changed again!"

One of the hardest things to understand in agile software development seems to be the concept of “iterative“ development.

Especially in conjunction with the concepts of done-done and definition of done.

In my experience people – developers and customers alike – tend to be confused by the opposing forces of “embracing change” and getting the current iteration of the product to a “done” state in “production quality.”

Although there are several very good explanations on the web, like the one from Alistair Cockburn, it seems very hard to express the basic concepts concisely.

The default example nowadays seems to circle around the different ways to paint the Mona Lisa, so let's start with that one:

• Incremental:
  • (could be similar to waterfall with milestones)
    • partition the canvas into an arbitrary number of rectangles
    • Start painting at the top left rectangle
  • This approach has the added benefit that you could dispatch a subteam to paint the bottom right rectangle and thus ‘scale’ the project. 1
• Iterative:
  • (closer to the standard approach in agile projects)
    • Do a rough sketch of the whole picture in pencil
    • Get customer feedback on the sketch
    • Erase some lines and areas
    • Get customer feedback on the sketch
    • Do broad fills with colors
    • Get customer feedback on the intermediate
  • In this approach you might even have one iteration where the Mona Lisa was blonde

While this model does a fine job in explaining the difference between iterative and incremental, it does not really address the topics of ‘done’ or shipping.

Partially that is due to the fundamental difference between Software and pictures – it is easy to keep on working on software after shipping, because we ship something that is mechanically created from the stuff we write. (No matter whether it is compiled and linked, compiled and put in a jar, packaged or anything else – we still don't have to let go of the stuff we created to ship to customers). There is a huge difference between paintings and software, so for me this is where the analogy stops.

In painting we get value from the customer feedback. In software products we oftentimes can get much more value from real-world use of the product we’re building. Or to be exact: from using the current state of the product that we are building with real customers.

Now to be able to do this, we have to do both – we have to build an increment of our product that is fully functional. And we have to iterate over parts that we already had ‘done’ the last time around.

Let’s look at a simple example – a sign up dialog.

We might want to offer some high-tech login integration via facebook, google and twitter later on, but since we’re just a tiny startup and haven’t yet gotten around to deciphering all the fine details of the OAuth2.0 protocol, for the time being we only want to enable registration via e-mail for the first launch.

So our first iteration of the login dialog only includes e-mail. But what about the design? Since we already know that we also want Google and others integrated, we could already do a real nice UI-design for all the options, couldn't we?
Well – we could. But we shouldn't. We would have to deal with a whole bunch of decisions about things that we only have vague ideas about. And would have to maintain those decisions for quite a while. One agile way of addressing this in an iterative, incremental way, would be to build an increment that is of production quality and make sure that it is easy to re-iterate over this part easily by employing techniques from good software craftsmanship.

So the first increment would contain a finished part of the product (with all the colors, to stick with the Mona Lisa metaphor) to make it really usable, but we would be willing and take precautions to change it later on (paint it over) to iteratively add new functionality.

So long for now
  Michael Mahlberg

Footnote: Scaling and iterations

Actually this also shows that this kind of work-breakdown and scaling is manageable if the expected result to be is known beforehand. We can now easily(?) put nine illustrators on nine pieces of a gigantic billboard that is to feature the Mona Lisa as long as each illustrator knows which part they are responsible for. But that would not have worked for creating (developing) the Mona Lisa in the first place.

What's in the Potentially Shippable Product Increment (PSPI)?

There are many references to the frequent release of running software in the agile universe – of which the agile manifesto certainly gets cited the most.

One term has become very prominent - the “potentially shippable product increment” from the agile sub-universe of scrum. [In this case from LeSS - the Large Scale Scrum Framework. ’Of course’ the scrum guide itself does not use this term. The scrum guide calls it “Increments of potentially shippable functionality”]

But since the notion of the potentially shippable product increments captures so much of the practices of good agile software craftsmanship I really fell for the term and use it more often than the official term from the scrum guide.

And it is a very handy way of illustrating what is behind the ideas of Integration, Shippable, Iteratively, Product(ion quality), w

Integrated

“All [created artifacts] have to be integrated” – the stuff really has to work together (as I outlined in more detail in what exactly is continuous integration).

Shippable

Something you could give the customer to play with on their own. An installer-file, an executable, a .ear-file with deployment description, a docker image etc. Something they could really “take away” with them.

Iteratively

We know we are going to change things - let’s build them in such a way, that it is (and stays) easy to do that. Even though we deliver increments of the product we do so iteratively – we do not try to paint a picture like the Mona Lisa from the top left to bottom right. We do it with sketches and refinements and edits until we are finally satisfied with the result.

Production quality

Production quality is perhaps the hardest one to explain without painting lots of pictures. One of the best explanations I've come across is that it "also has to work when the customer can use it without the developer being around" – which implies many little things.

Those things could include:

• a user friendly way to interact with test-data if there is something like that necessary for the relevant increment
• no buttons that don’t do anything
• no spinning wheels that are not connected to any of the inner workings
• etc.

Of course this is a bad definition, because it (almost) only defines a negative-list. It only says what production quality is not. I’m still working on a positive-list, and hope to release that soon.
One thing for that positive-list that springs to mind immediately is the requirement that the code adheres to the SOLID principles – so that it only has to be changed if a future requirement has an impact on the implemented capabilities – not because something has been left over “to be fixed when we work on this in the next iteration.”

How do you define your “Increments of potentially shippable functionality?”

till next time
  Michael Mahlberg

What exactly is continuous integration?

A while ago I wrote about the fact, that a build server can't give you continuous integration, now let's look at what we might want to accomplish with continuous integration in an agile project.

Three stories and a potentially shippable product increment

Let us look at an example from a scrum-inspired project. Suppose we have three backlog items (of course not necessarily stories in the Cohn format...):

• our product can do ‘X’
• our product can be installed on Windows
• our product can be installed on Android

The ‘old’ way

In an old-fashioned project, using ‘late integration’ those requirement could easily be met by having three separate results

• a web-application where the ‘x’ can be demonstrated
• an install-package for Windows, where some sample app, based on roughly the same technology stack as the ’product to be’, is installed
• an install-package for Android, where some sample app, based on roughly the same technology stack as the ’product to be’, is installed

These different artifacts could even be put in the same source-code repository and built by some type of build server, but they would not have to interact with each other, because that could be part of a later integration phase.

The problem in this scenario is that there is no mandatory requirement for a functional integration between these tasks.

So you could end up with an installer on Windows that just displays some “this would be your application” boilerplate text, an install package for Android that contains a different launch mechanism than the windows version and a web application that can do ‘x’ but is included in neither.

Even if the automated tests related to each backlog item would be ‘green’ on the build server, the customer would still end up with three separate “features” that might not generate any value for them.

The agile way

Building this with a continuous integration mindset would be different. Following the old ideas of continuous integration in conjunction with the mindset of a potentially shippable product increment yields quite different results. Especially since such an increment contains all the existing functionality as usable and working software.

In this scenario we would focus on integrating the functionality and make sure that every story we complete interacts with all the other stories.

And all off a sudden, the customer would have real value – whether the artifacts are built via a build server or not. As long as the team creates a thing that really could be shipped every time it integrates a task – in the functional sense – and makes it easily accessible to the customer, the customer can just take that artifact(s) and interact with all of the currently completed functions.

No ci-server required, btw.

’till next time
  Michael Mahlberg