Agile Israel 2011 visit summary

On last Monday, April 12^th 2011, I have visited the Agile Israel 2011 event.

As a rule, I tried to focus on lectures by guests, especially on guests coming from abroad. I have already received a 2-day Scrum training by AgileSparks representatives in the past, and so preferred to hear things from a fresh angle. I would also like to say "kudos" to AgileSparks for bringing such a large event together, year after year !

The short list of lectures I've attended:

• Keynote: Scrum & XP Beyond the Trenches - Henrik Kniberg
• Agile Software Craftmanship – Principles, Practices and Best Practices - Gal Marder
• Moving from Yearly Plans to Continuous Planning using Lean Product Management – Inbal Oren
• Lean Startup – Guy Nirpaz
• The Dolt’s Guide to Self-organization: How to Make Self-organization Work in an Agile Business – Jurgen Appelo
• Visualizing System Archetypes – Visualization and Systems Thinking – Karl Scotland
• Continuous Deployment – Outbrain Case Study – Itai Hochman

All presentations are available at http://agilesparks.com/AgileIsrael2011Agenda.

Following is a description of the lectures I have attended, followed by some of my notes – in case you are interested reading further into it.

Feel free to scroll through it and read about those that interest you.

Keynote: Scrum & XP Beyond the Trenches - Henrik Kniberg:

The keynote was given by Henrik Kniberg from Sweden (see his blog here, including the slides from the Monday’s presentation) , the author of “Scrum and XP from the trenches”. Recently, with AgileSparks help, it was translated to Hebrew.

He gave a very interesting lecture, extending some of the common scrum ideas with some more advanced thoughts.

Some of the items I’ve collected from the lecture:

• Performing “bug bash” Tuesdays.
• Backlog workshop for the next sprint – perform once a week (for example – every Wednesday) – spreading it over the three weeks of the current sprint.
• Provide estimations only on stories and not on tasks. The tasks are small enough, and the estimations on them do not really help, as long as the whole thing gets done. Each task should be roughly the same size of a few hours or one day.
• Focus factor – estimated from previous sprints.
• Don’t fill the sprint – have it about 70% utilized, leave slack.
• Ask the scrum team about their top 3 impediments (during retrospective) – so as to focus on removing these for the next sprint.
• “King pattern” – one of the stories in the scrum is the top priority – “the king”, and everyone should help to get it done. Once it is done, the next important story becomes the “king”.
• Definition of done:
• Merged to trunk (mainline).
• Acceptance tested.
• No increased technical dept (the code base was not messed up as a result).
• Simple design
• Passes all tests
• No duplication
• Readable
• Minimal
• Story that is “ready for development”: define when something is clear enough and is ready for development. This requires to have the estimations and the acceptance tests ready before starting to develop.
• Tests automation backlog – part of the sprint content and gets some of the time within the sprint.
• Top 5 internal (technical) improvements – part of the sprint content and gets some of the time as well.

Agile Software Craftmanship – Principles, Practices and Best Practices - Gal Marder:

Gal is the CEO of Trainologic - a company that focuses on software teaching and consulting. I have attended a 6-day Java course that was passed by him to our group in VMware, and I was impressed already back then by his ideas and ability to present them, so I wanted to attend this one.

The presentation focused on the real day-to-day aspects of programmers who would like to consider themselves as craftsmen, and that being agile is an integrated part of it.

We heard some of the similar ideas from Uri Lavi from the "Software Craftsmanship in Israel" group, and I think it is good to being reminded once in a while what “software craftsmanship” means.

Here are some points I wrote down from this lecture:

• Agile architecture – has more abstract models, less little details.
• Have a high-level architecture modeling – whiteboard sketch is enough. See http://www.agilemodeling.com/ as a resource.
• Models (creating these should take no more than a few days, even for a large project):
• Technology diagram
• UI flow diagram
• Domain model diagram
• Change cases: how will you change the architecture when some assumptions change.
• How much initial modeling should be done ?
• Known technology – none or simple.
• Unknown technology – very little.
• Partially known – little.
• Clean code: code is a way of communication and documentation, therefore it needs to be clean and readable.
• Test-Driven-Development – provides an immediate feedback, serves as a safety net.

Moving from Yearly Plans to Continuous Planning using Lean Product Management – Inbal Oren:

I have attended the first 15 minutes of this lecture, but was a bit disappointed - as no ideas were quite new for me, and I did not quite like the way the presentation was made.

One thing he mentioned was a recommended book by Marty Cagan (a former Ebay product manager) – “Inspired: How To Create Products Customers Love” .

So I have moved in the middle to the following lecture.

Lean Startup – Guy Nirpaz:

Guy, the CEO of Totango, was talking about the ways agile and lean startups should choose to increase feedback and value creation.

It is of course relevant not only for proper startups but also for emerging product groups within large companies, such as our APM group within VMware.

Guy is also a great speaker and it was an enjoyable lecture.

Some ideas from the presentation:

• Lean is about speed of execution, not the cost.
• MVP – minimum value product – what is the minimum we can do that will make the customer interested.
• Lean startup – driven by a compelling vision, rigorous about testing this vision.

The Dolt’s Guide to Self-organization: How to Make Self-organization Work in an Agile Business – Jurgen Appelo:

Jurgen Appelo is from Nederlands, and is the author of the “Management 3.0” book.

His lecture focused on the power of self-organizing teams, and the role of team leaders and development managers in an agile environment, and about ways the manager can move the power to the team.

The manager should be:

• Managing the individuals – making sure the rules are fair.
• Managing the environment – to protect the self-organizing system.

He presented 7 levels of empowerment, that should be chosen from in every situation:

1. Tell – make decision as the manager.
2. Sell – convince people about decision.
3. Consult – get input from team before decision.
4. Agree – make decision together with the team.
5. Advice – influence decision made by the team.
6. Inquire – ask feedback after a decision by the team.
7. Delegate – no influence, let the team work it out.

Of course, it is the manager’s skill to select the appropriate level in every case.

Visualizing System Archetypes – Visualization and Systems Thinking – Karl Scotland:

Karl Scotland from the UK comes from Rally Software – one of the leading Agile Consulting and Implementation companies.

His lecture focused on understanding the limits and constraints in our processes and how can we remove or reduce them, and find the root cause and reduce it.

The lecture was on a theoretical level for the most of it (using some “feedback loops” models), but had some good examples.

One initial example he gave: You drink coffee when you’re tired. But the coffee just treats the symptoms, to really treat the tiredness you might want to do more sports, have a more healthy lifestyle, etc…

Some notes from the meeting:

• Put limit on tasks: don’t do more than X things at the same time. Adding more tasks will degrade performance.
  For example: do not ever have more than 2 items “in progress”.
  The limit needs to be found iteratively – add a task and see how the performance is affected, until the correct balance is found.
• Shifting the burden: if you have a resource (a person, a hardware), that is a bottleneck, you need to see how to dissolve it (move skills to others, etc…).
• Limiting the total activity, putting activities into “swimlanes” – so that they won’t interfere one with another.
• Classes of “service” – do prioritization, have different classes of “service” for different issues (for example – different service level for bugs from Beta and bugs not from Beta). Always be able to do the most important stuff first.

Continuous Deployment – Outbrain Case Study – Itai Hochman:

Outbrain have mastered an excellent continuous deployment process – a developer commit starts running on production in just 30 minutes. Itai leads the engineering at this company.

Their business is to suggest additional related articles when reading  an article/blog, so in some cases there are no severe outcomes from a bug.

On other hand, some of their customers are CNN and Ynet, and their servers receive around 100,000,000 hits a day. Their total deployment is over 100 servers.

Some points on their process and how did they achieved the above:

• They have a lot of very separated and single-responsibility services, having EVERYTHING automated (extremely high automatic tests coverage, automatic monitoring of all the systems, constant self checking of all services and modules).
• Their developers are the total quality owners – there are about 15-20 developers and just 3 QA engineers, who’s role is mostly to help the developers to plan the tests and to implement the automation for the feature, and are a very integrated part of the development process.
• Each developer owns a specific feature, and this reduces the interdependencies.
• Each bug or a problem is analyzed immediately, and for each problem they install measures to avoid it next time (automatic test, additional monitoring ability, etc…).
• All code reviews are posted to reviewboard and are done immediately, and the feedbacks are treated with high priority and are fixed as soon as possible.
• The deployment is done on a staging environment as a first phase, and a portion of the incoming traffic is directed to it.
• They get also immediate feedback on performance and SLA of the new code push (they use Nagios and another tool for SLA, didn’t get the name).
• They use TeamCity for their continuous integration.
• For new features, they use on-off switches (flags) and internal (“hidden”) URLs, so that the QA/PM/Support can play with the feature, while the customer is not exposed to these features. This happens for a short time, after which the flags are removed, and the feature becomes part of the main flow.

That’s it for the long summary.

Hope this was interesting and helped you.

Feel free to follow-up with any questions or suggestions.

Baruch.