I love cooking. Graduate school was overseas and the food at both the university's cafeteria and the local restaurant were less than appetizing despite of the great sea food, vegetables, and other goodies available at the market just a mile away, so I decided to take matters into my own hands and stated cooking. To my own surprise cooking was fun and easy; and I was good at it, thankfully because very few times I ate my food thinking I rather be eating at the cafeteria.
Although it is quite rare for me to watch cooking shows I have fun watching Hell's Kitchen. For those of you who don't know the show: there is this famous Chef Gordon Ramsay who recruits 16 contestants (8 women and 8 men) in two teams to compete cooking for guests at the restaurant under the same name as the show and eliminate one contestant from the losing team at the end of each episode. The winning team is treated big time with an outing to an upscale place, and the losing team has to do some quite nasty chores. The most fun part, from my point of view, is when the restaurant opens and the teams have to cook the orders because the entire kitchen turns chaotic very quickly. Food gets burned, undercooked, ingredients are missed, portions of one same dish are prepared at different times, contestants within the same team disrespect each other, customers get quite unhappy... and Chef Ramsay's shouting madly at the contestants until there is no way to save the night and the restaurant is shutdown for the night ahead of time. I don't watch the show all the time but from the couple dozen episodes I've seen out of five seasons service was completed only twice. That success record is embarrasing at the least.
Why does that happen? Both teams have strong motivation to win: not being eliminated and being treated like royalty. So, why things continuously turn bad? Here's my take on it:
- Poor communication: the team members don't communicate with each other to know who is doing what, keep their timings right, and help each other.
- Upfront planning: it would be a waste to plan how the entire evening will go because such plan would become obsolete within the first three minutes of receiving the first order; however they should all have a high-level strategy in place so that they know what to expect from each other.
- Slow to adapt: once one thing goes wrong problems escalate because they have a hard time adapting to the customer demands and the state of the kitchen
- Movement: as things start going wrong and escalate the contestants start moving around a lot more and more quickly. Such frenzy only delays things further and make it so much easier to make mistakes. They should help each other more instead.
- Lack of self-organization: were they better organized among themselves most problems would not occur.
- Lack of respect: Although it is a competition, if they respected each other they would work better as a team and significantly increase the chances of winning
Does that sound to you like what is going on in your organization or what happened at a previous job? I have many memories of projects going wrong for different combinations of the same reasons.
A very effective way to overcome those issues is by following the Agile and Lean principles. Effective communication facilitates self-organization which significantly reduces movement. High-level upfront planning allows the team predict each others actions more effectively and how to help each other. Continuously adapting to the current situation produces more and better results more quickly. And last but no least is the respect for each other, which not only makes working together more enjoyable but also increases productivity.
Saturday, March 21, 2009
Sunday, March 15, 2009
More comments on SDWEST´09
Agile vs. Traditional
On Wednesday, March 11, Scott Ambler and Terry Quatrani gave a fabulous keynote about traditional vs. agile sw dev. The setting was Scott playing a ¨hello, I am PC" role representing the traditional approach, and Terry playing the "hello, I am Mac" role representing Agile. Those of you who know Scott Ambler can very well imagine how hard it was for him to play his role, given the strong advocate to Agile that he is. In a very entertaining fashion and with the help of some images they showed aspects of tradional sw dev and how agile approaches the same issues. Terry's catch phrase for the keynote was "...delivering what the customer wants!"
Scott then proceeded to show some of Dr. Dobb's survey results, showing some eye opening results showing that agile teams do more modeling and generate almost as much documentation as their Traditional counterparts. Maybe more surprising were the results showing that team distribution is less affected by agile than by traditional organizations; i.e., Agile teams have a higher success rate.
Note: Source for the following diagrams was taken from Scott Ambler's 2008 survey via Dr Dobbs. The modeling diagram is a manicured version of the table he published.
Strategy for modeling
Documentation
Success rate
Jolt Awards
The oscars of the software industry. For a list of this year's Jolt Awards visit http://www.joltawards.com/winners.html
On Wednesday, March 11, Scott Ambler and Terry Quatrani gave a fabulous keynote about traditional vs. agile sw dev. The setting was Scott playing a ¨hello, I am PC" role representing the traditional approach, and Terry playing the "hello, I am Mac" role representing Agile. Those of you who know Scott Ambler can very well imagine how hard it was for him to play his role, given the strong advocate to Agile that he is. In a very entertaining fashion and with the help of some images they showed aspects of tradional sw dev and how agile approaches the same issues. Terry's catch phrase for the keynote was "...delivering what the customer wants!"
Scott then proceeded to show some of Dr. Dobb's survey results, showing some eye opening results showing that agile teams do more modeling and generate almost as much documentation as their Traditional counterparts. Maybe more surprising were the results showing that team distribution is less affected by agile than by traditional organizations; i.e., Agile teams have a higher success rate.
Note: Source for the following diagrams was taken from Scott Ambler's 2008 survey via Dr Dobbs. The modeling diagram is a manicured version of the table he published.
Strategy for modeling
Documentation
Success rate
Jolt Awards
The oscars of the software industry. For a list of this year's Jolt Awards visit http://www.joltawards.com/winners.html
Monday, March 9, 2009
Software Development West conference and expo 2009, day 1
This year's SDWest (http://www.sdexpo.com/2009/) is being dominated by tutorials and classes on diverse Agile subjects.
Tutorials and Keynotes
Classes, case studies, and panels
The first session I attended started at 8:30 AM and the last activity ended at 8:30 PM. Needless to say I am happy to be back home relaxing at the couch. Here's some notes on what I attended:
a) Gerard Meszaros gave a tutorial on how things that need to be considered when going from concept to product backlog. Most practitioners have tend to pay attention to the activities closer to the implementation such as stories, use cases, and unit tests; and spend less time, if any, on the what needs to be done to translate the customer's concept into the right design. That is no design is as bad as BDUF because we end up with story blinders. Such lack of functionality not only delays projects but are a source for the need to redesign later on; and under-designing is as bad as over-designing. Projects require an iteration zero to do up-front planning. Five levers need to be covered: Product vision; product roadmap; release plan; iteration plan; and daily plan
b) Robert C Martin, a.k.a. uncle Bob, gave a keynote speech in his usual entertaining and engaging way about the state of the art of XP after ten years of existence (actually more since it started in 1995) . He is quite a showman as a presenter. Taking as starting point the xp diagram he pointed out that scrum covers the outer ring only. Scrum has been extremely successful because it talks at a business level in a way that the business people can understand and makes them more likely to buy in the methodology. The innermost layer is the geeky layer and the middle layer is the glue that sticks the other two together. The success of Scrum has been so tremendous that XP has been falling behind in terms of adoption. This is a very dangerous thing because agile loses effectiveness without good practices. The result is that blindly following scrum leads us to think we are moving fast whereas we are not because over time the cycles become harder to keep up with due to the code being harder and harder to maintain.. This doesn't mean agile is bad; it isn't because it exposes the problems and traditional/waterfall doesn't. What it means is that we need to raise the bar as programmers. This brings the central point of his presentation: we need to develop good software, period. Robert also pointed us to the Manifesto for Software Craftsmanship (http://manifesto.softwarecraftsmanship.org/main) which was put together very recently.
Raising the bar.
Manifesto for Software Craftsmanship As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value: Not only working software, but also well-crafted software Not only responding to change, but also steadily adding value Not only individuals and interactions, but also a community of professionals Not only customer collaboration, but also productive partnerships That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
© 2009
c) Scott Ambler gave a tutorial on Agile Model Driven Development (AMDD) with two focus points:
The negative impact that traditional and waterfall approaches to software development have on productivity, quality, and deliverables. And the importance to drive our agile activities based on practice vs theory. Throughout the entire tutorial Scott went over and over again on the importance to plan and act honestly in the best interest of the success of the product and the organization. Regarding modeling he pointed out that the right model to use is the one that best communicates with the target audience keeping focus on the product's construction with the goal to develop a high quality system. Another important factor for large organizations is scaling distributed teams making sure that the minimum necessary up-front design is made. Note that this doesn't mean BDUF but that a larger amount of design is needed for larger teams than for small and for colocalized teams. Also, for remote teams it is more effective to divide the work based on product features than on job function because that reduces the amount of remote communication needed; although strong coordination will still be needed.
Tutorials and Keynotes
Classes, case studies, and panels
The first session I attended started at 8:30 AM and the last activity ended at 8:30 PM. Needless to say I am happy to be back home relaxing at the couch. Here's some notes on what I attended:
a) Gerard Meszaros gave a tutorial on how things that need to be considered when going from concept to product backlog. Most practitioners have tend to pay attention to the activities closer to the implementation such as stories, use cases, and unit tests; and spend less time, if any, on the what needs to be done to translate the customer's concept into the right design. That is no design is as bad as BDUF because we end up with story blinders. Such lack of functionality not only delays projects but are a source for the need to redesign later on; and under-designing is as bad as over-designing. Projects require an iteration zero to do up-front planning. Five levers need to be covered: Product vision; product roadmap; release plan; iteration plan; and daily plan
b) Robert C Martin, a.k.a. uncle Bob, gave a keynote speech in his usual entertaining and engaging way about the state of the art of XP after ten years of existence (actually more since it started in 1995) . He is quite a showman as a presenter. Taking as starting point the xp diagram he pointed out that scrum covers the outer ring only. Scrum has been extremely successful because it talks at a business level in a way that the business people can understand and makes them more likely to buy in the methodology. The innermost layer is the geeky layer and the middle layer is the glue that sticks the other two together. The success of Scrum has been so tremendous that XP has been falling behind in terms of adoption. This is a very dangerous thing because agile loses effectiveness without good practices. The result is that blindly following scrum leads us to think we are moving fast whereas we are not because over time the cycles become harder to keep up with due to the code being harder and harder to maintain.. This doesn't mean agile is bad; it isn't because it exposes the problems and traditional/waterfall doesn't. What it means is that we need to raise the bar as programmers. This brings the central point of his presentation: we need to develop good software, period. Robert also pointed us to the Manifesto for Software Craftsmanship (http://manifesto.softwarecraftsmanship.org/main) which was put together very recently.
Raising the bar.
Manifesto for Software Craftsmanship As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value: Not only working software, but also well-crafted software Not only responding to change, but also steadily adding value Not only individuals and interactions, but also a community of professionals Not only customer collaboration, but also productive partnerships That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
© 2009
c) Scott Ambler gave a tutorial on Agile Model Driven Development (AMDD) with two focus points:
The negative impact that traditional and waterfall approaches to software development have on productivity, quality, and deliverables. And the importance to drive our agile activities based on practice vs theory. Throughout the entire tutorial Scott went over and over again on the importance to plan and act honestly in the best interest of the success of the product and the organization. Regarding modeling he pointed out that the right model to use is the one that best communicates with the target audience keeping focus on the product's construction with the goal to develop a high quality system. Another important factor for large organizations is scaling distributed teams making sure that the minimum necessary up-front design is made. Note that this doesn't mean BDUF but that a larger amount of design is needed for larger teams than for small and for colocalized teams. Also, for remote teams it is more effective to divide the work based on product features than on job function because that reduces the amount of remote communication needed; although strong coordination will still be needed.
Sunday, March 8, 2009
First Posting! Catching Up
Hello all,
This is my first blog posting so I am formatting it as a catch-up bullet list.
This is my first blog posting so I am formatting it as a catch-up bullet list.
- Mar 3: Software Guru magazine wants me to write an article on Agile for their special issue to be published this summer. I will be writing about Agile and how it fits with standards and models, particularly with MoProSoft
- Feb 1~12: Back to Mexico. Followed up with some companies on deciding to adopt agile. Some of them are still enthusiastic but are yet to decide, in addition that March is the time to plan budget for the year so delays are expected. One government company is going really slow and will need a lot of effort from my side to get them to put the proposal on the right hands for approval. Also had a first meeting with a couple of small companies, both curious to learn more about agile.
- Jan 12~22, 2009: First business trip to Mexico. Gave a presentation on Agile to the Asociación Mexicana de Informática (AMIAC) at the National University of Mexico. There was a lot of enthusiasm from the attendants and most of their question were related to how to make Agile function with standards (ISOs) and models such as CMMI. I met with executives from 3 companies, one of them government, to present my services. Also met with Hanna Oktaba, director of ProSoft, to talk about their MoProSoft standard. The central aspect of the trip was to learn that most Mexican industries are very tightly bonded with standards and small software service companies seem to have no much choice but to abide by those rules. What I found somewhat unfortunate is that there is no much awareness of Agile and its benefits; and although there are some big Mexican companies that already do agile (most of them banks) the existence and use of agile is yet to gain momentum there. On the bright side of things some people showed interest and communication with them is ongoing. In conclusion I realized that it will take a lot of effort to get Mexico to adopt agile.
Subscribe to:
Posts (Atom)