Today at Iltam meeting, I shared my personal experience in using a development process based on Extreme Programming. For all of you which are interested the slides (Prezi) can be found here.
I also would like to take a moment and thank Moshe Salem and Shlomit Morad for inviting us once again to give this session.
And last I want to remind you that next week we will be having the 9th meeting of the Agile Practitioners group. in this session Ayende will share his experience and his wisdom in writing automated tests. to register to the meeting go here
Want to adopt Agile and don’t know where to start?
click here to learn
on Sunday 1/7 Iltam is going to conduct an interesting meeting that will cover some very interesting agile subject. Specifically what I really like about this meeting that after a very long time I see some content that will mention my old and favorite Extreme Programming process. For some reason the XP methodology is no longer discussed in the Israeli community.
Anyways, there will be three parts to this session in the first part my partner Elad Sofer is going to talk about agile tools, Afterwards Danko will do a scan of various process models which are bundled under the Agile umbrella and I will do the last part in which ill talk about the experience I had in managing an R&D group using the XP process, if you are interested the complete details can be found Here.
hope to see you there.
Want to adopt Agile and don’t know where to start?
click here to learn
Posted in: Events
As a prequel to the first Agile Practitioners IL group meeting (register here). Jurgen Appleo has kindly offered to give a short, one hour, session during his visit next week. I know this is a very short notice but knowing Jurgen, I’m sure it be worth while.
The event is limited in space so for further details and registration go here. And don’t forget that we would still like to see you all at the first formal group kick off meeting.
Last month I spoke at “QA & Development in Agile” gathering. SELA were kind enough to video my talk and to make it avail;able online.
Details about the talk (with the actual slides) can be found here.
and if you want to tune in and listen to the actual talk (about 30 minutes in Hebrew) you can do it here.
Also I would appreciate any feedback you can share. So feel free to add your comments.
I‘ve been wanting for quite some time now to setup a monthly meeting for people 
This session subject will be "Feedback". We will have Elad Sofer (which is also a co-founder of this group) talk about "Feedback - The secret ingredient of success", why feedback is so important for success and how it is used Since this is our first meeting we shall also try to gather feedback from participants on what else they would like to hear, and how they would like to see this monthly meeting evolve.
If you want to get involved, please RSVP at http://www.eventbrite.com/event/1774314021
Gathering starts at 17:30
You can join the Agile Practitioner IL group at http://www.linkedin.com/groups/Scrum-Practitioner-Israel-81807?trk=myg_ugrp_ovr
Food and drinks are sponsored by Typemock LTD.
I've been running this blog for 2 years now and so far I have kept my ranting to a bear minimum. Today I'll make an exception (hopefully the last one).
I got a distributing call a couple of days ago, telling me that unfortunately there are no more places at the Haifa Agile Tour event and "were sorry but please don't come".
In itself not a big deal, I've missed more than one event dues to space limitations. Getting this calls just TWO days before the event (which I registered a few months ago) AFTER I got a a confirmation email saying "please come and here is where you park" is a just plain wrong.
When you organize an event its ok to:
Emailing people saying we managed to increase our venue please come, just to call them so late in the game apologizing with no clear reason is NOT.
Doing so disrespectful and insulting. It clearly states that some sort of criteria was applied other than first in first served. Really the last thing I would expect at an event sponsored by the Agile Tour Organization.
So I contacted the organizing firm and I got the following answer, no nothing unexpected has happened at the last moment, just that they ran out of place and:
Sine this conference is more relevant to people of the industry more that it is for consultants, sadly we had to unregister consultants
That is only "developers" were let in. Agile "Coaches" and other (none potential customers) were left out. since clearly this is less relevant for them.
So here's a couple of questions for Ignite people:
Is that how you regularly do business?
Do you really think its wise to tick of people (specifically the kind that makes a living by connecting to people) just in order to attract a couple more potential customer?
If you are refusing people, why was the registration open while doing so?
And my blog title is IMistaken...
Today I gave a session about how to write better code in the Israeli Software Craftsmanship group. While I didn’t manage to cover all the things i planned to do (I underestimated the time needed) I still manage to have a great time.
For those who missed the session and for those who wish to get a second glimpse the slides they can be downloaded here.
The Israeli ALT.NET group is having its second tool night Monday the next week on the
on Mon. 12/07, 18:00-21:00
Sears offices,
Ekershtein building A,
HaMenofim 9 St,
Herzeliyya Pituach
The format is for 4-6 sessions, by different presenters.
if you want to register and tell us you’re coming go here.
Hope to see you all there
It appears that many have found this topic interesting, therefore we shall be conducting this open house one more time. it will take place on Monday, February the first at Sela offices. This event requires registration so if you are interested just leave me a comment.
If you wish to review the slides they can be found here.
Second session was planned to be another session with Alistair Cockburn however, he choose to ignore the official session title and instead he conducted an interactive activity demonstrating the power of iterative development and effectiveness of an adaptive process.
after that Ive joined a session focusing on the role of the PO in a scrum process and how to scale this position without damaging the entire process.
The role of the PO in a scrum team is to represent the client. the PO is responsible of maximizing the ROI, i.e. he’s the one responsible for generating $$$. Specifically the PO is in charge of grooming the product backlog, which includes among other, writing user stories, prioritizing them and keeping track on what is getting build. The important thing to remember is that this is an active role, stories are not invented from thin air, they are discovered by talking with users, customers and sometime even the developers. A good PO will actively manage the backlog, he will keep priorities straight, refine stories as new knowledge is gained, remove less important stories and add new ones.
The key point of being a PO which is sometimes missed is that the PO should consider himself as part of the team. When a PO works in disconnection from the team, things will usually not go smoothly optimal. For example while in the Scrum “rule book” the PO approves stories during the demo at the end of the sprint, effective PO’s do not wait for it. they actively review and approve progress during the sprint work. after all why wait?
But sometime one person is not enough to effectively cover all the responsibilities of the PO role. and the big question is how to scale that role. Like anything else there is not a single answer on how to correctly scale the PO role, each method has its own strengths and its own risks. the key for success like anything else in life is to always manage the risks and be on the lookout when things are not going as they should.
One way of scaling the Po is to divide the by area of responsibility. i.e. one person (or more will work closely with the customer) and one (or more) will work closely with the team. Another option is to split the work more naturally according to the product technical components. but no matter how the work is split its crucial to first achieve good communications channels between the people functioning as PO’s. Normally a PO team will much higher level of cooperation than other teams to succeed.
another tip for scaling the PO role is to adhere to agile values, i.e. always inspect how the team of PO function and to improve. It is also possible to use a modified scrum process in order to manage the work inside the PO’s team.
but the most important tip of this session was when to chose not to scale. Sometime organizations are scaling the PO not because they actually need to, but because there's an underlying dysfunction which was not recognized. for example I've seen a PO which spent so much time in customer relations, that he didn’t have time to help the development team. naturally the team complained, and suggested to add more personal to the PO. Only after sitting with the PO and raising the team issues, did we realize that the PO did have time but he didn’t fully understands what was required of him.
So before scaling, take a good look, maybe scaling i not the answer. maybe just maybe there’s a better alternative.
After Alistair lecture the convention divided into 4 different tracks,
I not going to explain too much here info on that can be found here and here. I would just say that Kanban is what guided toyota when designing its lean manufacturing line and it very much resemble a Scrum process with two major differences:
Kanban should be used in situations when one can’t plan effectively, even for a very short cycle found in Scrum. This usually happens in specific kind of projects. one example would be projects which are mainly about support and maintenance. In These priorities really change on a daily basis making planning useless.
However many projects do have specific stages in which its really hard to plan ahead and naturally they adopt a more Kanban style of working. This happens a lot towards a release date during the Hardening phase. In this phase most of the work is about solving issues found as fast as possible and there is nt much use in doing extensive planning ahead.
Kanban is sometimes adopted to hide a Scrum smell. Sometime an organization find himself incapable of planning and adopt Kanban way of working. However, the inability to plan can sometime be a real dysfunction needs solving. Maybe the PO is not doing a proper job in managing priorities, maybe an external force like the CEO is injecting too much noise… adopting Kanab in this states will only hide the problem (at least for some time). In these contexts Kanban can be viewed as a ScrumBut
The most visible effect of Kanban is that from time to time team members will be blocked. Since the amount of WIP is very limited. there will be cases in which a team member is not allowed to pick up new work and needs to find himself something to do. The first option this member has is to help others. and indeed, One of the goals of a Kanban process is to generate teamwork in order to solve bottle necks in the process.
but there are cases in which one cant help others, this is the time in which a member works on improving the process. Whether by trying to understands why the bottle necks happens and resolve them. or by doing any kind of work to improve General productivity (Paying Technical debt, optimizing some development process, cleaning up…)
another Effect a Kanban has is the that regular measurements like Velocity burn down charts lose their meaning. You cant draw a burn down when not working in time boxes, the same goes for velocity. Instead in a Kanban process one use a modified Burn up chart in order to measure the WIP at any given time (where the goal is to minimize it) and ”lead time” which is the time it take for a task/feature to be finished (naturally the goal is to shorten the time).
To summarize Kanban is an agile process, which resemble Scrum but takes it a little further by adopting a flowing kind of process. It was successfully adopted by Toyota , and it can be adapted to enhance a Scrum process or to replace it in specific stages during the prodcut life cycle.
next Scaling the PO Role
The opening talk title was “Effective software development in the 21st century”. As promised by the title this session was packed with so many great insights, advices and ideas for me to be able to repeat them all. But some stuff did stick and I thought i should share.
Yes, this simple fact still comes as a surprise for people outside agile circles. However one must remember that originally Agile methodologies (mainly XP and Scrum) were created for such teams. A fact that some Agilists tend to forget. What is important that current methodologies, as used today, have grown, changed and adopted to all kind of projects and they are still growing. For example the trend in which more engineering practices are picked by organization doing Scrum might soon force the powers to be to finally include some of them in the “book of Scrum”. Yes who knows what the future of Scrum might be.
A great metaphor the full details can be found here. In short, when looking at development as such a game we can say that:
so where that leaves us?
With two (actually more) important observations. First, like any other complex game you don’t find yourself in the same state twice,and a single winning strategy does not exists. In fact, when talking about strategies, the terms right or wrong does not apply, strategies are either weak or strong. What’s more important is that one can and should pick different strategies for different situation. A process which works for a startup company probably wont work as well for a big team. Second, the different in nature between writing code and developing a product might explain a very basic developing dilemma. On one end we want to ‘win’ the game of writing code, which has specific goals and a known end date. On the other side we must remember that from a product POV the game is infinite (hopefully) and we always want to be prepared fro the next “round’. Meaning that its not enough to write working software satisfying current needs. The quality of the written code must be kept good enough to support future development. And those two needs sometimes pull us in different directions
its not the first time i hear this, there’s an ongoing growing movement of developers calling all to start treating writing software as a “profession”. Alistair however summed it up quite well
“A developer must relearn how to program every few years”
and indeed software development techniques are continuously changing. When I started out my first programming job involved writing code in C/functional C++ for an embedded system. A couple of years later I had to relearn how to program when i switched to develop using object oriented C++. A few year passed and I was introduce to Agile, which came with practices like TDD, pair programming. So again I had to relearn the skills of writing software, and last a couple of years ago, I started to developing under .NET which again made me relearn much of my skills. Bottom line I feel all these relearning is the only way to keep up with the profession of writing software.
The last part of the session discussed the idea that actually software development is mostly about making decisions, and that the speed by which we transfer those ideas between minds is what actually dictates the productivity of a development team. The best way to speed up development is by locating and removing all barriers which slows down this flow of ideas. For example the reason why distributed team are less efficient than collocated teams are that they communicate using inferior channels which of course reduce the efficiency in which we can transfer ideas.
The nice thing about using this analogy, is that the entire development cycle can now be reduced to a manufacturing line and all the appropriate theoretical knowledge can now be drawn upon. Specifically by using decisions as unit of inventory we can now map the stations along the development “line” and try to locate bottlenecks by recognizing the places in which decision are being delayed.
There was much more going in the session, in fact I’m sure that in order to grock it all ill need to listen to it at least a few more times. I do hope however that I managed to convey at least some of that knowledge.
Next post ScrumBan (how to use Kanban in Scrum)
Well the second gathering has ended and it was great. while the amount of people coming this time seemed to be a little less than the first time (I estimate there were about 150-200). Content wise this day was way better. I think that this time most of the sessions were aimed for a more advanced audience, assuming at least basic knowledge of what is scrum and Agile.
Another improvement was that this time the keynote speaker was physically present. While it was nice hearing Ken Schwaber through a live feed, it didn’t have the same effect as having Alistair Cockburn in the same room. And hearing what Alistair has to say is fascinating (more on that will follow).
Like last time, the day was opened by a lecture given by the key note speaker followed by breaking up into 3 tracks lasting until the end of the day when we gathered for an ending panel discussion. all and all i was able to attend 5 sessions all of them were immensely interesting. I just wish that someone would find a solution enabling a person to attend two lectures at the same time.
The second Israeli Scrum User Group gathering is happening today. Last time was really good and I expect this time to be even better. the Key Note speaker of the Day is Dr. Alistair Cockburn and the rest of agenda also looks promising even more.
so if don't have any special plan I'm sure its not too late to come.
So many announcements today.
Anyway next week Ill be giving two open houses:
The first will be at Sela University on the 23/3 and will deal with the trouble of planning and estimation in the software world. (As far as I know most of the places are taken, but if you're interested leave me a comment and I'll se what can be done)
The second one will happen at Haifa on the 25/3 show why Design For testability is not a prerequisite for doing TDD. (the slides for this can be found here.
Posted in: Events
Been some time since our previous encounter so we thought we might enjoy another meeting.
Anyway, we will meet on
April 2nd and 3rd, at Sela University.
Details are on the alt.net israel’s usergroup:
http://groups.google.com/group/altnetisrael/browse_thread/thread/4ab4329c4bdd8253 (hebrew)
I would like to thanks my associates at Sela making this possible.
Signup link will be published shortly.
Posted in: Events
6/10/2013
Posts
