Archive for January, 2009
::
One Smart Cucumber
Wednesday, January 28, 2009
I was messing around with some Ruby stuff tonight and was reading up on the Cucumber project. Cucumber is a behavior driven development (BDD) testing tool.
Anyone who talks to me about user stories knows I’m kind of a stickler on the value statement. I think I’ve found a kindred soul in Aslak Hellesoy, the creator of Cucumber. The following comes from the Cucumber documentation.
You should discuss the “In order to” part of the feature and pop the why stack max 5 times (ask why recursively) until you end up with one of the following business values:
- Protect revenue
- Increase revenue
- Manage cost
If you’re about to implement a feature that doesn’t support one of those values, chances are you’re about to implement a non-valuable feature. Consider tossing it altogether or pushing it down in your backlog. Focus on implementing the MMFs (Minimum Marketable Features) that will yield the most value.
Here is an example taken from an IRC chat session in #cucumber:
[5:08pm] Luis_Byclosure: I'm having problems applying the "5 Why" rule, to the feature "login" (imagine an application like youtube) [5:08pm] Luis_Byclosure: how do you explain the business value of the feature "login"? [5:09pm] Luis_Byclosure: In order to be recognized among other people, I want to login in the application (?) [5:09pm] Luis_Byclosure: why do I want to be recognized among other people? [5:11pm] aslakhellesoy: Why do people have to log in? [5:12pm] Luis_Byclosure: I dunno... why? [5:12pm] aslakhellesoy: I'm asking you [5:13pm] aslakhellesoy: Why have you decided login is needed? [5:13pm] Luis_Byclosure: identify users [5:14pm] aslakhellesoy: Why do you have to identify users? [5:14pm] Luis_Byclosure: maybe because people like to know who is publishing what [5:15pm] aslakhellesoy: Why would anyone want to know who's publishing what? [5:17pm] Luis_Byclosure: because if people feel that that content belongs to someone, then the content is trustworthy [5:17pm] aslakhellesoy: Why does content have to appear trustworthy? [5:20pm] Luis_Byclosure: Trustworthy makes people interested in the content and consequently in the website [5:20pm] Luis_Byclosure: Why do I want to get people interested in the website? [5:20pm] aslakhellesoy:[5:21pm] aslakhellesoy: Are you selling something there? Or is it just for fun? [5:21pm] Luis_Byclosure: Because more traffic means more money in ads [5:21pm] aslakhellesoy: There you go! [5:22pm] Luis_Byclosure: Why do I want to get more money in ads? Because I want to increase de revenues. [5:22pm] Luis_Byclosure: And this is the end, right? [5:23pm] aslakhellesoy: In order to drive more people to the website and earn more admoney, authors should have to login, so that the content can be displayed with the author and appear more trustworthy. [5:23pm] aslakhellesoy: Does that make any sense? [5:25pm] Luis_Byclosure: Yes, I think so [5:26pm] aslakhellesoy: It's easier when you have someone clueless (like me) to ask the stupid why questions [5:26pm] aslakhellesoy: Now I know why you want login [5:26pm] Luis_Byclosure: but it is difficult to find the reason for everything [5:26pm] aslakhellesoy: And if I was the customer I am in better shape to prioritise this feature among others [5:29pm] Luis_Byclosure: true!
I was impressed to find that section in the documentation. Not only do the docs detail basic usage but they go into the deeper discussion of how to apply agile principles using Cucumber. The balancing act of teaching principles and practices at the same time is no small feat. To find that in software documentation is pretty amazing.
P.S. One of my worst titles ever, I know. I think I was subconsciously inspired by the Hallmark Movie my wife had on a couple nights ago. I now realize I missed my calling as a greeting card writer.
Topics: Agile, Software Development | 1 Comment »
Quote from EC: “I thought to myself, ‘How is a kid with sticks like that going to get across the ice?’”
Wednesday, January 28, 2009
My eight year old son’s comment last night at dinner about watching a boy at school on crutches, walk out to the bus on the sidewalk, which had just been coated with a thin sheet of ice. The conversation last night was filled with a number of my son’s comments starting out with “I thought to myself…”. My wife and I decided it’s probably not a bad trend, this keeping his thoughts to himself. 
Topics: EC Quotes | No Comments »
10 Questions to Think About Before Adopting Agile
Tuesday, January 6, 2009
Agile. Everyone is doing it, so should you, right? Not so fast. Even though it’s being sold as a silver bullet by various vendors and consultants, agile is far from easy. In fact, I’d argue that adopting agile is harder than moving to a process heavy software development methodology. At least with the process heavy approach you have the how-to guide. Agile is as much about attitude as it is about anything else. And a company’s attitude is found in its culture. Companies with cultures that clash with agile are not likely to succeed in adopting agile.
The following is a list of questions I think anyone considering the move to agile, whether company wide or at a smaller scale, should ask before moving forward.
- Is your company policy driven?
If employees feel inundated by policies, watch out. There is nothing wrong with policies, but a company driven by policies is likely to be at odds with agile values and principles that support people interacting with one another over contracts, documentation, and processes. A company culture overrun by policies struggles to trust its employees to make good decisions without heavy handed tactics. - Does your company encourage identifying and eliminating its stupid practices, policies, and processes?
A company culture that encourages, at all levels, the elimination of the stupid things the company does will have no problem latching onto agile’s principles concerning change. Don’t have a culture like that? Good luck with accepting and embracing change in a manner agile demands. - Is the contract king at your company?
Contracts come in all shapes and sizes. Some contracts are legally binding documents between two parties, like a service provider and its customers. Other contracts are less obvious but more prevalent, like change request forms and requirements docs. A CYA approach by employees is often a result of a “contract is king” company culture. Welcoming changing requirements and customer collaboration are agile values and principles that are next to impossible for a “contract is king” company to adopt. - Is “on time and on budget” your company’s best measure of project success?
Agile promotes continuously delivering working software that is valuable to the customer. When delivering on time and on budget is the key measurement to a project’s success, it misses the most important point: value. And this all gets back to our previous question of contracts. Companies that value “on time and on budget” the most as a measure of project success are often the same ones that depend on the contract to determine value, not whether the project truly does deliver something the customer wants or needs. This isn’t to say that agile cares little about time or budget, quite the contrary. Agile focuses on delivering value early and often. - Would a fair description of your company’s structure be one of tribes at war with one another?
A great book to read to get an understanding of what I’m talking about here is Great Boss Dead Boss by Ray Immelman. Examples of warring tribes include production versus sales, engineers versus marketers, accounting versus purchasing, etc. Most of us remember the high school cafeteria and the cliques that form. Most of us laugh at how absurd the cliques got, yet too many of us grow up and create even more absurd cliques in the business world. Agile demands constant communication between people and focusing on the customer. You cannot succeed at either of these if your company is made up of factions of tribes. A company needs to be one tribe striving for a common goal. - Are simple solutions ignored within your company?
Simple is hard and yet agile calls for simplicity. Company cultures that struggle with promoting simple solutions are often the same ones that “try agile” for a bit and abandon it because “agile doesn’t scale”. Also, companies that are in love with solving huge problems with complex solutions often struggle with simplicity. Simple is, well, too simple for these companies. - Does your company advocate and live by the “No Asshole Rule” (in principle, if not by name)?
My apologies if the language offends. I find the behavior and acceptance of such individuals within an organization more offensive. Companies that do not adopt this rule will struggle mightily with agile. Individuals who are grownup bullies in the workplace will make sure that anything like agile, which encourages everyone involved to make good things happen, fails in spectacular fashion. - Is “corporate speak” the primary language spoken at your company?
Communication is key to everything, let alone agile. Being able to reflect and adjust behavior is also key in agile. Speaking in a language that doesn’t say much at all is a serious roadblock to effective communication. Corporate speak is also a sign that a company’s culture may value style over substance. Style can come in the form of fancy documentation but little working software. - Do the people at your company enjoy working there?
Don’t show me the survey done by such and such publication. Those are nice awards to put in the job postings but the real deal is found amongst the people on a day-to-day basis. The vibe of the workplace is hard to miss. Motivated people who feel empowered to get the job done are critical in successfully adopting agile. A place where the people don’t enjoy working for the company doesn’t fit this bill. - Do customers enjoy working with your company?
Customers who go out of their way to say nice things about you because of how much they enjoy your company and its products/services trust your company and are going to want to make good things happen together. Agile is all about working closely with the customer. If customers don’t enjoy working with your company now, there is no magic agile pixie dust to make them enjoy working with your company when it adopts agile.
Some might argue that adoption of agile is an answer to these questions. That may be true, but I have my doubts. Company culture is what needs to change in most cases. Changing company culture in a positive way is difficult. The temptation for many of those considering the adoption of agile is to think of it as just another methodology, process or set of practices that can be adopted. Those taking this path are almost certain to fail. With that failure will come much finger pointing. Agile didn’t scale. Agile wasn’t disciplined enough. Agile is missing X, Y, and Z. Agile simply didn’t work. In reality, agile was never understood and never a good fit from the beginning.
Topics: Agile | 4 Comments »
::