Whose job? On self-organized teams and responsibility

Basically this boils down to the statement that in my opinion there is a big difference between everybody being responsible for everything and everybody being responsible for the whole thing – and only the latter works.

The old story of four people

I once read a story about some people called Somebody, Anybody, Everybody and Nobody.

They where supposed to complete some Job that had to be completed somehow – let's not worry about details here.

It was a Job Anybody could have done – but Everybody thought Somebody would do while in the end Nobody did it.

While this is a cute little play on words, it –unfortunately– is also a phenomenon observable in peoples behavior. In his book „The Tipping Point“ Malcolm Gladwell quotes an experiment where a person in distress called out for help in two different environments. A densely populated area and a sparsely populated area.
The alarming –but understandable– result was that in the densely populated area everybody thought that somebody else would do something and so nothing happened for quite a while. In the sparsely populated are the reaction was quite different. This phenomenon has been dubbed the “bystander effect” a long time ago.

Who is responsible in a team?

Recently this question has been brought up in the context of Scrum teams, but it really applies to all kinds of teams.

You are not responsible for everything

The notion, that everybody on the team should be able to do everything and whenever a problem arises every team member should be able to fix it is not only unrealistic, the whole idea is counterproductive to the overall performance of the team. A team –as described for example in an article by R. K. Grigsby– is a group of people with complementary skills [who are mutually accountable and share a common goal].
Now, can you imagine a soccer team with all players being equally well suited for all positions? How high is the probability that such a team would have the worlds best goalie? Or the worlds best offensive? So clearly there have to be some areas of specialization –while still maintaining some skills in all the other areas– if you want to have the best team possible. But when the skills are not evenly distributed, neither can the responsibility.

You are responsible for the whole thing

But every team-member should be responsible for the whole. That is quite a difference. While I might not be able to perform a database change that is necessary for my new code I can still try a number of options to make sure that the system stays in good shape. I might track down a team member with the prerequisite knowledge. I might hold back my changes until I find some database genius on the team to pair with. I might find another design. If all else fails I might try to stop the line.
But I don't just do my part and move on and rely on the team to fix it because "the team is responsible to fix whatever goes wrong."

Let's not confuse self-organization with anarchy – self-organized on a team level means that the organization comes from within the team. Not from the outside. But this does not mean that everybody just does what they feel like. If the agreement is that Scott has the final say on database decisions, and whenever there is a decision about cryptography either Alice or Bob have to agree with it, then that may be the choice of the team, but it still is an organization that applies. And if anybody strays from those agreements –without negotiating them new– this betrays the mutual accountability within the team.

Therefore, in teams everybody is responsible. Yes. But for the whole, according to their specific capabilities. And it is a question of team organization how the team members act on this shared responsibility.

And remember "responsibility can never be assigned, it can only be assumed".

till next time
  Michael Mahlberg

Boards: Paper vs. Digital – when, how and why

There are all kinds of boards around – Scrum Boards, Task Boards, Personal Kanban Boards, Story Boards, Portfolio Boards, Kanban Boards etc. – and all of them can come in different flavors. Two of the most distinctive flavors are “physical“ and “digital” and the difference is huge!

Even though the names differ, all the boards are in some way descendants of the kanban boards used in manufacturing, notably at Toyota.

(Of course there is a huge difference between kanban systems in manufacturing and virtual Kanban systems, therefor in Kanban the kanban is not the kanban, but that is another story)

Why use a board at all?

The first rule of Kanban is not ”You do not talk about it”.
Instead it is “Make it visible” or, to quote the correct words “Visualize the workflow” – and that is what a board is good at. In my early days with agile we called all kinds of boards “information radiators.” That term also referred to burndown charts, and burnup charts, and earned value visualizations, and defect maps, etc. – whatever was helpful, but never all of them at the same time.
The point is: information should be radiated. Made visible to everyone. And it should be the relevant information at the point where it is relevant.

Communicate!

Okay, so that is one part of it. But is there anything else, besides visibility?
Yes there is – such boards can also be a great way to communicate!
When they are located at places where everyone on the team notices when somebody else updates the board a lot of information is conveyed implicitly. Not to mention that the boards can serve as a culmination point for standup meetings and as a tangible way to discuss the current state of flow.

Create bite size chunks

Even if there are no WIP-Limits on the board, as long as they are physical there also is a physical limit on what can be put on the board. Just realizing – for example – that you can't put any more cards in “quality assurance” without calling some brick-layers to remodel the rooms can persuade teams to shift their work-focus.

Model your process

In Kanban for knowledge workers (the one with the capital K) the board also is a physical representation of the actual process – including process policies like WIP-Limits or cadences and such.

Electronic boards make change harder

Huh?
Seriously?
No, of course not – at least as long as you're the administrator of that electronic board. And you don't have too many reports that rely on the boards layout. And nobody shares basic definitions like stations (a.k.a. columns or status-values) or classes of service. And you have a way to remove stations that are not empty. And you can easily inform everybody about the new process policies that go with the new board layout.
As long as all of these preconditions are met, electronic boards don’t make change harder. But as soon as you introduce central administration, create elaborate dependencies, share basic assets etc. change becomes a lot harder.
After all agile software development was meant to be adaptable and one of the most important parts is that there are retrospectives (or operations-reviews). But what good are those retrospectives if it is not possible to easily (!) adjust the process accordingly?
Where is the empowerment of the team if some tool-administrator hast to edit status values, so that the so-called self-organizing team can get their new buffer column (or something like that) on the board?

Electronic boards reduce visibility

There used to be a saying "DOORS - where requirements go to die!". Lately DOORS in this quip has been replaced by the names of more modern tools, but still there is a bit of truth in that saying.
Requirements that are stacking up in a tool (usually) don't make you feel uncomfortable. Unlike walls, tools have almost no limitations and the difference between, lets say, 350 and 850 un-reviewed requirements is quite easy to miss.

It’s about learning!

One of the great effects that can be experienced by going through the pain of really modeling the actual work we do is that we learn a lot about our processes. And adjusting the visualization over and over again is what reflects this learning. We might start with a five station (column) board and end up with a five station board. But if our board really reflects the learning it will probably have experienced times with a lot more columns in between.

(Try to) always start physical

And since everyone can break the rules on a physical board (hang a card sideways to indicate an improvised class of service, write a new rule, suggest a new cadence etc.) which is immediately visible to everybody who comes along to interact with the board, physical boards facilitate the willingness to experiment. And there is a much smaller risk to break anything (which is just not the same with electronic boards) which also contributes to a more relaxed stance to experimentation.

So – there are some good reasons to use an electronic board and even if you do use a physical board you still have to find a way to process the data electronically. But the power of a physical board, especially due to its limitations should never be underestimated.

Until next time
  Michael Mahlberg

Why “the iron triangle” (of project management) isn’t

Over and over, people quote the iron triangle of project management - relating verbatim to the elements time, scope and cost from the wikipedia article or by the slightly less formal adage “Cheap, Fast, Good – pick any two”.

Surprise: It is not a triangle

Anyone who looks closely at the concept – or just reads the first paragraph on wikipedia – quickly realizes that the “triangle” has at least a fourth side: quality!
(But the term “devil’s quadrangle” has not yet found it‘s way into wikipedia)

And as handy as the tool “iron triangle” may seem in arguments, it really should be used with caution. Especially arguing about the quality constraint is very common in my experience. By relating to the “pick any two” adage people try to argue that “with the new time constraints we have to compromise on quality.“ And apart from the fact that “quick and dirty is very un-agile” this approach completely ignores the fact that compromising on quality usually does not get the job done more quickly but generates severe issues for the ensuing product.
The agile answer to this conundrum is to negotiate on scope instead of quality. That is what most sane people would do with tangible objects as well. I might go with a motorcycle (smaller scope) when developing a car isn’t feasible under existing time and budget constraints. But I definitely would not go with a car where “somewhere between 20 and 40 percent of the nuts and bolts are not tightened correctly” (less quality).

To me it seems much more rewarding to manage scope than to try to compromise on quality.

till next time
  Michael Mahlberg

Triage may seem cruel, but it could save your product

Triage is a term from the battlefield. To be more specific from the battlefield mobile hospitals.

So triage should not have a place in the – comparatively peaceful – world of software development. Or should it?

Sometimes you can’t get them all

It’s all about the question of how to make the best use of your resources in times when the demand exceeds the resources.

The original idea behind triage was to categorize the wounded into three categories (as described more closely in the wikipedia article on triage)

• Those who are likely to live, regardless of what care they receive
• Those who are likely to die, regardless of what care they receive
• Those who would die if they did not receive immediate care but are likely to live if the do get immediate care

and then concentrate your resources on the category where your effort really makes a difference. In the original case this means to start with the third category – cruel though it may seem for the other two categories.

Over the course of time the rationale and theory behind triage have evolved immensely, as can be seen in the article. Both the ethics and the practical application have been refined, but the basic idea is stimm the same. Don’t waste your energy on “lost causes” when that would lead to loosing causes you have a chance of rescuing.

What’s that got to do with software development?

In our day to day work we’re often confronted with situations where the requirements exceed our capacity.

If we try to do everything, even if we dynamically reschedule according to priority, some things won’t get done. That is exactly what “requirements exceed capacity” means. And this is exactly where triage fit’s into the model. If only 4 of 11 requirements will “survive” make sure not to waste any effort on those, that will never see the light of day anyway. Put them in a separate “folder” and once you’ve got discretionary time on your hands revisit that folder and check which of the requirements would still provide value.

If we concentrate on the 4 most important requirements first – the amount we can expect to complete – we end up wit only 36% (4/11) of the requirements fulfilled, but the features for those four requirements can be shipped.

But it is never a good idea to try to fulfill all 11 requirements with only enough resources for 4 – we would end up with 11 requirements fulfilled to 36%. And because a feature that is only 36% complete in most cases is not shippable we would end up with zero deliverable features.

No, it does not mean you can skip tests or refactoring

So if we have to cut functionality can’t we go faster by skipping unit test, documentation or refactoring? That would be just silly – just as if the doctors in the battlefield hospital would omit washing their hands as Uncle Bob would probably remark. On the contrary. Applying triage on a requirement level should give you the time and space to work at your optimum on those requirements that can survive.

till next time
  Michael Mahlberg

Yes, you do need a “Dashboard” (a.k.a. Andon - Board)

And no, I don‘t like the terms “Project Dashboard”, “Lean Dashboard” or “Agile Dashboard”. I do like the concept of the andon-boards

But what is a(n agile) dashboard, and why do you need it?

Speed is nothing without control

Most lean and agile approaches include some kind of feedback mechanism to enable informed decisions. In Scrum for example some information is fed back into the loop in the sprint planning as the capacity for the next sprint. In flow based approaches the feedback is often build into the work organization. When a kanban approach to process control is in place it can at least be found in the capacity of the stations (a.k.a. WIP-Limits per column).

This may be enough for a while, but it is not enough for the long run.

How often is an autopilot ‘on course’?

Actually not much at all - if it would be possible to set the course once and then ‘just let go’ you wouldn’t need an autopilot. The main reason to have an autopilot is to counteract the little deviations off the course caused by internal or external disturbances. So the autopilot constantly correct to the target, but the target is only reached for very short periods of time.

You’ve got to know that you’re off course to make adjustments

To be able to auto-correct your course, you have to know wether you’re on or off course. And that is what a dashboard can tell you. By making the actual ‘course’ visible as early as possible. On a dashboard. That is updated as soon as the information is available. And this is where an automated dashboard can come in handy.

What should go on the dashboard?

Whatever you’re aiming for!

• You want to spend a certain amount of your capacity on a specific project? Then the actually spent time per project has to go on the dashboard.
  
• You want to increase the test coverage? Then the current test coverage has to be displayed.
  
• You want to spend at least x% of your time on improvements? Then the time spent on diferent types of work has to go on the dash.
• etc.

So, how do you navigate your project?

’till next time
  Michael Mahlberg

There are some situations where “agile” is the default mode...

Of course there are a lot of situations and places where agile approaches have become the default mode, and looking back at the history of software development with regard to iteratively-incemental approaches that is only a re-discovery anyway.

But in the big – a.k.a. Enterprise-Level – companies it’s mostly not the case. Or only in name but not in action.

Sometimes even “The Enterprise” goes into “agile”-mode

There is a situation when even Enterprise-Level software projects switch to an agile mindset. At least in most things but the name.

All of a sudden certain things start to happen:

• Business people re-prioritize on a regular basis (in short intervals even)
• Business people take the time to describe and verify the requirements
• Rollouts are allowed with very little overhead (sometomes called ‘hot-fixes’ in this context)
• Developers ask the people from whom the requirements actually came, what they want now
• etc.

Crisis-mode?

The situation I’m referring to is especially common for in-house-software that is developed for (and often in) large comapnies. Not all – only those projects that come into a crisis-mode phase at the end of the development phase.

I mean the time between the official end of the project and the time the software is actually in use. After the project has been declared finished, but before it is adopted for company wide use. When the last glitches are eliminated – which often takes up way more time than ‘planned’.
This crisis-mode is actually when everybody switches to things that work. And surprisingly these things are an interesting subset of what the agile manifesto mandates. (Of course I’m referring to the second page here)

Unfortunately some practices are not so important in crisis mode. Things like “sustainable pace” and “regular reflections” sometimes don’t seem so important in crisis-mode, but even the “continuous attention to technical excellence” is often more prevalent in crises-mode than in the day-to-day business during the run-time of the project.

So, here‘s an idea: If your enterprise shows the same crisis-mode behaviours, why not use this as a wedge to introduce more agile approaches?

’till next time
  Michael Mahlberg

Expensive Architecture Is No Architecture

Some musings on the value of architecture...
(This post is originally from 2007 but never has been published IIRC – and it's current as if i had written it today)

• Developers sometimes claim that “[this] architecture is to expensive”
• Recently several architects claimed that "[the] architecture has to be enforced because otherwise no one would pay the extra cost"
• It seems, that even some architects think that architecture leads to more cost than benefits
• From my point of view this attitude completely misses the point
• IMHO the "form follows function" mantra attributed to the Bauhaus is true for information systems as well
• An architecture that is motivated by the "right" goals it will pull more than its weight
• Architectural principles always should be a means to an end – and that end should b made explicit. They are meant to address real problems in systems development.
• The statement "It may be more expensive but it is what architecture demands" is a clear indication that either the scope of the observation is too narrow or – much more probable – the architecture is not an architecture but a bunch of rules far away from the real problems.

IMHO [as of 2015] the whole point of these musings is: If there is friction between development and architecture and the reason for this friction is that the architecture seems to be too expensive than that is an excellent opportunity to either re-evaluate the architecture (with real numbers and amounts and explicit assumptions) or to communicate the reasoning behind the architectural guidelines better.

And of course this is no one way road from architects to developers – it also sometimes pays off handsomely for development to make the incurred cost of architectural guidelines visible (of course also using real numbers and amounts and explicit assumptions)

So, how is your architecture? Does it pull it's weight?

’till next time
  Michael Mahlberg

Timeboxing and Zeno's paradox

Every now and again I run into arguments about the rigidity of time-box boundaries. Basically it goes like "But perhaps we could have finished what we wanted to do in 2 hours if we just gave it 5 minutes more. _Do we really want to discard 120 minutes worth of work just to save 5 minutes?"

You never have enough time

According to the best known of Zeno’s paradoxes Achilles (who was regarded to be the fastest runner of his time) will never be able to overtake a tortoise with a hundred step head start.
That is exactly the problem with the extension of time-boxes. Even if one would allow a maximum extension of 10% of the original time box to try to “finish it” it would likely still be unsatisfactory in the end.
Like the tortoise in the paradox (give wikipedia a short glance if you haven't already) the time “needed” for completion of the task would be extended an infinite number of times. However, after a couple of extensions, by infinitely small amounts. So in reality and for all practical purposes the timebox would last for 1,11111... times the time that was originally allotted. Which of course is a very specific time. 2 hours and 13 ⅓ Minutes if I am not mistaken.

So the point is definitely not to extend the timebox. It's got to be something diferent.

Parkinsons Law to the rescue?

As Cyril Northcote Parkinson stated in his famous law:

“work expands so as to fill the time available for its completion”

The funny thing is, that the opposite seems to be true as well: if there only is a fixed amount of time, as soon as people realize that it is really fixed, they tend to come up with something usable in that time, effectively applying “design to budget” approaches to things like meetings as well.

And – after people get accustomed to working in timeboxes – the results usually show up shortly before the time is up.

And if they don't sticking to the timebox will help you to plan more realistically the next time around. Just don't fool yourself with 2h timeboxes that tend to last for 2:15 ... ish ...

So – just stick to the timeboxes – use them to your advantage instead of fighting them! (And remember to size them realistically!)

till next time
  Michael Mahlberg

There is no such thing as a continuos integration server

Of course the title is reference to the “There is no such thing as a free lunch" adage, also known as TANSTAAFL, but really it is about the fact that people think they have the advantages of Continuous Integration when all they have is a build-server.
Of course this is just another instance of semantic diffusion, but IMHO there really is a huge opportunity wasted by not following the concept of continuous integration.

The original Continuous Integration

When I first came across the idea of continuous integration it was in the context of eXtreme Programming (XP). It was just a practice that required a lot of discipline, a finely tuned set of tests, a sound system architecture, capable developers and a good source code management system.

Low-tech is key

James Shore wrote a piece about “Continuous integration on a dollar a day” back in 2006, which in my regards still holds true even today.
The point here is in both cases – in the original description as well as in the James’ article –, that no task is done until it is incorporated in the “main development line” and it is shown that this main development line is proven to be as error-free as can be at that point in time. And the developer(s) who signed up for that task take it on as their responsibility to make it happen. To ensure that this is handled in an efficient way, integrations are serialized and don't happen concurrently. (James employs a nice token to ensure that)
Simple enough – not much technology needed.

Using this approach you end up with a product that always includes all the work completed at that point in time in a way that could be shipped or installed instantly.

That may sound nice in theory, but in our case...

• ... the tests run too long
• ... our tasks are so small, we would have way to much overhead
• ... out team is too big for that
• etc.

Fair points – let me address them one at a time:

The tests run too long?
That is a very good indicator to make your tests faster and perhaps more expressive. Or change your architecture in such a way that you have more, smaller, independently testable components.

The task are to small for that?
Create slghtly(!) bigger tasks

The team is too big for that?
Your team is too big. Period. Change that!

etc.?
If the CI-approach is not feasible because of «X» it is almost always a good indicator that you have a problem with «X» - even though the case of long running tests deserves a seperate discussion.

The Problem with CI-Servers

Don't get me wrong – I'm a big fan of automated builds and build servers. But my point ist that they just can't provide continuous integration.
being serious about continuous integration means you can never have a red build on the deliverable after a task is completed and integrated. After all making sure that the main line is “clean” is essential to the very definition of continuous integration.

The point of the original CI-concept is: As a developer your job is not done until the main line reflects your work

The point of the so-called ”CI-Servers“ is: “Just commit your current work an start on something new – I‘ll let you know some time in the future if the test still show that the software is okay or if there are any clashes with contributions from your co-workers.”

Therefore build-servers actually promote starting on new tasks before the seemingly finished tasks are completely integrated – that's exactly what they are made for...

And the problem gets worse if your tasks are small and the test are long-running... Then you end up with huge build queues that grow during the day and get cleared up at night. And it takes until the next morning until you get feedback on whether your code is really integrated with the system or you still have to do rework.

So yes, please use a build server – but only as a safety net. And don't call it continuous integration just because you have a server performing your build-runs and unit-tests for you.

’till next time
  Michael Mahlberg

5S – taking it too literally?

As an old saying in Object Oriented Analysis (OOA) goes “Naming is essential.” And while I was writing this series on the 5S approach over the last couple of weeks I felt increasingly uncomfortable with the Sort – Straighten – Shine – Standardize – Sustain canon of the English translations.

The 5S-approach works well for knowledge work ...

I actually took the words from the Wikipedia article to create the titles for my articles, but as you can see in the current list of links below I amended the titles with the translation from Hirano‘s book on implementing 5S in e.g. office environments.

• Sort (or organization)
• Straighten (or orderliness)
• Shine (or cleanliness)
• Standardize (or standardized cleanup)
• Sustain (or discipline)

To me these translations made a lot more sense in the context of knowledge work. And – to be honest – in the context of the original descriptions as well.

... but not so much with the ideas associated with the English S-Words

It is my feeling that while it is a nice touch to have the 5 Ss from 5S matched up with English words starting with ‘s’ (which definitely helps with memorizing them), there is a very high risk of semantic-diffusion through this.

There is a qualitative difference between organizing things and sorting them. Just like straightening things out is not the same as being orderly. And so forth.

In business process design, design thinking and software development we have a couple of approaches that are completely in line with the 5S approach – but it is hard to recognize that when the (English) S-words are used.

To take one thing from software development, “refactor mercilessly” is a way to keep the codebase organized and clean – keeping the codebase sorted and shiny doesn‘t make too much sense in that context.

There are more things – like naming things correctly, which not only fits in with cleanliness but also with orderliness and discipline. But the point I am trying to make is that the 5S approach provides much more applicable guidance when not taken literally by the s-words from the Wikipedia article, but instead by the older translations from Hirano et.al.

So how about giving the translations from Hirano‘s book a try for your next process improvement session? You do have process improvement sessions, don‘t you?

Till next time
  Michael Mahlberg

Sustain! The fifth S of the 5S

(Shitsuke, 躾, according to Wikipedia)

Whether you look at Hirano or the Wikipedia article on the 5S Approach, the last pillar or practice is the hardest Shitsuke, 躾 which the Wikipedia article translates as Sustain, while Hirano translates it as Discipline.

Let‘s once again have a look at the implementations that are listed in the Wikipedia article:

• To keep in working order
• Also translates to "meaning to do without being told"
• Perform regular audits

These factory related implementations seem to translate quite easily into practices that are also known from agile software development processes or the teachings of clean code development or pragmatic programming, but are they really?

To keep in working order for example can be nicely mapped to practices like continuous integration (the practice, not the tooling) or the "no broken window rule.
Performing regular audits is at the heart of almost every agile method – be it as a retrospective or as a operations review- (as long as you don‘t call it a post-mortem).

But in my opinion and experience this is only part of it. The hardest thing about this pillar is that it is about discipline. About cleaning up even if I already worked late. About sorting things even when there is time pressure. About removing the mess I created while working while the sun is shining and the waves are luring. Agreeing on standards even though everybody seems to do it "almost the same way".
About just really following through on the other four Ss.

And for me this is the most important yet hardest to master of the five "S".

Till next time
  Michael Mahlberg

Standardize! The fourth S of the 5S

Seiketsu, 清潔, according to Wikipedia

Other parts of this series

• Introduction to the “5S” philosophy
• The first ‘S’ – sort or organize
• The second ‘S’ – straighten or orderliness
• The third ‘S’ – shine or cleanliness
• this article

Standardize what?

Even though the Wikipedia-Entry refers to this practice as “Standardize!” I prefer – once again – Hirano‘s definition of this technique as “Standardized Cleanup” which makes it somewhat clearer, what the subject of the standardization is.

Wikipedia suggests things like the following for the workplace on the shop floor:

• Maintain high standards of housekeeping and workplace organization at all times
• Maintain cleanliness and orderliness
• Maintain everything in order and according to its standard.

Now, from my point of view, standardized cleanup blends in perfectly with the XP-practice of ubiquitous automation and the current state of software development tools, where it is quite easily possible to actually define standards in such a way, that the compliance with those standards can be enforced or even maintained automatically.

On a coding level there are numerous things to be standardized

• coding conventions
• checkin comments
• build procedures
• key-bindings (especially if you're doing pair-programming with changing pairs)
• Concepts to adhere to (e.g. SOLID and things like that)
• Line-Endings ... (even though that may seem trivial)

And a lot of those standards could be validated by means of the development tools and the source-code management tool (e.g. git-hooks or the hook-mechanisms available in other source code management systems.

But there is also a lot of things you could standardize on other levels...

• User Story formats
• Requirements descriptions
• The quality of acceptance criteria

What else would you standardize?

Till next time
  Michael Mahlberg

Shine! The third S of the 5S

(Seiso, 清掃, according to Wikipedia)

Other parts of this series

• Introduction to the “5S” philosophy
• The first ‘S’ – sort or organize
• The second ‘S’ – straighten or orderliness
• this article

Cleanliness or shine?

According to Hirano the third pillar is called “cleanliness”, a term which doesn't help very much in clarifying the implications for the knowledge-worker or software-development organization.

Let's have another look at the article from Wikipedia.

• Clean your workplace completely
• Use cleaning as inspection
• Prevent machinery and equipment deterioration
• Keep workplace safe and easy to work
• Can also be translated as "sweep"

Once again this seems easy – or at least obvious – when the workplace is a workbench, a car pit or any other environment where ‘real’ or physical dirt accumulates. But how do you attain cleanliness at the workplace of a knowledge-worker?

In my opinion, when your knowledge work involves computers, the sweeping might include:

• Checking the local working copy of your source code control system for orphaned files
• Removing temporary files
• Removing unused build and configuration files
• Deleting invalid contacts and obsolete phone numbers or addresses
• Or even such mundane tasks as running anti-virus software regularly
• Keeping you synced folders (e.g. Dropbox) synced
• Keeping Backups
• Removing unused branches in the source code control system

If your work also includes actual creation of code there usually is a lot of cleaning up to do at the end of a coding session. That cleaning up could include (but is not limited to) things like

• Removing duplications
• Removing experiments
• Removing trace and debug statements that are no longer needed
• Adding trace and debug statements for maintenance purposes

Even apart from work directly related to computers there is a lot of ‘sweeping’ possible:

• Re-evaluting your planned work (e.g. backlog grooming in many scrum-inspired environments) – weed out the stuff you don't need anymore
• Removing old versions of documents
• Removing outdated links from the documentation (e.g. Wiki-pages)

And so on – just get rid of stuff that doesn't add value any more or is outdated. Having superfluous ‘things’ usually confuses people more than it helps.

What are your suggestions for sweeping the workplace of knowledge-workers?

Till next time
  Michael Mahlberg

Straighten! The second S of the 5S

(Seiton, 整頓, according to Wikipedia)

I am still not convinced that it was a good idea to only use English words that start with an ‘s’ for all the pillars of the 5S-System in the Wikipedia (and some other) explanation of the concept.
According to Hirano, who wrote one of the defining books on 5S, the second pillar is called ‘orderliness’ which – in my opinion – is much easier to interpret for software development purposes.

Ideas from production (as quoted from Wikipedia)

• Arrange all necessary items in order so they can be easily picked for use
• Prevent loss and waste of time
• Make it easy to find and pick up necessary items
• Ensure first-come-first-serve basis
• Make (the) workflow smooth and easy
• Can also be translated as “set in order”

The difference between ‘sort’ and ‘straighten’ is very subtle - especially when we think about software-development or other knowledge work, but if we consider the alternative translations ‘organization’ and ‘orderliness’, the difference becomes much clearer in my opinion.

How to apply these ideas to software development

While ‘organization’ calls for the removal of unnecessary clutter (be it in your File-System, on your physical desktop, on your computer’s desktop or anywhere else) ‘orderliness’ goes a step further and requires us to set the things that are not unnecessary – one might say those items that are necessary – in a definitive, understandable, reproducible order.

Let‘s look at other options to bring more orderliness into software-development

One of the things I tend to see here is the “automate ruthlessly“ or “ubiquitous automation” concept. Or, as they put it in the old days:

• The first time you do something, you just do it manually.
• The second time you do something similar, you wince at the repetition, but you do it anyway.
• The third time you do something similar, you automate.

But just using the tools of the trade in a more orderly fashion can make a huge difference. Using tags to categorize files (if your file-system supports such a thing), using a defined pattern for file names (not only for source code) and generally not only weeding out stuff but also ordering your tools and material falls into this category.

As James O. Coplien quotes in the foreword to the clean code book there is the old American (?) saying of “A place for everything and everything in its place” which really captures the whole concept very well for me.

What I propose in addition to Cope‘s explanation of this concept (a piece of code should be where you expect to find it) is to apply this idea to everything related to the value chain – from the first idea to the end-user actually interacting with the capability of the system that represents this idea.

• Where do the requirements belong?
• Where do the acceptance criteria live?
• Where would I find the swahili language translation of the help-files
• Where is machine specific configuration information placed? And how about user specific configuration?
• and so on...

Now what would you propose to do in our day-to-day work to get our software-development more ‘orderly’?

Till next time
  Michael Mahlberg

Sort! The first S of the 5S ...

...(Seiri, 整理, according to Wikipedia)

When applying the 5S-Approach to software development it is important to not just take the Wikipedia definition verbatim, but to also look behind the scenes.

So what does "sort" mean in software development?

First of all – it is not "sort". [Hirano][hirano-95], who wrote one of the defining books on 5S, describes this pillar as "organization" - the verb, not the noun.

Ideas from production (quoted from Wikipedia)

• Remove unnecessary items and dispose of them properly
• Make work easier by eliminating obstacles
• Reduce chance of being disturbed with unnecessary items
• Prevent accumulation of unnecessary items
• Evaluate necessary items with regard to debt/cost/other factors.

When you think about it, this is very close to "decluttering your life" – but with a focus on the workplace. (you might want to look up “100 items or less”)

How to apply these ideas to software development

Does “organize” mean you have to have a clean desktop? Either the one on your computer or the one your keyboards is placed upon?
Does “organize” imply you should not have any personal items on your desk or walls?
Does “organize“ require you to not have old printouts of code on your desk?
No, No and... Yes! Actually it does mean that you don't have any old, obsolete printouts on your desk. This is where things are quite similar between the workplace in a factory and a workplace in knowledge-work – don't put too many things you don‘t actually need in your workplace. Neither in the physical workplace nor in the virtual workplace on your computer

• Are you constantly clicking on the same buttons? Buttons which don't actually add any value to your work? Eliminate those clicks.
• Is your computer‘s desktop cluttered with old shortcuts? Remove them! Or move them to a special folder where they don't interfere with the day-to-day work.
• Do you have all of the Microsoft products installed but only ever use one of them? Sort at least the icons so that the unused ones are out of the way.

Take the time to organize your personal workplace – it pays of in spades.

The same holds on the product level:

• Do you have hundreds of files, that don't serve any purpose any more? Just delete them! If you're not sure if it is safe to delete them this might be a good time to take a good look at your source-code management system...
• Do you have local copies of old versions of your source tree, so that you can look up certain things? Once again a good option to familiarize yourself with the source-code management system of your choice. And then delete those copies. (And while you‘re at it you might want to have a look at git to get some more leeway with respect to source-code management)
• Do you use google to look up how the functions of your programming-language, libraries and frameworks work? Try thinking about compiling the relevant information and making it accessible locally to avoid things like google driven architecture (German article).
• Do you have dozens of auxiliary (self-made) framworks and libraries? Try combining them while weeding out the unused and obsolete code.

I guess you get the drift – organizing your work in the software world can be tremendously helpful and certainly is a good starting point on the way to a streamlined lean and agile software development process, but of course it is not the only thing that’s necessary. But then again it is called ‘5S’, so there is more to come.

Till next time
  Michael Mahlberg