Jiri Lundak

Archive for the ‘Scrum’ Category

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

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

Low Scrum Adoption Rate in German-speaking world?

In Agile, Scrum on April 30, 2007 at 12:45 am

A week ago I was presenting a session at the JAX conference’s Agile Day, hosted by Jutta Eckstein. Exceptional was the interest people have in Agile software development. First it was thought that only about 100 people would attend the Agile track, instead 280 showed up, showing the increased awareness.

Quite contrary to this only a few people (about 10) raised their hand, when asked who was already using Scrum. But even more surprising to me was the fact, that only about another 10 or so signaled their interest to use Scrum in the near future, when I asked them.

I think, that there is still a lot of potential to educate people to use Agile in their work. But how can we lower the entry barrier? During lunch I was talking to a group of people, that had their reservation about what to expect from Agile development. They mentioned the thought, that what was needed to provide would be some week long immersion workshop, to experience the benefits, for one’s own work.

Maybe this is missing, especially in the German-speaking part of the world.


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

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 :

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 : , , ,