Saturday, 30 June 2012

About Visibility

A couple of years ago I had the luck to attend a course given by Ken Swchaber. during that course Ken pointed that the main role of the Scrum Master in a scrum process is to ensure visibility. On all Levels. But why is visibility so important? There are many answers to that. Probably too many for me to do justice to them all. for example, you need visibility to understand exactly where you are in order for you to make the right decisions based on real hard facts. Today, I happened to tune in into a TED session about Four principles for the open world, by Don Tapscott. In that session Don talks about Transparency and what that may cause organizations. He explains that since today the world is so transparent organizations must really adopt...

Wednesday, 27 June 2012

Iltam Meeting – Being Agile

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

Tuesday, 26 June 2012

Taking design out of the requirements

One of the biggest mistake you can make as a product person is to include in the product requirements technical design decisions. I picked up this lesson about 4 years ago at a session given by Tom Gilb at the first Agile Testing Days conference. I think this lesson is applicable in all types of development processes but is crucial when you are trying to use an agile process The Mistake Here’s an example I recently encountered at a backlog grooming meeting: We need to have a pipeline of processing stages in order to … It was the word pipeline was got me going. when you mention a pipeline in a user story. no matter how you turn this around you just decided not only what you want but how you want it built. there is no sane user (that I know)...

Sunday, 24 June 2012

Push vs. Pull Management

Over the last decade or so I encounter quite a few managers, while each of them was unique in its own way, I roughly found that I can divide them into two main groups according to their strategy. Pull Managers On one hand there were managers who were very into what went on always walking around asking question showing interest in everything going on and putting their nose into all places including those it didn’t belong in. Push managers in the other group there were those who considered themselves the focal point of their team, they usually got their info by using all kinds of report, they did attend meeting when needed, and naturally they did talk to their team, but most of the time they were minding their own business using their...

Thursday, 21 June 2012

And Sometimes You Lose

Here’s a story of TDD adoption failure: about Two years of effort becoming insignificant in about 6 months. Shame Want to adopt Agile and don’t know where to start? click here to le...

Wednesday, 20 June 2012

Don’t Repeat Yourself–the story of a wasted hour

The DRY principle is kind of a known concept to most software developers. it goes hands in hand with “Minimize Duplication” (4 elements of simple design by Kent Beck) “Single Source of Truth” and probably some more of this kind. But lets start with a story I hate Wasting Time This week I was sitting doing some pairing trying to setup their first Given-When-Test using nBehave. We went through the regular steps: creating a new empty project, setting up a new empty spec test running it seeing that it fails and started working on actually doing something meaningful by loading up the application DAL into the test context. 10 minutes into the process, executing what we had resulted in a very nice FileNotFoundException and some text talking...

Monday, 18 June 2012

Agile Practitioners IL - 9th Group Meeting

On July the 8th we are going to meet again. This time we will meet at live person offices and will take the content into the more technical aspects. Oren Eini (AKA Ayende) is going to talk about: Unit Testing - A Historical & Economical Overview And we might even do a hands on if time allows, so don’t forget to bring your laptops as well. The even of is open to everyone however registration is required. for more details and to register go here Want to adopt Agile and don’t know where to start? click here to le...

Sunday, 17 June 2012

More Agile Myths

Marc Löffler in this post talks about some agile Myths. about a year ago I blogged about some agile misconceptions. Here are some to add to this list. Agile = No Design In an agile process you usually wont see a specific design phase. In fact scrum for example does not explicitly talk about design at all. This leads some people to think that in an agile process design is not done or is not deemed important. Well actually quite the opposite. Design is such an important part of software development that trying to box it into a specific time/phase in a process simply doesn’t work. When development software you need the flexibility to change/update/adopt your design as you learn more and more.that is why in agile circles we will usually talk about...

Saturday, 16 June 2012

One question at a time

Taken from Agile Testing list: If someone asks me a complete list I tend to ask what is your most valuable question you want to get answers now. And because I am a man I can only do one thing at a time ;) Pascal Dufour. What a great way to describe the process of test automation. Yes I now the context of this quote was completely unrelated to anything about testing, But it did ring a bell for me. Where should I start? A very common question I hear many time when I talk to people about the need to test their feature. Many times that not because they don’t know what needs to be tested. But because there are so many things to test that it gets a little overwhelming and from all the many things its really hard to know where to start. So here’s...

Thursday, 14 June 2012

Pain the Ultimate Motivator

Gil Zilberfeld asks Why Did Agile Originate In Software? Answer: the pain! The software development business has been suffering for quite some time. The Standish group has been reporting (int heir Chaos report) that about 2/3 of all software projects does not meet initial expectations (either the completely fail or overrun budget/time or both). And for the past decade or so those numbers have not changed drastically. And frankly every person involved in the software industry is familiar with this pain. Developing software is a hard business. And where is a pain there is a reason to change. That is the nature of evolution. Successful species do not change. If the methods and techniques that predated agile were good enough there was no reason...

Wednesday, 13 June 2012

On Various Testing Levels

One of my very first few posts (dates end of 2008) dealt with the premise that One test level is not enough to reach a good qulity product. Then I argued on one hand that Integration tests are not enough, but on the other Unit tests are not enough as well. Only the Power of combining both approaches will truly help make your product successful. Has anything changed since then? Since then I had the chance to meet  a lot of great people who taught me a lot about Quality and specifically about testing. I had the chance to meet people like Lisa Crispin which exposed me to the Agile Testing Quadrants, Michael Bolton who taught me the difference between tests and checks and Elisabeth Hendrickson who really showed me that being a good tester...

Tuesday, 12 June 2012

Tests Not Run Waste Away

Over the last couple of weeks I was helping a developer tackle some nasty issues with some automated tests which kept failing for no apparent reason. The tests in question were not unit tests and did not belong to the end to end type. Instead they were somewhere on the level of component and involved several units of code, a service or two, some threading and communicating to another process. After watching the struggle continue for a couple of hours, I started to get the “writing tests shouldn’t be that hard” alarm buzzing. So I took a step back realigned my thinking glasses (yes I think using my eyes) and looked closely again. What I now saw was: The amount of time we invest on this might indicate a negative ROI The heavy usage of mocking...

Monday, 11 June 2012

Estimation and Commitment

Today we had a meeting at a potential client and during our meeting the they asked the Million $ question. It went something like: Question, Using this agile thing how can we tell for our project when we will be done? You Can’t Which reminded me a story I heard about 20 years ago which went something like: A tourist arrives to the old city to see the sites, during the day he see this ragtag kid sitting and playing with his friend, he approaches this kid and ask “tell me, how long will it take me to get to the old market?”, the kids look a moment at the tourist and then turns back to his friends without saying a word. the tourist politely asks again which yield no better result. and even after nudging the kid he still gets no answer. Frustrated...

Sunday, 10 June 2012

Israel Dot NET Developers User Group (IDNDUG)

Next week I’ll be talking at the IDNDUG group meeting about test automation. its going to be quite a long session (about 2 – 2.5 hours) and I will try cover several aspects of test first approaches as they developed over the past few years. While the session will not be completely technical and will I include some general background, I do intend to dive a little deeper then your regular “Introduction is TDD” session. so if you are planning to come do bring your laptop, we might find some use for it. for more details and for registration go here Want to adopt Agile and don’t know where to start? click here to le...

Saturday, 9 June 2012

The Role of Management

One of the talk I really enjoyed at XP2012 was: The Manager's Dilemma by Ola Sundin. In this talk Ola tried to answer a simple question that always rises when an organization is starting to adopt Scrum: What is the management role? Manager as the developers of the Organization It was lighting talk (15 minutes), so there was not a lot of content there, but there was a single excellent idea. The managers are the people which are responsible for making the organization better. while the team, the SM & the PO  are in charge of developing a product making it better. Managers are there in order to improve the organization in order for it to become more valuable to its customers (share holders). Using this basic idea Ola showed how he managed...

Friday, 8 June 2012

TDD exercise for beginners

Two years ago I posted about this excellent site that contains various TDD problems that can be used by beginners to practice their TDD skills. Over the last couple of days at the TDD mailing list there’s a thread in which people are putting links to all sorts of great resources for such exercises so I thought to put them all in one places for future reference Http://nimblepros.com/resources – a site containing 11 code katas. I actually participated in a testing dojo that used the Gilded Rose Refactoring kata and it was great http://stackoverflow.com/questions/2443697/tdd-exercise-ideas -  a thread discussing the same subject with several problems for TDD. http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue – another (the original?) Kata catalogue. contains all the classics and then...

Thursday, 7 June 2012

Agile Research

I was lucky to have the chance to participate in the XP2012 conference which was held last month at Malmo Sweden. One thing that makes this conference special is that the conference is organized in a joint effort with universities. The basic idea (which is great) is to bring together practitioners from the industry along with academicals representatives in order to combine theoretical knowledge with real life experience. and make both share their knowledge. The thing that did strike me weird however was that all the professors and PHD students I met, came from Exact Science departments, that is all of them were majoring/researching in some field related to computer science, software engineering or something similar. Why is that weird you...

Wednesday, 6 June 2012

The Mistake Programmers makes with Requirements

One of the more common complained I often hear programmers make is that they don’t not get good enough requirements, and even when they get them its many time too late and more often than not they significantly changes along the way. (and by change I don’t mean getting new requirements all the time which also happens, but to the same requirement starting as one thing and then ending as something different) at the end of such a complaint there is always the assumption, which sometimes is said explicitly and sometimes not, that if “they” could write proper requirements all our problem will be solved. Perfect requirements are a Myth in order to understand this statement one must think what is the purpose of a requirement. that is why do we use this mechanism. and the goal is actually quite simple....

Pages 381234 »

 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | Walgreens Printable Coupons