Agile delivers better business value in a healthier work environment

It was not until I started doing Agile that I began hearing the word business value more often. Before, I knew about the word, but hardly ever used it. No doubt Agile is closer to business value than other approaches. But.. what is different in Agile regarding business value? Other approaches have the same objective, right? Whether you do a software project doing Agile or doing another approach, the objective is the same. I believe the first difference resides in how this value is delivered. In Agile, it is delivered incrementally and order by value (i.e. the most valuable features are delivered first). In waterfall, all the value is delivered at the end of the project. A second difference is Agile provides 'better' value. The customer is able to shape the features that are delivered and it's able to provide feedback early. This way, the software that is built resembles more what they were looking for.

Lately, I have been reading some blogs related to business value. First there were some that stated that providing business value is the most important reason to adopt Agile (http://www.leadingagile.com/2009/12/adopting-agile-isnt-point.html & http://blog.adsdevshop.com/2009/12/03/if-you-dont-focus-on-business-value-dont-adopt-agile/). In reply, there were some other blogs that stated that delivering business value is not the only reason to implement Agile (http://docondev.blogspot.com/2009/12/business-value-is-not-only-reason-to.html & http://iljapreuss.blogspot.com/2009/12/focus-on-whose-value.html). I didn't understand it very well at the beginning but I think I do (better) now.

I will oversimplify what I understand describing a common scenario where a software company develops software for another company.

The software company gives value to their customers by providing them with a tool that allows them to perform their business better. This brings the question of what is value for the company that develops this software. I believe the most important asset of a software company is their people and the tacit knowledge that resides on them. So a company gains value as its employees learn how to build better software, i.e. as their collective knowledge improves. And what is value for an individual working at this company. I believe it is the same as in the company: knowledge. Individuals provide this value to the company they work on through their work.

So, If I understand correctly, the second set of blogs state that if the Software Company focus only on delivering value, probably it will neglect its most important asset, which are its employees (who will be unhappy and probably leave the company).

Humm... Software companies have the difficult mission of pleasing their customers while at the same time pleasing its employees. They need to provide value and gain value at the same time. Same happens with individuals and the companies they work in. Individuals need to provide value and gain value at the same time. How can all this be accomplished?

First, this ecosystem should work better than I described because the above graph is wrong. It's missing the value that comes from the customer to the company, and from the company to the individuals. It is of great importance for software development companies to have as customers recognized companies and it is of great importance (and the only way to improve) for individuals to work in great development software companies.

So the graph would be more like this:

It is true organizations and individuals play different games, as Alistair says. But in these games, all parties involved need to get some benefit. Otherwise, one of the games would end.

This first reason is not related to Agile, so let's go to the Second: What Michael and Ilja have been saying in their blogs. Agile work environments are healthier and nicer to work in. This alone is a great reason to prefer a company and to adopt Agile. Why is it healthier? There are many reasons: The first that comes to my mind is Collaboration and team work are encouraged. Success depends on the team and not on individuals persons. Also, agilists reckon that you have to have a life besides work. Beck says "40 hours a week". This is a very important message. The morale is higher on Agile teams. Having the software working at all time and having test harnesses allows the team to feel safer. Yet another reason is individuals are empowered.

As a conclusion, I believe it is true that Agile could help improve the way a software company delivers software while at the same time provide a better work environment. I believe the second is a great reason for individuals to choose a company, but is it a valid reason for a company to adopt Agile?. I guess the first thing companies will evaluate is if they can produce better value. However, if Agile helps the company provide a work environment that helps companies keep their best asset, it's sure is a great incentive to adopt it as well.

I have been discovered: I am attempting against the communication of Agile teams

Today, I read a comment someone post on the google wave sample page of taskboardy (http://wave-samples-gallery.appspot.com/about_app?app_id=68026)

Bringing people apart

Google Wave may yet be great, but not for this. Remember that Agile is about bringing people together -- in person. Need a real task board for this, not another application that glues people to the computer screen.

First thought that came to my mind is: Would someone consider using Taskboardy (or any other electronic tool) being collocated? Specially a task board!!! I worked in a distributed team and therefore I am forced to use an electronic tool. However, I am always in the dilemma of whether I should also use a physical task board. I know I am loosing a great visual radiator with the tool... (I decided not to, because the team is not in an open space. Otherwise, I would maintain both).

Kept thinking and perhaps the comment makes sense. How many times someone sends an email or chat with a person 1 meter away? I've seen it many times. So what can we do when the tools are not used the way they should be used? How can we encourage the most effective communication, which is face to face conversation? If the team is collocated, perhaps it makes sense to follow the comment and suppress any channel of communication that is not face to face. Take away phone, uninstall email, chat, wave, etc, etc...

Does it make sense to blame the tools? In the case of the processes, perhaps it does :-) If things go wrong in the project, let's blame scrum. At least in this case, the enemy is invisible. It is very hard to visualize what is going on, which are the bottlenecks or which are the dysfunctions. In the case of electronic tools, it would be much harder to blame them. I can't imagine telling my team member "my code sucks and I didn't do any unit tests because of Eclipse". Or... the team members don't talk to each other because of V1. Hum

Henrik Kniberg said during QCon SF yesterday we should use the tool that makes more sense to solve our problem. Now the question is: what if we are not smart enough to choose it? Will have to ask next time I see him...

Couple of things that caught my attention lately

- Scrum illustration leaves out people (http://bit.ly/2sJnHj) humm interesting, ah? Anyway, the most human side of the Agile Manifesto comes from Cockburn and not from Schwaber/Sutherland, right? Does the scrum books talk a lot about people? I don't remember. I would have to check again...

- Customer value is not in the values and principles of the agile manifesto. It's true. We are always talking about customer value, but it's not there. Is it because customer value is the ultimate objective that all Agile values and practices support?

Taskboardy available

I have finished the first version of Taskboardy, a wave gadget that allows to maintain a taskboard inside a wave. The gadget could be useful for agile distributed teams using Scrum or XP.

The idea is create a wave at the start of the sprint, install the gadget and add all members of the team. Then, user stories and tasks for each user story can be created and the tasks can be moved among the different states. Participants in the wave can assign the tasks to themselves. When someone modifies the taskboard, the rest of the team can see it immediately. Wave advices of the modification showing a number on the wave and bringing the wave to the first position.

The taskboard is very basic. I thought about adding some other features, like a description for the user story or the story point estimates, but didn't because I wanted to keep the first version light.

The taskboard looks like this:

If you want to take a look now and have an account in the wave sandbox, click here.

At a technical level, the gadget is made using javascript that calls the wave api to store the state of the taskboard in the wave. The platform takes care of broadcasting this state change to all other participants. For the drag & drop functionality, I used the Google JQuery API.

To install the gadget, just select "Add gadget by URL"

And then point to http://taskboardy.googlecode.com/svn/trunk/taskboard.xml or the short url http://bit.ly/4lc6lT. The installation is really easy!!

Another 'feature' that comes out of the box because it's inserted into a wave is the possibility of replaying the whole sprint. Not sure if this could be useful, but it sure looks cool.

Of course it's free to use and open source. I haven't been able to do thorough testing, so if you find a bug please let me know and I will fix it. I don't plan to do any addition of functionality. One of the reasons is that if some people start using it, I would be changing their functionality.

Please share your comments!

Update: I was not clear on the difference between the sandbox and the preview. The gadget works on both. The only difference is in the sandbox, there is a wave already created with the gadget installed. In the preview, you will have to install it.

Update 2/7 (superbowl hour): Fixed a problem with especial characters (",', etc.)

Does a heavier process guarantees safety?

Criticality is one of the things that justifies heavier processes, but here's an example that shows you that a heavier process could result in less safety (and of course is more costly, less user friendly and VERY annoying)

This morning, I went 5' earlier to the station cause I needed to buy the monthly pass. I (wrongly) choose the machine where nobody was in, select the appropriate options, purchase it, and.. and.... and... the receipt comes, but the ticket never comes!

I think, this shouldn't be hard. I just go quickly to the ticket office (while at the same time trying to advice the people that the machine is not working) and tell them what happened, hoping they would just go to the machine, verify that what I say is true and print my ticket (while putting a sign on that machine until is repaired).

Wrongs thoughts. There is nothing they can do. I have to call the 0800 - caltrain. "In the meantime, just give the conductor the receipt". Besides, they don't do anything to prevent other users to use the broken machine... (I don't get it)

Go to the train, talk with the conductor (they are always very kind) and he let me in (he evens tell me, 'well, with the receipt and the credit card, there shouldn't be a problem to use it the whole month..'. Nooo, I speak with the operator and she told me that the conductor shouldn't have let me in, that I should've bought a new ticket and ask for the refund sending a form that I could print through the web site through ordinary mail. Noooooooooooooooo.

Result: the process is heavier and less secure.

Less secure because a non scrupulous person could ask for a 'rebate' of its ticket, even if he got the ticket printed. How can they verify that what s/he is telling is true? They lost all the insight that could have been gained should they have gone in the moment to the machine (If the non scrupulous person tries to do the same, he would have to explain why the ticket gets printed 1' later, etc..). In the more formal way, there is no way to prove the non scrupulous person wrong and they have to refund the ticket.

The oddity is that at the same time...
- The process is more costly to the enterprise because someone has to pick up the mails, process it, etc). Worst, not solving the problem soon of course derives in other complaints.
- It is more costly and annoying for the user because I need to learn how to send a regular mail, print the form, fill it, find out where is the post office, send it and 'wait a few weeks' (as the operator kindly said) for the refund. At the same time, I need to buy a new ticket (I will go back to the old fashion employee way this time!)

Come on Caltrain guys!!! It shouldn't be that hard!

This post also comes as a result of reading Alistair's book again (my hero!). There is always these people that says 'We need to use a heavier process to be safer' and when asked 'Why?' .. Just because.....

Unfortunately (for all of us), we will always have to think.

Agile is lots of Communication

This is the first post of a series of posts where I will try to define what I think are the most important properties of Agile. As I have been reading Alistair's book, the first post is about "Communication".

What is communication and why is so important in Agile?

To understand the importance of communication in Agile, let start by its definition. The Merriam-Webster definition says communication is "to transmit information, thought, or feeling so that it is satisfactorily received or understood". Another definition taken from Alistair Cockburn says "communication is transferring one idea from one person to another". The latter is a stronger definition as it implies the idea needs to be understand by the receiver (as opposed to just received).

Why is so important to communicate in Agile?

Agile reckons that the process of construction of a software solution is a creative game where the individuals involved interact continuously to build a solution. Cockburn calls the process "a cooperative game of invention and collaboration". During this game, all actors involved contribute their particular knowledge and therefore they need to communicate among them as effectively as possible.

Even more, most Agile methodologies deliver the solution incrementally and encourage highly concurrent development in each iteration. This means all actors are usually working in the same piece of functionality at the same time. Abundant and effective communication among all actors is vital.

Let's try to visualize this with an example. At the beginning of the iteration, an increment of functionality is proposed to be built. This functionality is expressed as a set of user stories written usually by the product owner. In the planning meeting, the product owner tries to communicate what s/he thinks are the key ideas of this new functionality. A conversation between the team members and the product owner is usually kicked off where the team members usually provide quick important feedback about the feasibility and also quite often new ideas that could improve what the product owner had in mind. During the iteration, teams need to communicate extensively with the product owner to clarify missed points and to show progress. This constant communication is key to build the right product (i.e. to build what the customer is expecting). Among the teams, communication needs to be fluent and constant as well. Developers and testers (and all other actors involved) need to design, develop and test a piece of software in a short period of time. A great flow of information circulates when designing the solution, the tests and after development has finished when the team converges and agree on the final product. Agile foster the creation of the test scenarios and test cases as a group and also the creation of code in pairs. It can be seen that the flows of communication go in all directions.

Individuals and interactions over processes and tools

What are these guys trying to say? The statement says a lot about the philosophy underlying Agile and it takes a great deal of time to understand it and interpret it. My current understanding says Agile values more a team of crafted software engineers collaborating towards the creation of a solution than the same team following a prescribed process. As it is explained in the Agile Manifesto webpage, it is a "We value more" statement. It doesn't mean processes should not be used or tools are useless. It means that the focus of the methodologies, processes and frameworks is on the people and their interactions rather than in the creation of intermediate work products, filling templates or following instruction lists.

How should this interaction occur? Agile delivers software incrementally in short iterations using highly concurrent development practices. All members need to communicate to produce something in a short period of time and therefore the communication needs to happen as efficiently and as effectively as possible. And which is the most effective way of communicating? The Agile Manifesto lists as one of its 12 principles: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation".

Which are the most effective ways of communicating?

It is very difficult to communicate. If you think that even between people of the same culture and language talking face to face in a room there could be misunderstandings, you can imagine how difficult it could get (don't you have misunderstandings with your wife after living with her for many years?!!). People have their own context and ideas and so the information they receive is processed according to it. Besides, our natural language is limited and imperfect (and it reduces to the person that is trying to communicate).

So which are the most efficient and effective ways to communicate. How can we minimize misunderstandings? How can we communicate faster? Cockburn studied this and came with the following graph.

In the X axis, there's the temperature of the communication channel. Reading a paper document is the coolest of the channels and therefore, the least effective. Talking face to face in front of a whiteboard, while writing diagrams is the hottest and most effective way to communicate. I don't think many people would disagree with this. There is nothing like talking to someone while you see his face, his expressions and his body language. These "other" channels act in both directions and allow to reformulate or write a diagram if the receptors make "weird" expressions or even speed up if the receptors are getting bored. There is nothing like seeing the face of the people you are communicating with.

So how should this graph be used? All projects and all teams are different and run under different circumstances. If the team is small and it works in the same building, it is clear that they should all work in an open room, where they can talk to each other whenever they want (this is the Agile sweet spot). However, today's reality brings much more challenging projects, where the teams are distributed, in different countries, with different languages, cultures and worst of all, huge timezone differences. Generating the necessary communication channels in these situations could get really hard, but we need to keep in mind that communication is key to success in Agile. Each team will have to use the best of their imagination to figure out ways of heat the communication as much as they possibly can.

It is important not to loose pragmatism when thinking the communication channels. For example, Cockburn mentions that when the development team doesn't have full access to the business people, it is effective to leave some kind of "sticky information" that developers can check whenever they want. I found this example very valuable, because there are always fanatics that read the theory and stop thinking.

How does Agile "manage the incompleteness of communication"?

Agile tries to manage the incompleteness of communication by trying to improve the communication influx and by verifying, as soon as possible that what was communicated is what was really meant to be communicated.

Agile improves the communication:

- By encouraging open spaces where both business and technical users sit together. This fosters conversation among the technical members and with the business people, conversations can be overheard, everybody knows who is on its desk and who isn't and usually what are they working on. In short, it creates a medium where everybody is sharing the same information because the communication channels are shared by everybody. Cockburn calls this "osmotic communication".

- By having a daily standup. This short meeting that occurs daily pushes everybody to communicate.

- By doing pair programming, as XP suggests. This practice can be performed by 2 developers, 1 developer and 1 tester or 1 business people and either a developer or a tester. Although the main objective of this practice is to produce better code and minimize the bugs, it creates a great opportunity to exchange patterns, techniques (when done between technical members) and business information (when a business user is involved).

Agile provides several verification points because it delivers the software in iterations. This means that in a short period of time (from 1 week to 1 month) the business people can see working software and can verify if what they see is actually what they had in mind. Agile also encourages business users to write acceptance tests. These executable specifications are run as soon as the functionality is completed and also serve to verify that the develop functionality is what they are expecting.

Conclusion

Agile development relies on creative individuals which interact continuously to build the proposed solution. Communication could get hard, but is always necessary. Each project could bring its own challenge. Agile relies on these creative individuals to find ways to communicate as much and as good as they possibly can.

2 Intense Days at Agile Open California

I spent the last 2 days at #AOCA, in Fort Mason (San Francisco, 15 blocks from home!). This is my second experience in open spaces and I love it. I think it is the most Agile format as it allows and promotes collaboration and communication in this endless game: your career.

I met wonderful people, like Pat from The Gap who told me how she was thinking of expanding the agile horizons in The Gap. Wait... Expand? I told her the impression that I got when I was there is that everything was already Agile (It is really impressing see a whole department doing Agile..). I also met Tom Looy from Tacit Knowledge and Joshua Kerievsky. They both had been in Florianopolis last week, where they told me had a great time (Joshua even told me that he would've gone to Buenos Aires, had he knew about it).

First day:

The first session I attend was about "Growing Agile" or how to implement Agile in bigger groups, far from the Agile sweet spot. We have a pretty big group in Axway, but some people talked about groups of 100 or 200 or even 500. Pretty amazing, ah? I introduced my question, which is how you maintain the technical coherence in such big groups but didn't get any good answer... Will keep asking!

The second session I attended was Kanban 101. I still really don't understand the difference with Scrum. I thought it was about not having iterations but they told me you could still have iteration and do kanban. They told me that it was about minimizing "work in progress", putting a maximun numbers of items in progress in each phase.

The third session I attended was about team trust. We talked about team trust (collaboration) within the team. We identified things that work well: Having a shared environment, build community, collective ownership, aligned goals, a good compensation system, fairness and freedom to agree and disagree. Among the factors that can hinder collaboration we identified: "your failure equals my success environments", contradictory values, lack of motivation, a non supportive environment and lack of genuine commitment. We ran out of time, but the facilitator wanted to talk about trust within the organization. Much of what Pat is trying to achieve. Very interesting.

The last session I attended on Thursday was about a training game for agile leaders. This game continued as the first session on friday. What I found interesting about this game is that the whole introduction of Agile is through a game that simulates an iteration, it calculates business value, it is timeboxed, etc. What I am trying to get at is that the introduction contains a lot of the philosophy behind Agile.

Second day:

The second session I attended was about Agile Visualization Tools. We went over the different graphs and diagrams that could be used. I knew most of them, but there was something that was mentioned that really caught my attention. A while ago, I sent an email to the scrumdevelopment list (http://bit.ly/vzB4u) asking if there was another way of categorizing user stories. Well, it seems there is and is called "User Story Map". I will keep investigating this for sure because it seems something that could be really useful for us.

The third session I attended was about project chartering. Joshua and a coworker explained which are the most important components that should be agreed upon on a contract and the importance of agreeing on those things (http://bit.ly/3nYtI1)

The last session I attended was about distributed agile. Challenges and tools were listed. It seems most of us are facing the same problems :-)

All in all, I enjoyed the conference a lot.

A First Approximation to Understanding Software Quality

My first thoughts about software quality

First time I thought about software quality was in my first agile project, a few years ago in Globant. I remember a message on the blackboard that said: "Quality is not negotiable". Back there, I didn't know much about agile, but I was impressed with all the good engineering practices that we were following in a very disciplined way. Now, having read a few more books, I could say that we were doing XP. My interpretation of the message at that moment was: We are not going to abandon any good engineer practice due to time constraints, because the consequences of doing so would be worse. In other words, even if it takes more time to do automated tests for all features, refactor every time we felt we need to, do pair programming, code reviews, etc we are going to do it because at the end, it pays off.

Different definitions of software quality

So what is software quality? Years have passed, books have been read and the definition is still vague for me (and looking at the forums, it is still a topic of heated debate).

Juran's definition is "Quality is fitness for use". But for use by who? Juran specified that the customers should be identified and their needs determined.

Crosby's definition is "Quality is conformance to requirements". The problem with this definition is "who creates the requirements?" (i.e. those requirements attend the needs of all users?)

The Poppendieck's make a separation of quality in production and quality in development. According to them, Juran's definition corresponds to quality in development and Crossby's to quality in production. Other differences are "variable results are good" in quality in development, but bad in production quality and "Iteration generates value" in quality in development, while it generates waste in production.

Quality in software development results in both "perceived and conceptual integrity". Perceived integrity means the products attains "a balance of function, usability, reliability and economy that delights the user". Conceptual Integrity means that "the system's central concepts work together as a smooth, cohesive whole".

Weinberg's definition is "Quality is value to some person". This definition acknowledges that quality may mean different things for different persons (i.e. quality is relative).

For example:

- Quality is Zero Defects for people that are disturbed by those defects

- Quality is having a lot of features for people that use them

- Quality is elegant coding for developers that appreciate that

- Quality is high performance to users whose work taxes the capacity of their machines

- Quality is low development to managers with low budgets

- Quality is rapid development to users who are waiting for the software or to marketers that want to sell it

- Quality is user friendliness to users who spend 8 hours a day in front of the software

Weinberg's reckons that the definition of quality is political and emotional, because it "involves a series of decisions about whose decisions count, and how much they count relative to one another"

Quality that can be measured versus Subjective Quality

A lot of the quality definitions are very subjective. Value to a person.. Fitness for use.. How can we measure that? (I guess the best measurement is how well the product sells). On the other hands, there are things that can be measured. For example, CMMI approach, in its levels 4 and 5 try to measure quality using statistical analysis.... But does that assures a satisfied customer? In Agile, certain measurements can be taken, for example how many tests there are, the code coverage. Do those number assure that the tests are well written?

Open Questions

- Can we divide Internal and External Quality? The Poppendieck's talk about perceived (external) and conceptual (internal) integrity. Marick, in his testing quadrants also specifies that some quadrants aim at internal quality while some others to external. Does it make any sense to make this separation? I know you cannot have external quality without internal quality. However, it could be entirely possible to develop an excellent product that doesn't provide any value to the customer (so external quality implies internal quality, but not viceversa).

- Weinberg's definition brings other dimensions to my current ideas. For example, that rapid development or time to market can be considered as quality attributes.This is not intuitive to me. I understand that having a product in a couple of weeks has a lot of value for some persons, but if that product is bad programmed, without tests (etc.!) I wouldn't consider it a quality product.

Conclusion

The definition is still vague to me. However, to think a little bit about quality made me realize that most of the Agile values and principles aim at improving it. For example, short iterations and user involvement improve the value to the user because something nearer to what is expected is built. Engineering practices like automated testing, refactoring and continous integration improve the conceptual integrity and thus the perceived one. In other words, Agile tries to maximize the quality - value - at the least possible cost.

Agile without automated testing

Sometime ago, I was talking to my friend Matt about what would be the 'Cost of Change Curve' of Agile projects without an efficient automated testing strategy. Basically, we were talking about Boehm's Cost of Change Curve.




And Beck's famous flat cost of curve.



The latter, assumes all XP practices are performed efficiently. So the question, how would the curve grow if automated testing was not performed or was not performed efficiently. I don't want to go into much detail about what kind of automated testing (unit, functional). Let's assume the selected strategy doesn't work.

Today, reading a Cockburn's book, I saw the graphic that I was imagining, but with another topic: Agile without refactoring.

This is exactly what I thought. At the beginning it is cheaper not to think about an automated testing strategy. As the project evolves. the cost of changes without having the automated test harness grows exponentially. The analogy with refactoring is perfect. At the beginning, it is possible to do small changes without cleaning the code. A few weeks, after that, the code becomes so messy that it becomes costly or impossible to do the changes.

Self-organized sardines

Self-organized sardines swimming together at the Monterey Aquarium

Updated: A coworker (with whom I went the first time to Monterey) went recently to Monterey to check the self-organized & self-disciplined sardines, but there was an ungrateful surprise. The sardines where not organizing very well: some of them were going one way while other were going some other way and even some anarchic sardines not following any circle!! The result, the sardines where going much more slower!!!!

Disorganized sardines... Lack of leadership in that group?












Thank you Eli for the pic and the comments!

Don't blame integration tests!!!

A week ago I was looking at the presentation Integration Tests are a Scam.

First thing that came to my mind: Is he cynical with the title? (How can we blame integration tests?) The problem is using integration tests for things that should be tested at the unit level. In other words, the problem is not using integration tests for what they should be used: Just to verify that the integration between the different components is not generating any problem (well.... he is not talking about functional tests, right? Functional tests are integration tests, but everybody recommends having them as way to check that the business features are constructed the way they are supposed to be. )

Second thing: Why is it so hard to define a strategy that makes heavy use of unit tests? (e.g. as suggested by Cohn's pyramid). Is it because TDD is very difficult to learn? Is it because QA departments define the strategy (and they are more into the functional aspects/tests). Is it because of the managers?

Who can we blame for this scam? I think that we all as a community need to take responsibility. We need to understand better the benefits of unit testing, we need to be trained and we need to DO THEM!

Scrum Masters should be hot!

http://www.implementingscrum.com/2008/03/10/tony-soprano-meets-scrummaster/

Old post... Makes you think.

Agile brushstrokes

Agile Transitions, by Joshua Keriesvky :-)

	Agile Baroque Transition
	Agile Impressionist Transition
	Agile Expressionist Transition
	Agile Graffiti Transition

I between this weird comparison, Keriesvky said that in his actual project (where I assume there was not very junior people) they are not using fixed time iterations, they are not calculating velocity, they are not dividing the user stories in tasks, they were not holding retrospectives (formally, they would do it whenever it's necessary). That was pretty amazing to hear. No rules, just what works. I guess you need to be VERY mature to do such a thing.

Yet Another Bug Versus Feature Post

A couple of weeks ago I was talking with the Requirement Analyst of the project. He was basically complaining that some members of the team are too rigid in their definition of bug. Everything that is not explicitly specified in the acceptance criteria of the user story is a bug. It is deterministic. But is it really like that?

The way I see it, a user story goes through different phases of understanding and its scope is refined in each of these phases. First, it starts as an idea of something that can contribute value to the application in mind. At this moment, everybody is living in the world of ideas and that world doesn't have any restrictions or constraints. The scope of this user story is completely blurred.

When the story is estimated for the first time, it transitions to the second phase. Developers go through it for the first time, providing hints on the feasibility of the user story (or what would need to be changed in order to be feasible). QAs also help refine the story because of their ability to think of the different scenarios this user story could apply to. This is the first time (usually) the team (or at least a representative part of it) look at the user story and discuss about it. The user story takes shape. Acceptance criteria are usually added (based on the questions and discussions that arise) and the scope is radically refined to a point where the team should understand at least what needs to be done.

The planning meeting represents the third phase of refinement for the user story. At this point, the product owner explains the user story to the whole team. This should be the last phase because a scope is agreed on and a final estimation, to which the team commits to, is made based on it. But is it?

When the user story begins to roll and QAs start thinking about scenarios and test cases, developers start designing and something starts to emerge, the understanding of the user story changes a great deal. Even more, seeing something concrete triggers new ideas or unveils constraints that were overlooked. Continuous communication and collaboration between the team and the product owner is vital to overcome problems and accommodate all necessary changes. Finally, the user story is completed and with it, the user story transitions to its last phase.

All of these phases happen usually in a very short period of time in most agile projects. There isn't a big upfront analysis and design period and the project start with just the vision and a bunch of user stories understood. The rest is decided on the road. Even more, in many cases, the requirements will change and a successful agile team should be prepared to handle this. The key to be successful in this environment is to have a gelled team with a lot of criteria.

So what happens when after the user story is completed, some part of the functionality doesn't meet the expectations of the product owner or some of the stakeholders. The question: is a bug or a feature always arises. The easy answer is: if it's not among the acceptance criteria listed, is a feature request. I don't think it should be that easy. I believe the team should use its best criteria to determine if the issue is far enough of the core of the user story to be considered a new feature request. I believe Agile relies on a bunch of crafted people that add value during the whole life of the user story and I believe that a shared framework of understanding should exist between the product owner and the rest of the team (this is key for the success of the project). In other words, a successful team understands what is being expected of the product, which is the criticality of it and what is the level of necessary quality. Having all of these things in mind, the team can make a decision and my opinion is that if the issue belongs to the core of the user story, it is just healthier for the group to recognize it was missed and track it as a bug.

Changing the perspective, perhaps it doesn't even make sense to make this distinction. A new level of understanding has been reached for the user story and what is important is to decide if the missing functionality is required for the next release or not. This makes the decision even easier. One of the reasons the team has to categorize something as a bug is that if it’s a bug, it will probably need to be addressed for the release and so it implies more work. If it is a new feature request, it will probably go to the next release. If the product owner, who is the person responsible for the ROI of the project, decides this need to be included, the decision falls to how it is going to be tracked.

In conclusion, a successful scrum team should first ask the product owner if s/he thinks the functionality missing is important for the release and then track and prioritize the work that needs to be done. A team should be fond of their work and their craft and it should use its best criteria to make the decision. And finally, if it is a new requirement, it needs to be prepared to change. We live in a very competitive world where business conditions change all the time. The success of the team depends on being able to accommodate those changes.

The success of the team relies on being really Agile.

The Agile Mantra

The Agile Mantra

It's undeniable that our professional life creates paradigms and structures that we then follow in our day to day life. Agile has influence me. Schwaber's and Poppendieck's book's concepts come to my mind frequently, in aspects of my life that have nothing to do with software development.

For example

- I am constantly trying to eliminate waste - What is waste in my everyday? Well, plans that keep hanging in my head forever. They are waste, because I keep thinking about them and I never do them. Also, I tried to do things well for the first time. If I don't do them well, it is highly probable that I will have to in the future (they are bugs!).

- Value Stream Mapping - Whenever I am following a process, I try to optimize. Look for the places I'm just waiting, try to identify things to improve etc. I am talking about the most stupid things like the process I follow to lock my bike when I go to work (including where I hang the key after locking, to be able to find it faster when I get out!)

- Continual Introspection - I am continually trying to find better ways of doing things. It doesn't matter whether it is the diswhashing, the path to the train/work or a more serious task. I continually introspect and act on the results.

- Look for the value on the things I do - I started to ask the question "what is the value of this" instead of doing things automatically. This was a big change. I was very used to doing the things they told me to do, not inquiring much on the reasons. Today, I have a much more critiquing attitude.

Maybe, I am going to far, but Beck's TDD book has influenced me in the way I tackle a problem. Before, I wanted to get it all solved in one shot. Now I do it in steps, taking checkpoints in the middle. Other things that I value more now are quality. Bake quality in or do things better. I value communication and I understood the difficulty of it.. What else? Well, this whole Agile world has an impact on our everyday life, right agilists?

Posted by Federico Zuppa at 11:19 PM

Can't image Agile 10 years ago

A few days ago, I was taking an interview to a person that never ever had hear about Agile. All of his life he worked with waterfallish methodologies. So after he explained the way he used to work, we explained him the way we were working. We told him that he had 3 weeks iterations, during which we wrote the tests cases, implemented the user stories and tested them. He looked with an incredulous face and ask: "but do you actually implement that functionality or just think about it?". Wow!!! Right away, I started thinking about those first pioneers and the reactions they must have faced 10 years ago. They must have think they were out of their minds, totally crazy. If I think about it, I would have think the same. Imagine yourseld doing 6 to 12 months projects and all of a sudden someone comes and say we need to this in 3 weeks cycles.. Knowing my limitations, I am sure I wouldn't have understand him....

Has Agile Attacked the Essence?

I was reading Brooks's famous article "No Silver Bullet" and found very interesting the separation of the difficulties of software development in "Essence" and "Accidents". The essence are the difficulties inherent to the nature of software, while the accidents are those that attend its production, but are not inherent.

Has Agile attacked the essence or the accidents?

Definitely not the essense. The essence is the programming language and the way the software is designed. Object Orientation attacked the essence (although I don't think it reached the revolution in productivity Brooks mentions). Domain Driven Design concepts attacked the essence because it deals with how the software is designed. But not Agile...

I was dissapointed. Some Agile practices are more related to the essence, probably the ones that deal with programming like TDD and refactoring but definitely Agile is not the silver bullet :-(
Agile then just handles the accidents in the best possible way.

Anyway, this order of magnitude improvement in productivity will ever be possible?. Cockburn states in his book that "as much as programming languages may improve, programming will still be limited by our ability to think through the problem and the solution". He seems to imply that even if a revolutionary programming language is invented, it won't bring an improvement in productivity without the "accident" (communication, collaboration) being performed well.

As of now I guess Agile represents the best promise in an improvement in productivity. It doesn't promise an order of magnitude (although Schwaber promises like 70% ?) but ...

Which are the promises in the "essence" side?