Jiri Lundak

Archive for the ‘Agile’ Category

Being Seriously Agile

In Agile, Agile Development, Uncategorized on March 17, 2017 at 1:59 pm


Picture above: Definition of the real Prussian measure of a cubit and a foot (found on the wall of the City Hall of Bad Langensalza in Germany)

Often in my work as ScrumMaster, coach and enterpreneur I come across people telling me, that they have their own brand of Agile. They somehow tweaked Scrum or Kanban or SAFe or LESS.

I get usually called to coach a team, to act as ScrumMaster to a team or to teach line and project management, what Agile means.

I often get asked about different techniques – how to structure meetings, how to synchronize teams, how to make the team perform, etc. But what surprises me again and again is, that I seldom get asked:

What does it take to be able to go into production after each and every Sprint or even continuously?

As this happens often to me, I come to the conclusion, that people more often than not are happy with “Cargo Cult” Agile. They follow all the ceremonies without ever arriving at the core of Agile, that is:

  1. Deliver production quality software after each and every Sprint.
  2. Talk to the customer and not just to some intermediary (yes, the product owner is often an intermediary!).
  3. Continuous improvement is key (and this is not about some fancy or funny technique to solicit the thoughts of the team).

And just one thought about scaling agility to the enterprise:

  1. It is not about scaling agility up, but it is about scaling work down to manageable sizes.

You might not be able to satisfy these imperative points of being agile at the moment. But you can certainly try. And do not settle for any goal below this ideal.

And now move the world!

Courageously “Kicking Dead Weight”

In Agile, Leadership, Scrum Agile, Team, Values on March 31, 2013 at 2:22 am

This is the first installment of a small series on trimming away fat, that inhibits organizations in realizing full potential, when trying to adopt Agile ways.

First let me make one thing clear: this is also about one value, that often seems to fall by the wayside. I am talking about courage. People tend to minimize the impact agility has on their organization. This is a natural reaction, because we have all the inclination to self-protect, our position, our job, etc. On the other hand we – as Agile change agents – want to maximize the impact of agility in the organization. So, to take action, we must go against our natural inclination. And this is really hard… but usually worth the effort.

“Kicking dead weight” or getting rid of processes, ceremonies, activities and even people, that do not contribute to our goals, is very hard to do, but extremely necessary. It might even be very urgent in your project.

Years of experience show me, that many organizations (especially larger ones) have lost control of their appetite (for “resources”, for regulation and for simultaneously ongoing projects). How comes?

They take on more projects than they can handle. They add external people, because they have not enough themselves. They are not able to control this much people, so they add rules. They have not enough people that check compliance with the rules, so they add more people, making projects heavier and more complex. Then the cycle starts again.

Once people are hired, processes are installed and rules are established, getting rid of them is seen as daunting at best and impossible in all other cases. Why is this so hard? Because many people contribute to the problem (sometimes unknowingly) and only few, if any, try to solve it. Many people joining the company just take existing rules and behaviors as unchangeable company policy and have usually not the courage and/or time to act on it.

Now, let us focus on the people problem. How can we get on top of it?

Here are some basic principles, that come to mind:

  • Think twice about who you hire: First think “Do we really need to fill that position?”, then “Can we just shift forces internally?”, and if you really need to hire somebody “Has this person really the skills to help us?”. Choose wisely with highest possible standards. Put candidates to the test. Do not just let HR decide. Make your teams choose the people they want to work with.
  • If possible, never hire external people: If possible to not overcommit in the number of project you staff can handle. When hiring external experts, you often end up devaluating your own people. The simply do not get any chance to build up new skills. This is a death spiral, leading to even more dependency on exteral help. And what is worse, you even loose the ability to judge the goodness of the external people's work.
  • If you have to hire external experts: Do not create a Troian horse, where the providing company can send you anybody they like. Treat external people like your internal ones. Evaluate them with the same rigour and diligence as you would when hiring for a top notch permanent position. When hiring them, do it only for a limited period of time. Make it paramount, that they teach your own people how to do the job well. It is better to give the complete project outside or buying an off-the-shelf product, than having a pseudo-internal project.
  • People just do not cut it: If you have people on your team, that do not solve problems, but – on the contrary – often contribute to create them, then do not hesitate to try to help them. If they live not up to the chance, remove them. How do you know someone, who does not contribute? If you collaborate closely with your team, you will know. Else ask the team. They know the good people. External people, that are of no help, should be immediately removed.

I know this might sound hard, but it is the only way to improve things. But remember: it takes courage. You need courage to go counter useless policies within you company. You need courage to face a person, that you need to correct or even remove.

In the next installment we will talk about trimming processes.


Are We Following Agility Blindly?

In Agile, Collaboration, Management, Values on November 14, 2012 at 1:22 am

Are we a swarm of agile fanatics, that do think in an undifferentiated way to have found the silver bullet for producing good software? Are we a bunch of people so convinced of ourselves, that we meet persons (like middle managers, bosses, CEOs or simple colleagues) thinking differently, with indifference at best and arrogance at worst?

Recently I was pointed to read the following article in the renowned German newspaper “Die Zeit”: “Der Sog der Masse”. The article (titled something like “The Pull of the Masses”, sorry for the imperfect translation – no native English speaker here), tries to discuss the power of mainstream thinking, where the big mass of people follows a quite small number of articulate people, that voice loudly a particular (but many times false) opinion.

Discussing the article was interesting. It was cited to indicate to a small group of people – that where voicing concern, that the company they were working for, was becoming less “Agile” -, that these people were speaking up, not because they were convinced of Agile values, but because they where following a small group of articulate spokespersons, without reflecting on their own.

Hmm…this happening makes me think.

Do we as proponents of the Agile community communicate well? Do we sell our noble goal – to give customers what they really need and delight them – really well?

We perceive ourselves as fighting against the mainstream of how software is developed and how work is managed. We are not mainstream yet, because many companies do not do Agile, although they say they do. At the same time there are companies that do Agile for quite a long time, but where people entering the organization perceive the existing culture to be “the mainstream”. When new managers want to bring in new (but old) practices, that the Agile community abandoned some 10 years ago, they feel like a new minority, with a fresh “new” perspective. They feel the need to challenge the existing thinking.

Is this bad? I do not think so. I always perceived the Agile community, and also most of its members, as open to “new” challenging thinking. But does this mean one should jump ship at first sign of contrasting thought? Not really. Having a conviction and standing in for a set of common values is not per se bad.

The main problem lies, as many times, in communication. As we know communication is always multidirectional. Whole books have been written on the subject. But one of the main hindrances I observed these days first hand, is the absence of deep listening, on both sides – the so-called “mainstream” and the “challengers”.

Following things hinder deep listening (and thus understanding):

  • Missing appreciation for all people.
  • Egocentricity (being focused on own goals).
  • Underestimation of people's value system.
  • Fixation on preconceived “solutions” and own worldview.

We from the Agile community should not fall prey to these kinds of hindrances for good communication. This would go counter our own values and quickly give us a bad rap.

I know we are mostly not following agility blindly. Let not people have the impression, though!

On Project Transparency

In Agile, Collaboration, Personal Development, Values on May 15, 2012 at 11:52 pm

One of the main agile values is “transparency”.

We expect it of teams, when it comes to reporting progress. We expect the individual developer to be transparent, when he is doing his work. We are selling Agile as a means to know where a project really stands.

And this very good! Why? Because it helps build trust.

But do we just build trust in case of success, when we meet our sprint goals, when we deliver a system into production or when our estimates match the actual effort? Often managers and business owners think so. But this assumption is down right wrong.

Just ask yourself: “Whom do I trust more?”

  1. A person, that has made an error and admits it.
  2. A person, that has made an error and tries to cover or downplay it.

But you may counter: “But if I do not want to stir up unnecessary controversy? I know the project is still on track. This was just a small miss hap.”.

Think again: What happens, if the customer somehow gets to know, that you tried to cover your failure or you just deliberately decided to let him take the backseat on an other customer?

Will you gain his trust or loose it? You are right, the first outcome – in this case – is no option.

Sure you might end up justifying your dubious choice or bad performance, and this might even trigger more than necessary attention on the customers’ side for the project. You have maybe more work and a hard time. But who is really to blame?

Some people like to blame others, especially when there are other parties they might depend on. But do you not think, that many customers are fed up with nobody taking responsibility for problems in projects? What about breaking the blame game and just explain to the customer, what led to the problem and what you intend to do to correct things, so that the project gets back on track?

Would you gain posture and trust doing so?

I know, somebody will come and try to convince you, that you can not – in this particular situation – tell the whole truth. “You need to learn to play the political game.”, he will tell you. He might even offer to “coach” you on this. “You need just to tweak your messages according to its receiver.”, she will say.

Think again? Can you keep track of what you said to whom and when? Does it become easier in a more complicated project with many parties with differing interests and stakes at risk? How does just saying the truth and explaining the situation stack up against this?

But what can I do, when I am in a tricky situation?

You have just two options (none of them is without problems, I must admit):

  1. Continue to tell the truth, and nothing but the truth: You will run into trouble with people, that do not like it or have different opinions (partner companies, your boss, your company owner, your sales department or even your customer). But you will be nonetheless be seen as trustworthy and congruent. Depending on your company culture, you will be allowed to continue your work backed by your colleagues or – in case of a negative outcome- it might be time to get out of the way. But at least you remained true to your deepest values. And it might even happen, that you are able to build a long-standing, strong tie of trust with your customer, which might lead to other projects being entrusted to your organization.
  2. Participate in the political blame game: Get entangled in the political mess, that many big projects are. Bend the truth to fit what the stakeholders in your company, in the customers’ organization or of some third party, want to hear. You might get away with it, because other participants in the political game, are bending the truth even more and many people, interested in hearing the truth, just do not have the means of recognizing it. Yes, you might be successful with your project. But what you can loose is much more significant: your credibility with colleagues and customers alike will suffer. Worse, you might get used to bending the truth. But it will not work on every project. So get used to the idea of being exposed sooner or later. And a reputation once ruined…

“But I am part of a larger corporation. Bending the truth is normal affairs around here. If you do not play along, you’re toast!”, you might say.

That is true. Honesty does not always pay dividends immediately and in all organzations. And there are certain places you just do not want to work at, if you want to maintain a morally sustainable position. And face it: there are some companies out there actually appreciating transparent, honest employees.


…And Should We Keep In Mind

In Agile, Agile Development, Scrum, Scrum Agile on May 4, 2012 at 12:50 am

That we always start from different positions and situations in any one organization.

That my organization (team) is not your organization (team).

That sheer size makes things complicated and long-winding.

That – because of entropy – things tend to fall apart.

That boundaries are fuzzy and thus changes come along leaky and not clear cut.

That small changes can have huge impact.

That a bigger and divers toolset available to you, gives you more leverage to cause or to react to change.

I totally agree with Ron Jeffries, when he states:

“Agile, Scrum, XP, Kanban, Lean: the same elephant, different points of view.”

And I would add:

“…and you can make it dance or pull tree trunks, just not at the same time.”

Because context is needed to choose your tools wisely. And as with software engineering ability: the more you practice using your tools and the better you master them, the more you are able to apply them, when need arises. And the more varied your toolset, the more possibilities of intervention you have.

What ways to you know that could improve the situation and in which context where you successful?

Putting the “Engineering” Back into Software Enginering

In ACCU 2012, Agile, Agile Development, Architecture, Design on April 25, 2012 at 12:01 pm

Yesterday I attended a whole day pre-conference tutorial with the late Tom Gilb titled “Advanced IT Design and Architecture” at ACCU 2012 in Oxford, UK. As Tom pointed out, he would have preferred to give the two-day version, because of the sheer mass of material covered (including lots of material to study at home, including an electronic copy of his book “Competitive Engineering“, that does not fit on a memory stick under 1GB).

His basic message was, that “real architecture” needs quantified requirements, derived from concrete stakeholder needs, as its foundation. These must allow to be numerically evaluated to help drive making informed design decisions.

He presented some simple tools that help in the process:

  • A formal specification language named “Planguage”, to be able to arrive, using decomposition, starting from unquantifiable ambitions for any particular needed quality, like “data consistency”, at quantifiable requirements (each with its own numerical scale), for which a current baseline value is stated and “tolerable” or “wished for” goals are defined.
  • Design Impact Estimation: a structured way at trying to come up with a matrix of weighted (sometimes partial and even complementary) design strategies, to help with the choice and prioritization of the alternative(s).
  • Evo: an Agile process that allows to get early feedback on design attributes, before scaling up and committing to a certain design.

During the day Tom multiple times attacked the Agile community as being ignorant to the fact, that design and architecture are fundamentally important to a successful project. He illustrated his point with some example from failed “Agile” projects.

As a long-standing proponent of Agile software development myself, I feel obliged to reflect on the state of affairs and to respond.

The Relationship Between Agile and Architecture

Here are some articles (pointing partially themselves to further articles) that tried to highlight the relationship between Agile methods and architecture:

Sure enough you will find other articles as well, many of which are part of the IEEE electronic library.

In the Agile community we have in practice a very ambiguous relationship with architecture. There seem to be people and organizations, as observed by Tom, that use the notion of “no big design up front (no BDUF)” as an excuse to do no architectural or design activities whatsoever. I challenge, that these individuals or groups of people, would not architect and design their applications properly, even when applying traditional processes. As Tom also stated, most of so-called “architects” today just throw acronyms at you, without ever working like engineers.

So this is not a problem of Agile, but of human nature. The only allegation one can make to the Agile movement is, that it does not properly address this issue with a set of good principles and recommended practices, that are as easy to apply as possible, but at the same time as rigorous as necessary. What happened with automated testing (unit testing, TDD, BDD, ATDD, etc.), that it spread like wildfire, even to non-agile organizations, should also happen with good architecture practices.

The Missing Link

People trying to write good software that has real business value to the customer, will do whatever is necessary, to deliver it. In an Agile environment, they will try to architect and design (in the sense Tom uses the words), as much, as is absolutely necessary, and not more. Recognizing, that a system will need to respond to 300'000 user requests per second is not unnessecary information for an Agile development organization. When I know this in advance, it is wise to choose my design alternatives accordingly, because knowing this essential requirement limits my solution space.

As I perceived it, Tom did not propagate the one and for all cases perfect BDUF, but he installed something more important: a toolset that can be used to define and measure non-functional requirements, that affect our systems architecture. This does not preclude or even prescribe any particular design solution, but gives us a way to validate, how good our chosen design satisfies these requirements, something that goes often forgotten in an software engineering effort, be it Agile or not.

Where to go from here?

To make the adoption of quantitatively measurable non-functional requirements more probable and sustainable, we need to be able to make measurement (whereever possible) automated and iterative, so that changes in requirements are recognized and taken care of and changes in the architecture and design of our systems (especially if they have more of a product character) can be measured against the fulfillment of the stakeholders' expectations.

There is still some serious work to be done here.


Interesting Thoughts About Architectural Evolution

In Agile, Architecture on July 9, 2007 at 2:28 am

Tom Ayerst, whom I met when becoming a Certified ScrumMaster in Vienna in 2004, writes here some interesting notes about architecture evolution, like:

“What does this mean? The ideal architecture is as described above simple, and focused, it should also be balanced and not restrict you from taking it in any a particular direction. This last desirable trait is invisible, you don’t know you cannot go in a particular direction until you try to go there.”


“Over time your architecture will become less balanced and amenable to change. Getting the balance back will probably require an architectural review of some kind and some kind of more disruptive change than another simple refactoring.”

I think he is quite right. I can observe this with our own application framework we use at work. No simple refactoring will do. After multiple refactoring sessions done often as a pair, we are still trying to bring the architecture back on track. It all depends on how far away you already are from the ideal line.

Scrum Talk at Event for Swiss FDJP Project Managers

In Agile, Scrum on June 26, 2007 at 5:01 pm

I will be giving a talk about our experience with Scrum in a large project at an event of the Swiss Federal Department of Justice and Police on June, 28th.

Here the slides (in German) in Powerpoint format: Scrum in der Praxis (Powerpoint).

And as PDF: Scrum in der Praxis (PDF).

The 3 Axes of Agile Architecture

In Agile, Architecture, Programming on April 30, 2007 at 11:10 pm

When thinking about my last post today, I was not quite satisfied with it. The values seamed quite unfocused to me in hindsight.

Actually I think we need to condense – especially the values – some more, so that we get at the essence of the agile spirit we need to be able to measure a good architecture against it.

In the end I think it boils down to the following three axes, along which an architecture (maybe embodied by a framework) can be judged (see the figure below).

Agile Software Architecture Principles

I would contend, that an architecture satisfying all three of the axes is THE agile architectural basis for software development that is able to deliver on the agile promise.

Let us have a deeper look at the individual axes:


This axis focuses on embracing change. For an architecture to support this, it needs to be easily modifiable, extendable, refactorable. If it is hard to change, it will lead – over the long run – to clumsy code, horrible work-arounds, lots of glue code and very extensive documentation, that needs to explain all of its quirks and potholes.

If it is easy to change and the developer is free to change his application at will, without too much effort, without breaking existing functionality of his application, then the overall design of the architecture (and the framework eventually embodying it), will remain simple, clean and easy to grasp over quite a long period of time (good tending practice implied).


Agility has one of its foundations in the delivery of production quality code on from iteration 1 to whatever number of iterations a project takes to complete. As such an application developed in agile manner needs a foundation, that has quality build right into it. This kind of architecture makes it hard for the average developer to make stupid mistakes.

It simple does not allow to circumvent good coding practices. It allows freedom of interpretation only in dimensions, that are in the application domain. It helps the developer to test his code in an easy, dare I say fun fashion, so that he wonders, how he could ever live without the safety net he is constantly weaving.


Though I mention this axis at the end of this text, it is the focal point of agile software development. When we do not produce the right thing, it is of no use to produce it as fast as possible with the highest possible quality.

That said, it is crucial to produce value for the customer. The architecture should not stand in the developer’s way to produce some useful application. It should encourage him to produce value out of the box, to be able to show his customer a thin, but fully working, slice of the final product he will get.

At the same time it should prove to be a tool in the developers hands, that allows to try out easily alternatives, that can be quickly transformed into a visible artifact to put in the hands of the customer, so that fast feedback can be harvested, which eventually flows back into the development cycle.

Complementary products like acceptance testing support and generic self-documentation should help to produce value faster.


To produce an architecture (embodied in a application framework) that supports these essential values, may not be easy, but at least this is a starting point to think more deeply about principles that support this value-system.

As a nice side-effect I now have a system, that allows me to have a look at existing application development framework and weight them against each other. But I will spare this for another post.

Agile Software Architecture Principles

In Agile, Architecture, Programming on April 30, 2007 at 1:30 am

It is not a secret that I am fond of Agile software developement. I have published multiple articles over the last few month on pitfalls with Agile implementation and I am even writing a book about it.

But in my chest there still beats a heart of an architect and developer. As such I would like to see still better tools, frameworks and development practices. Last friday I was the last standing man at our company, with a colleague of mine and we were fantasising about our personal take on a lean, mean application development framework. We found quite a common ground, when it came to our dislikes with the existing way to develop software in the Java world.

It is always easier to articulate your dislikes, instead of reflecting on the values and principles, that you would like to see flourish.

So what we dislike about existing frameworks boils down to the following short list:

  • Configuration in monstruous XML configuration files
  • The jungle of XML WebServices as the SOA silver bullet for all application integration
  • Way too much code generation in the past
  • Although we are fond of metadata to be leveraged in applications, we dislike too much annotations (obscuring further how things work)
  • Writing still applications for the single VM, not using the power of many distributed ressources
  • Frameworks, that grow to such giant dimensions, that you have to install a 60 MB package, of which you use only 1% in your application
  • Frameworks, that want to be everybody’s darling, by including hunderts of alternatives (we integrate anything) for each module and for this sacrifices ease of use and efficiency in programming
  • Generation of boiler-plate code seen as THE holy grail in increasing productivity

When going through these points in retrospect, I would like to synthesize some values and principles, that I would like to see in a framework, that really helps me concentrate on giving a customer what he needs, without much of the grieveance included, when using today’s breed of tools.

Here are the values I would like to see embodied by an ideal framework:

  • Efficiency
  • Purity
  • Easy Modifiability
  • Expressiveness
  • Openness

These should be support by principles the framework should enforce and follow:

  • Ease of use
  • Transparency
  • Scalability
  • Maintainability
  • Testability

There is some tendency towards easing the pain of development with the advent some of the newer frameworks for web development, maybe started by the hype surrounding Ruby on Rail. Other new frameworks, that fit in this category are SEAM and Grails.

While these frameworks tend to point into the direction I would like to imagine, they are still not there, yet. Too much boiler-plate code, sometimes too much XML. And if all else fails: I could still argue, that they are not Java frameworks! 😉

I just would like to take the Agile thought to the extreme and make it as easy as possible (in Java) to implement and maintain an enterprise-ready application. “I know I’m a dreamer…but I’m not the only one”, to speak with Lennons words.

But who knows, out of idealism, sometimes something new and revolutionary can emerge. Let’s get surprised.

Technorati : , ,
Del.icio.us : , ,
Ice Rocket : , ,