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 good values as part of they backbone. those values are what creates trust which later on enable real collaboration.
So here you have it, we want to create a high level of Visibility in order us to gain the needed trust which will enable us to truly collaborate, with our customers, with our managers with our peers and with ourselves. Visibility is the key to get there.

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: Agile Principles,Agile Values

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

Read more »

Posted in: Events

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) that actually care about pipelines. in fact I would assert that most sane user has no idea what a pipeline is, unless they come from the oil business.

So why is this wrong

First lets be clear there is nothing wrong about doing design. In fact it’s a very crucial step in developing software. The thing is that you don’t want to mix between technical design: how we are going to create this, and the business needs (requirements): what we are going to build. and there are two main reason why you don’t want to mix this:

1. when you use the solution in order to describe the requirements you actually hide the business need. instead of discussing the need you start to discuss how you implement it. this makes business decision like prioritization, exact behavior much more difficult. its especially true if the solution is for some reason marked as an “infrastructure” that will be needed. as a product person how can you give low prioritization to something the technical department just claimed to be an infrastructure? even if that infrastructure was just created to solve a less important business need?
2. you don’t want to kill the team creativity – the moment someone put the solution - pipeline in the story was the moment the team stopped thinking about is this the best they can do. Is pipeline the best way to achieve the need? maybe it is maybe its not. putting a pipeline in the solution will discourage any team from thinking about alternative. After all, they were not asked to solve a problem, they were asked to implement a pipeline. so that’s what they will do.

When you are at the phase in which you design your product translating it into requirements for the development team, try always stay in the problem domain. Let the technical people worry about the solution. Technical design is the exact thing they are trained to do. the minute you start giving them the solution you just wasted a highly priced team and probably took one decision much too early.

Read more »

Posted in: stories,tips

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 own room to manage the work. and popping from time to time to ask something/direct the work.

While I do have my own preference on how I would like to see managers behave. I do think that you can be successful using either way. I do however feel that there are contexts in which “Pull managers” have a higher chances to succeed.

Pull vs. Push Systems

No I’m not going the Kanban road. I do want to talk about systems design.

question: if you have a system in which a single component needs to keep track of the overall system state how would you design it?

Will you have the various parts of the system “send” their events to this main component (Push) ? or would you have that main component pull the needed information whenever he needs it?

like always the correct answer is: it depends. If you have a very high rate of changes in your system (lets say thousands of events per second) or/and you have a relatively small number of parts. you would most likely prefer a pull mechanism. if however you have a relatively small rate of change or/and a large number of parts you would probably prefer a push mechanism.

Now lets take it into management. I’m used to work in an agile environment. in such an environment that amount of data which is gathered on a daily basis is large. the entire process is created in order to handle changes. and if you do it right most likely there will be a lot of change. and in such an environment if you want to succeed I believe that going the pull way will server you better as a manager.

Trying to sit in your office and expecting the information to come to you will means that you most likely will:

1. annoy your team – demanding them to bring the information to you whether on a daily basis or via and electronic management tool.


2. Miss a lot of the info – since an agile process will focus on verbal communication, there’s a lot going on which is not captured in any written way

Trust me if your managing an agile team you will need to do the Gemba each day

Read more »

Posted in: Agile Management,Agile Values

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 learn

Read more »

Posted in: TDD

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 about that the need to use a strong name assemblies only.

Great!

Of course Microsoft was generous enough to omit the name of the actual file (which probably would have saved us most of the time in fixing the problem and your time in reading all this) but anyway 1 hour later we noticed that the code base has several 3rd parties dll’s appearing in the wrong places and they were all checked into the source control AND to make things happier they were not of the same version. In short we had mismatching dll’s duplication.

Of course, like always, after I fix a problem everything seems so obvious and I cant figure why I didn’t understand it much earlier. but anyway after 2 more minutes we had that one thing solved and we actually were ready to do some serious work. At that point however we ran out of time so we scheduled to continue another time.

Duplications are Evil

Yes the DRY principle which wikipedia defines as :"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." applies to more than just code and code design. It applies to all parts of the system, in my case it can be restated by the common sense directive:

You shall only have a single copy of any 3rd party dll checked into your source control

Yes I feel stupid

So where else can DRY be applied?  What example do you have?

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: Design,Engineering Practices,rant

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 learn

Read more »

Posted in: Agile Practitioners IL

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 emergent design, or iterative design. the idea is to design more and more of the product as we learn more and more about the problem.

Agile = No Planning

It still puzzles me how people reaches this conclusion. Yes there is no one single long term plan that we follow. But just by looking one can clearly see that most of the structure you have when following an agile process is centered around planning. In scrum in all the ceremonies we do some sort of planning. In sprint planning its quite obvious we plan a sprint, in daily meeting we pan the next day, in demo we gather feedback in order to help plan the next sprint and in a retrospect we plan how to improve.

Agile = Small Teams

When I started out most of the time coming to large companies I heard them saying that while agile sounded nice it seems to be only appropriate for small teams mainly or those “crazy websites” projects. Funny enough I’m lately starting to hear (usually in small companies) that while agile is nice, its too much of a process and is too strict for what we need. its only good for bigger projects when you need a process to get going. It’s funny how the wheel turns.
In truth an agile process can be used in both situation, and the actual goal of the process is to find a balance after some trial an error of course. on one hand we want to give enough structure as to avoid complete chaos and on the other to still allow for the flexibility and agility which are so important to stay competitive in the software industry.

What other agile myths do you know? What is your experience with those myths? feel free to comment…

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: Agile Principles,Design,Planning

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 an idea. Treat your tests as question you would like to get an answer for. Each test case ill reveal a piece of information about the feature you write telling you some specific a fact about how the system behaves.
for example when you test a trivial add method one question can be: I want to know how my method adds too positive integer values. another question could be: I want to know how my method deals with adding a negative value to a positive value. and so on.
The trick is to ask yourself:

what is your most valuable question you want to get answers now"

that should be the first test you write, and when you get an answer the next test should give you an answer for the next most valuable question. and you continue to write tests until you don’t have any more questions to ask.

only do one thing at a time

Does this sounds like one assert per test?
To me it does. and now I have a good answer when people asks me why just one assert per test.

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: Agile practices,tips

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 for Agile to be invented (or is it discovered).

The First question

One of the first question we start with at a new organization is trying to understand the current issues. And we specifically ask the people involved what exactly are they trying to solve. We ask not because we cant tell. We ask to make sure that they are feeling the pain. In order for us to actually continue we need them to truly feel it.
“I just want to improve” is not good enough. In order for agile to take hold and really succeed. There must be a a big enough pain. Otherwise the people involved most likely will not have the necessary motivation to stick with an approach that in many cases seems weird and counter intuitive. In order to change we must feel a pain.

How come we’re lucky to be the first citizens in agile-land?

Since Pain is common place in our industry we had enough people motivated to try new things. Eventually, I think, that what made agile evolve. Not so lucky are we?

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: Random Thoughts,Self Improvment

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 takes a lot more than what I imagined.These people also helped me in refining and improving my understanding.
However I still think that relying on a single level of testing will not be an effective strategy.

Checked, Accepted and Explored

I think that I first heard this from Elisabeth Hendrickson:

Every feature (story) developed should be at least “Checked” “Accepted” and explored. Otherwise it is not Done

Checked

For most I use the unit test level to do this. Checked for me means that the code is doing what I think it does. Basically that it will exhibit no unexpected logical error and that the thing I intended it to do when I coded it is indeed what it does.

Accepted

For this I usually try to get as close as I can to E2E. Excluding the GUI. Accepted for me means that the system behave in a useful way. that is the user (or other person) that “ordered” the feature is indeed satisfied that the system behave in what he accept as a good way.

Explored

For this I use manual testing. Explored means that there was a person involved that played around with the system and tried to judge the general quality of the solution. usually there are specific question to answer in this phase, but sometimes this takes the form of free style testing. the goal of this stage is to use the brain power of a tester to see what else can be improved and whether or not the solution is indeed satisfactory.

Is that ALL?

Definitely not!
This is the bare minimum. In many contexts this is not enough. sometimes the system is just too big and needs testing at other levels, there are definitely the non functional requirements that need to be addressed and much more.
However this is a very good place to start. In some projects you can definitely achieve good enough results with only this. And if not, starting with here will give you a strong foundation to base the rest of your test efforts on.

The Twist

But what if were not in an agile context? Well the principles stay the same. I believe that using these 3 simple aspects even when you are not developing an end to end feature will do you good. Even when you are working in an team focusing on a horizontal layer of the product its just a matter of aligning your definition of what is the system under test. Each piece of functionality you deliver still needs to be checked accepted and explored. Its just that the accepted part takes a twist.
Since you are now working on part of the system, most likely your “customer” is not an end user but a fellow developer that needs to either integrate with you work or simply use it. However if you treat him like your customer he can still define his acceptance criteria. Most likely the resulting tests will be at the component (or subsystem) level and will not encompass the entire system. but either way the thing that you deliver will be checked, accepted and explored.

Read more »

Posted in: ATDD,AUT,Development Practices,Engineering Practices,Integration Tests,Unit Tests

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:

1. The amount of time we invest on this might indicate a negative ROI
2. The heavy usage of mocking framework was completely taken to the extreme to a place in which no mocking framework should be.
3. The tests were somewhat in the middle and looked like an hybrid creature. On what end they looked and smelled like focused unit tests when in fact they were integrated tests.

At that point I decided to take it up with the powers in charge and ask the bigger question of what exactly are we doing wrong here. maybe we are investing the effort in the wrong place using the wrong technique.
Today I met with the power to be and I got to hear the complete story. As it happens these tests were actually quite old and were initially written quite early when the team was just starting. For one reason or another the group of test were tagged with the Ignore attribute causing them to be excluded from the test execution. Since then they realized that they were going the wrong way with those tests, readjusted their method and actually what they have now is proving to be quite effective. The poor developer I worked with was the one who draw the short straw on fixing these old tests and bringing them up to date. The problem is that the ignore thing has gone undetected for some quite time.
So what can we learn from this:
If you invest the time to write the test you should take the effort and execute them.
Tests which are not worth executing have no reason to take up source control space. They should just be deleted. (In our case writing the tests altogether was faster then fixing them – which you always find out to be the case after you finish doing both)
Like production code tests should be maintained. The moment you stop doing so they starts to rot away and the effort involved in fixing them seem to be growing on an exponential curve.

The title of the post was taken from the “Way of Testivus”. I’ll be talking more about these things in the next IDNDUG meeting and more specifically in the upcoming SIGIST conference

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: AUT,TDD,tips

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 the tourist starts to walk away figuring the kid doesn’t speak his language and before he get very far he hears the kids shouting “about 15 minutes”. The tourist surprised walks back and ask the kid “why didn’t you answer me the first time” and the kids answer “How could I tell before I saw how fast you were walking?”

Estimate Effort Derive Duration

The sad reality of project management that we can never tell for certain when things will be done. the actual finish date depends on just too many variables which we have no control over. It can depends on the quality of our team members, on the mood they are in,  on their health, on external events which are not related to our company at all, and that’s before I talk about the planned/unplanned changes to the product and requirements.
When  using an agile approach we acknowledge this reality and try to work around this. we do this by estimating the effort involved in developing the given features the best we can and by measuring the speed in which the team work through these features. Even done right it only helps us to claim the following:
Given that no changes will happen from now till the end of the project, based on past experience, most likely we work through the remaining features in X iteration/time and we can tell this with a probability of Y%. Naturally as X get smaller we expect that Y will become bigger.
Any other claim can be considered irresponsible.

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: Agile Principles,Agile Values,Planning

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 learn

Read more »

Posted in: ATDD,AUT,Events,TDD

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 to bring all the managers into a single “scrum” team and use the basic scrum framework to manage their work. The had a daily they had a nice visible board, they created their own backlog of items etc.
And it all started by making the managers do a Gemba walk each day. That is the managers made themselves truly available for the team, by walking around and communicating to people each day.
The rest of the details can be found in his slides
Remember:

Managers are people too, Ola Sundin, XP2012 Malmo.

Want to adopt Agile and don’t know where to start?
click here to learn

Read more »

Posted in: Agile Management

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

1. 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
2. http://stackoverflow.com/questions/2443697/tdd-exercise-ideas -  a thread discussing the same subject with several problems for TDD.
3. http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue – another (the original?) Kata catalogue. contains all the classics and then some
4. Roy Osherove blog contains two katas the first has variants in almost every language out there, and the second is a little more advanced aimed to teach interaction testing
5. http://cyber-dojo.com/ – when pushing the setup button you get a nice list of various problems.
6. http://coderetreat.org/gol – the classical Conway’s game of life used in Code Retreats

If you know of more sites and resources please write them down at the comments below

Read more »

Posted in: Agile practices,TDD,Unit Tests

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 might ask. Well it was weird to me because most the things worth studying in agile are not technical in nature, they relate to human behavior, interactions team dynamics and general communications. I would expect that in order for these studies to be useful, they should be assisted by some people specializing in this kind of research. I would expect such research to be done in collaboration with phycology departments with business school with behavior specialist and even social experts. Computer science researchers (for most) simply don’t posses enough background to actually conduct this kind of research.
For example:
I attended one of the session which introduced such the following study:

Impact of Test Design Technique Knowledge on Test Driven Development: a controlled experiment

as the name suggests the goal of the study is to judge if concrete background of testing theory will change how TDD is practiced. Now don’t get me wrong, the assumption checked is very interesting and the experiment was done according to proper standards. However there was at least one little problem. The subject of the experiment were under graduate student undergoing a programming course as part of their studies.
Which raises the following question:
Under what conditions would someone consider a group of students to be a fair representatives of the general developer community?
Are we seriously going to take undergraduate students (which at most had a course about TDD and most likely just an intro session of 2 hours) and treat anything that might happen to them as useful evidence applicable to the general group of developers?
I think this is probably a very big mistake.
so how does this example relates?
During the conference I heard a nice story about some behavior studies conducted in the US sometime in the 70’s. It appears that those studies which later became the foundation of the field, suffered from a similar symptom. Most of them were done on subjects which were mainly young adult white males in the age range of 20-30. Naturally it was later found out that conclusions drawn from that research group were not very applicable when facing the wider general population and they were a little bias in their finding.
Are we sure its wise to repeat that mistake yet again?

Read more »

Posted in: Research

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. we need to get a need which usually sit at the user/customer head and be able to move it into the programmer head in such a way that the programmer will have full and complete understanding of what’s need to be done.
unfortunately the mean to pass ideas from one head to another without any lose of meaning does not exists in our world (yet), and therefore no matter how hard we try we can only do better and not perfect.

How are we doing?

Apparently not great. programmers still complain that they need to get better requirements. However I feel that we got it wrong. We have been trying for the last decade or so to make things better. Good and smart people have come up with ways to improve requirements writing and invented better way for formalization for example Tom Gilb points out that

“Requirements, the root to failed projects.”

and has some great ideas on how we can improve on that. but at the end this is in my opinion he wrong way to go.

if you can't beat them, join them

We programmers must accept the fact that understanding the business is our responsibility. Expecting others to explain things to us is quite a childish approach. At the end it is us who knows best how to gather the needed knowledge in such a way that we can understand it we fully understand things, therefore it is we that need to go out and follow these ways and reach the needed understanding. Fleshing out the requirements to a point in which we can implement them is our responsibility.
Yes there are people who can help us along the way, and yes some of them belongs to the product side which traditionally is in charge of writing requirements. But no its not their responsibility to explain it to us. They are in charge of picking out the good features, they are in charge of finding the best ways the product can grow and serve the customer. when they do its our job to understand what they want and then implement it to the best of our ability.
It is the programmer job to understand the requirement.

Read more »

Posted in: Agile practices. Random Thoughts