Jiri Lundak

Archive for the ‘Agile Development’ 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!

Knowing when to Leave

In Agile Development, Career, Job, Team, Values on January 23, 2013 at 1:02 am

It was a long time with the same company. I nearly became part of the inventory. It was an awesome journey from a disorganized bunch of people, with no real concept on how to produce good quality software, that preferred to depend on external knowledge for managing projects, to a lean and mean software company, that produces 17 releases a year and had more than 135 releases go live during these 9 years.

We made a dent in the universe, for how long it lasted. We introduced Agile development practices and looked for talented people to join us. Self-directed people, good collaborators and able software engineers. We were trying to hire only the best of candidates (we hired only every tenth maybe).

This saved the company from failing. We were successful again.

And now I am leaving. Why that? It is not because of bad technological choices, it is not because of bad customer relationships and it is not because of a hostile business environment. These are problems of daily business life. We can cope with that.

The discussions of the last month have worn me down. I was not able to convince my peers, that we were drifting away from values we all valued.

So here we are. Our people were breathing the spirit of agility. They embodied self-organizing principles. They valued to be included in the decision making process. Sure not everything was rosy. But we never shied back from correcting ourselves. Unfortunately I was not able to counter the building up of positions, of creeping distrust. Though I tried to improve things I miserably failed.

But now there is hope again. People are talking again with each other, about their values, their hopes and their expectations for a better future. That is a good sign. But I am not part of the solution anymore and this makes me very sad.

In this dark personal moment, there remains one wonderful and encouraging thing deeply impressed in my memory: the pure and genuine solidarity with Agile principles, that most of my colleagues have shown, by underlining the value and positive effect the Agile way of doing things had in their lives.

Especially one colleague brought me joy and encouragement. We never talked personally about agility and its benefits in depth, he always seamed not to care much, just doing his thing, taking never any sides in 12 years. And now this… a long email, showing his personal benefits he got from the Agile way and how much he cared. This was very moving for me personally. Agile has reached the hearts and minds of people living it from day to day. This I call a movement!

So now, that I must go, I leave behind people, who for themselves have seen the light, who know what they want and know how to take care of themselves. So my wish goes out to them: be courageous, do not give in and continue to do good work! You know who you are.


…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.


Recruiting People With Agile Potential

In Agile, Agile Development, Scrum, Scrum Agile on March 9, 2007 at 11:48 pm

We are currently in need of new developers and testers for our teams. As we try to live Scrum as an Agile development process I often ask myself, what kind of criteria we should expect of the candidates, besides the usual developer or tester skills.

Sure you can not see inside the cadidates’ mind. But more and more we try to ask Agile questions during the interview. Often I ask a question, that I hope will show the candidate’s attitude towards Agile practices and values and to see whether he would have the potential to lead other people by giving them a strong example.

One such question was recently: “The build fails. What will you do?”. The usual answer I get is: “I will fix the build.”. Then I add the tweak. “But, if your code did not break the build?”. Often people then revert back to the ‘I am not responsible for THIS!’ attitude, so they say “I wait till the build is fixed by the developer who broke it.”. The better one’s will propose: “I contact the developer that broke the build and we resolve the problem together as soon as possible.”. As I often see people not acting pro-actively, but in the ‘wait and see’ manner, I hope to get more people on board, that act on problems, instead of tending only their own garden.

Another question I recently asked a potential senior developer and team lead was: “Your team seams not to be able to deliver the functionality they commited to at the beginning of the sprint, because of quality problems. Your demo with the customer at the end of the sprint is to be compromised. What do you do?”. One answer to this question was: “I go to the customer and postpone the demo.”. Boing, a warning sign! Further questioning revealed, that this candidate did not even know what a commitment within an iteration was and how it worked.

Another small test I do with candidates is to refactor a piece of bad code with them in a pair programming fashion. I am not so much interested in solving the particular problem at hand, but in the way the person approaches the problem, how she thinks about the code and how she works herself through to understand it. Does she write a unit test first to frame the working code? Does she rename variables and classes to have a better grasp of what the code is doing?

To people previously not exposed to Agile development I first explain our development approach (Scrum) and then try to ask practical a question on consequences this has on the interaction between team members or between developers and the customer (product owner). Their answers usually reveal a good deal about themselves. How they think about the development process, what they would like to happen in a development process, etc. The additional question I then add is: “What would YOU do to improve the process?”. So I try to at least see how their attitude is concerning the development process. How do they want to live their lives as software developers? Do they think about improving something, they see, is going wrong?

What are your questions you come up with to check for job candidates’ compatibility with Agile values? Let me know about it.

Technorati :
Del.icio.us :

A Different Team Event

In Agile Development, Team on February 11, 2007 at 3:02 am

Sometimes you make a move out of desperation…and it makes a whole lot of difference.
No not in the spectacular way, as to save the world or make enemies become friends. But I think it still can make a difference by altering the collective and individual perception a bit.

Well you do not understand what I am talking about? So I have to begin from the start. Here is the story:

About six weeks ago a colleague of mine and myself were quite depressed. It seamed as if we – as a development team (togther with our other 20 or so developers and testers) – did not make any progress, when it comes to the quality of our code. Sometimes we just do not get it as developers. We write code, without thinking too much about it. Or we concentrate so much on the solution to our software problem at hand, that we forget about good design, refactoring, test-first development and any other good coding practice.

Even organizing inhouse workshops with well-known patterns guru’s as Peter Sommerland (of Pattern-Oriented Software Architecture: A System of Patterns fame), did not contribute to more awareness about bad code and how to avoid it. Instead in these workshops (although organized as interactively as possible), some people always were passive, maybe even thinking: “What a waste of time! I need to do some important work and we are wasting it here…”.

So as already said, we were heavily depressed. While contemplating the situation an idea sprang to my mind: We would make everybody do something. As many of us as possible should become involved. We decided to organize an event: Done by us developers, for us developers.

Löpa Häck Näit Flyer

Invited were all developers and testers (people having to do directly with our code) to participate in what we declared to be the first ‘Löpa Häck Näit’ (in Swiss-German meaning the first Löpa Hack Night, Löpa being the short name of our small sofware company Löwenfels Partner AG in Lucerne, Switzerland).

We would start at 6 pm with a snack and then hack away until 4 am in the morning. We had 16 people participate. We formed four teams, all in one ‘War Room‘ and would do a coding competition. At 22 pm we would have dinner (one of our colleagues and his wife cared for), then we would see a geeky film together, before continue coding. In the end one additional discipline was to participate in a game competition with the new WII console until 5 am in the morning. On a side-track we organized some music and two girls from the nearby Lucerne School of Arts and Design to paint a big wall sized Löpa Häck Näit Grafitto on an office wall incorporating ideas of many of the team members.

First I was quite sceptic about the outcome of the event. I expected some people to rebell against the idea. But having some of the more critic people on the organizing comitee helped a lot. From what I can say now, two days after the event, it was a full success. And something has build up I would call team spirit. We had made teams with people that did not know themselves this well, because they usually (in daily life) worked in different teams. But the teams were quite balanced and so the competition was really working out.

It was the first time we worked really in an Agile way, all people working together on the same problem at once. We worked on two problems we had in our real projects: How to write unit tests to check for equality of PDF documents and how to optimize PDF rendering speed at least by a factor of two.

Incredibly enough we were able to do better than we expected. Although the first problem – testing for equality of PDF documents – to prevent alterations, when refactoring for speed, proved to be more difficult to resolve, we all learned a lot about the PDF-format than we ever imagined to know. Interesting in this part of the competition was also to observe, that many team-members were happy to exchange ideas even with the competing teams. In the end we managed to find an approach (with the help of our PDF expert Beat) to write repeatable tests.

The second problem – optimizing the existing code for speed – proved also interesting. All four teams managed not only to double rendering speed, but all managed to increase it by at least 60 percent. The best team topped at 65 percent. When I think that we need to render about 100’000 documents a night, I would say we did very well (and all in about two and a half hours!).

I just heard that evening one voice say, that this was not the most efficient way to use our resources. But I thing that person was wrong. We should work like that all day long. What was our net profit of this night? I would say for myself:

  • Better teamwork
  • Better understanding of a forgein domain for many team members
  • Knowledge transfer between people with different skills
  • Solutions to two hairy problems, we were grappling with
  • Code that was tested and worked (with only some minor rework the other day)
  • Self-organization
  • Reaching of a common goal

…and besides all this: Lots of fun!

I am looking forward to the next Löpa Häck Näit!

The Under-Rated Product Owner Role

In Agile Development, Scrum on December 15, 2006 at 7:30 pm

The role of the so-called Product Owner is in Scrum maybe the most under-rated role. I believe that the main reason for this is, that most implementations of Scrum are driven by people with a software development background, like myself. So most of us put very much weight on the ScrumMaster role, as we believe that he is the most important person for a Scrum team. Does he not remove impediments and keep the Agile process moving?

During the last Scrum Gathering in Minneapolis, we had an Open Space session on how to empower the Product Owner. While we were thinking about the value, principles and practices, that should should be kept in sight, when working with a Product Owner, it came to me, that the Product Owner must be by far the most important person for a Scrum team. And here is why:

  • He is responsible for the success of the project the team delivers.
  • He has to make business decisions, about what is important to him and how much it is important in comparison to other requirements he may have.
  • He provides the vision about the product for the team.
  • He provides the team with user stories and needs deep domain knowledge to do that.
  • He has prime responsibility to validate the deliverables the team produces. Do they meet his quality requirements. Are all conditions of satisfaction met?
  • He has to provide timely feedback to the development team, when questions arise.
  • He has to be able to make decisions on the spot, to resolve questions on how to proceed.
  • He needs to be in constant communication with the team and other stakeholder or project sponsors
  • He has to keep the financial situation of the project under close scrutiny.

With such a huge amount of responsibility and other qualities he needs, it is by no means surprising, that it is this difficult, to find an ideal Product Owner. I strongly believe, that there is no perfect Product Owner out there bringing all to the table, that is needed.

Because of this shortcoming and the importance of the role, we as the Scrum community need to focus more on the Product Owner role, providing a platform for the ongoing education of our Product Owners. I think we now really begin to focus on what is needed. Whether it is enough to provide a Certified Product Owner training? This short training can be an initial step. But much more needs to be done. But what? I will try to answer that question in an upcoming blog entry.

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