Monday, December 27, 2010

New Year's Resolution: Get Fit Using Agile Workstations

*NEW* FitDesk Space Saving Semi Recumbent X Bike for Laptops and GamingEvery New Year, I come up with a New Year's resolution list, and it almost always includes getting in better shape by joining a gym. Unfortunately, I never seem to follow through on it. But how about getting fit at work by using an Agile Workstation?

Soho Adjustable Computer Workstation - BlackMedium CherryRecently, Matt, a colleague of mine, setup a make shift standing work station. He stacked some books on top of some boxes to lift up his keyboard and mouse. He also placed his monitor higher up on a shelf. His argument was that this gives him better posture and reduces neck pain and is better for his overall health. Everyday he codes standing up for about 2 to 3 hours and then goes back to a more traditional seated coding position.

This reminded me of a presentation given by Doug Bradbury at Agile 2010 entitled “Walk and Code”. Doug presented data that showed that we sit significantly more and stand significantly less on our work days than on our leisure days. Another study showed that obese individuals were seated on average 2 hours longer per day than lean individuals. Yet another study showed that men and women had a 17% and 37% higher chance of death when sitting more than 6 hours per day as compared to those sitting less than 3 hours per day. When we factor in sitting and not exercising then the numbers jump to an alarming 48% and 95% respectively. So clearly we need to exercise during our work week. But does standing or walking count?

Walkstation Height-Adjustable Desk and TreadmillDoug next describes the research done by Dr. James Levine on non-exercise activity thermogenesis (NEAT) which is the calories people burn during everyday activities like walking, standing or even fidgeting. Dr. Levine is studying the effect of NEAT on energy expenditure and overall good health. Simply walking at a slow 1 mph can burn an extra 100 cal/hr. Dr. Levine came up with an adjustable treadmill desk where people can walk and work, stand, or sit. He believes this can help in both health and productivity as people stay motivated, alert and focused. However, this adjustable workstation cost $4000+.

TrekDesk Treadmill DeskSo like Matt, Doug setup his own make shift treadmill/desk by buying a used treadmill from ebay and a desk from IKEA. After 22 weeks he had walked 240 miles (average of 11 mi/week) by just walking and coding!

So are you up for it? I found a treadmill desk add-on on amazon for $400. If this all sounds too extreme and expensive then try replacing your chair with an exercise ball or bicycle, or simply take the stairs instead of the elevators, park far from the office, and take a walk at lunch. Good Luck and Happy New Year!

 
TKO Anti Burst Fitness Ball Set 65cm
To learn more about NEAT check out http://mayoresearch.mayo.edu/levine_lab/about.cfm

To find out more on how Dough constructed his workstation, check out his blog http://blog.8thlight.com/articles/2010/2/25/walk-and-code

Here are links to studies referenced in Dough's presentation:

http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2783690/
 and http://aje.oxfordjournals.org/content/172/4/419.abstract






Wednesday, December 15, 2010

The Ultimate Wall Board



What’s on your wall board? Atlassian ran a competition for the ultimate wall board. Ole Højriis Kristensen from the Vodafone web team won the competition by integrating a physical Scrum board with Atlassian’s JIRA/Greenhopper issue tracking/PM tool.

Ole’s solution keeps the physical board in sync with their project management tool. He setup a printer below the scrum board. Whenever a new story is added to JIRA, a card is printed out with a reference to the JIRA ticket number. This receipt is then placed in a plastic card that has an RFID and a magnet and then the card is placed on the board.

Whenever a developer is ready to work on a story, the developer swipes the card and moves it to the next column. They also have avatar cards for each developer that they swipe to indicate who is assigned to the story. Any card movement on the board automatically updates the corresponding story in JIRA. A camera snaps a picture of the developer that is moving the card and it is attached as a comment to the JIRA issue indicating who modified the ticket. The board also kicks off the build/deploy process for stories that are ready for testing and sends out tweets to inform the team and QA. There is also a projector that continuously displays burn down charts and velocity from JIRA data.

Even when an issue is updated directly through JIRA, the board constantly reminds users (via voice prompts) to move the corresponding card to its correct position!

Additional awards were given to a couple of other boards. Check them out at http://ultimatewallboard.com/

Thursday, October 14, 2010

Agile Mythbusters

It’s Family Fued meets Myth Busters at an Agile 2010 presentation given by Scott Ambler. Scott explores surveys from Ambysoft and Dr. Dobb’s Journal to expose some myths about agile software development.

Below is a brief summary of some of the survey results:

Busted:
MythSurvey Says
Agile teams don’t provide up front estimates.More than 60% present high level estimates using expert analysis or agile estimation techniques.
Agilists don’t do upfront requirements modeling.About 80% use documented approaches.
Agile teams just start coding.On average agile teams take about 4 weeks to warm up.
Agilists don’t do upfront architecture.About 80% use documented approaches.
Agilists don’t write supporting documentation.Agilists write user manuals, training materials, system overview, and operations documents.
Traditionalist write better quality documentation.Quality agilists’ documentation is the same.
Most agile teams are collocated.42% are collocated while the rest are not and about 30% are distributed by a significant distance.
Traditional work better for distributed teams.Agile works better for both collocated and distributed teams.
Agile is just for small teams.Even though the majority of teams doing agile are small, there are large teams doing agile as well.
Traditional works better for large teams.Agile works better for small, medium, and large teams.
Most Agile teams are doing Greenfield development.Most teams are working and integrating with legacy systems.
Agile doesn’t apply to regulatory situations.About 30% reported using agile in regulatory situations like for example, SOX and HIPPA.
Agile works better than iterative (xUP) approaches.Success rates are the same, but agile may provide greater ROI.


Confirmed:
MythSurvey says
The majority of organizations are now doing agileAbout 70% are doing agile.
Agilist test often and test earlyThe majority is doing TDD, regression testing, and code reviews.
Agile works better than traditional approachesAgile provides higher quality, quicker delivery, correct functionality, and greater ROI.


The full survey results are available at http://www.ambysoft.com/surveys.

Friday, October 8, 2010

APLN DC - The Art of Storytelling

Thanks to all that made it out to my presentation on the Art of Storytelling at APLN DC. Below is the slide deck + notes.


Wednesday, September 22, 2010

Accelerating Your Organization’s Agile Adoption

Bryan Campbell and Robbie Mac Iver gave a talk at Agile 2010 about Agile Adoption. They started out by discussing how acquiring a skill requires time, practice and a mentor. They then defined 7 stages of agile expertise based on the work of Meiler Page-Jones:

  • Innocent: unaware of agile techniques
  • Aware: aware and seeking to learn more
  • Apprentice: ready to apply their skills to a real project
  • Practitioner: leap from classroom projects to those of real world complexity
  • Journeyman: agile techniques embedded natural way of working
  • Master: range of real-world project experiences; ability to teach these techniques to Apprentices
  • Researcher: sharing knowledge with a broader community; champion to further extend the benefits of agile techniques

Next they identify the risk and challenges from moving from one stage to the next. Moving from innocent to aware can happen fairly quickly. Moving from apprentice, to practitioner, to journeyman requires more effort and will take longer; however, it is during these stages that you get the greatest increases in productivity. Reaching the master and researcher stage will take even longer and not many companies see value in having employees reach this level. The tipping point is usually when more than 50% of the organization is at the practitioner level and more than 75% is operating at the apprentice level.

Next Bryan and Robbie discuss the J-curve effect where an apprentice struggles in adapting his new skills to real situations and reverts back to old techniques. This causes a dip in the skills progression which results in a decrease of productivity and a risk that crossing to the next level might stall or eventually fail. This is where having access to an experience coach or mentor is crucial to overcome the J curve and achieve a successful agile adoption.

Bryan and Robbie recommend 2 techniques that can help accelerate agile adoption:

  • The Breadth approach focuses on developing a solid foundation of best practices and refining them over time. This works best in the move from innocent to aware, or from practitioner to journeyman.
  • The Depth approach is focused on a more active engagement/participation of mentors on a real project. It is more of a deep dive and is best for crossing the J-curve from apprentice to practitioner.

They next cover agile leadership guidelines. They recommend

  • Addressing culture and values first and then practices will generally follow
  • Working in ways that embrace change and adjusting methods to fit the project
  • Creating teams of advanced citizens to ensure team dynamics
  • Influencing team decisions by setting movable boundaries

Bryan and Robbie wrapped up by presenting each group with different real life scenarios and having each group discuss different ways of resolving them.

The scenarios can be found at http://www.robbiemaciver.com/documents/presentations/A2010-Agile%20Maturity%20-%20Problem%20Scenarios.pdf

The presentation slides are available at http://www.robbiemaciver.com/documents/presentations/A2010-Agile%20Maturity%20-%20Presentation.pdf

Sunday, September 12, 2010

The Curious, Present, and Empathetic Agile Coach

Presence-Based Coaching: Cultivating Self-Generative Leaders Through Mind, Body, and HeartAt Agile 2010, David Spann and Gil Broza gave a workshop on agile coaching. The workshop involved several exercises to stress the importance of presence, curiosity and empathy.
They started out by emphasizing the importance of good posture when engaging a client. Posture subconsciously sends message of energy and others will check in or check out based on that. When standing, stand in with right foot in and always feel your toes. When sitting, sit up straight and also feel your toes. If things are not going your way, know your presence and adjust accordingly. They also reminded us that standing up is a power high energy position. It means you are involved.
Next, David and Gil define empathy as repeating in your own words what was said, mirroring hand gestures, and not trying to pass judgment at the moment of interaction.
The Leadership Dojo: Build Your Foundation as an Exemplary LeaderFinally, curiosity involves asking questions and figuring out the context. They wrap up by recommending several books:
Presence Based Coaching
Leadership Dojo
Coaching with NLP: How to Be a Master CoachCoaching with NLP

Wednesday, September 1, 2010

Look Before You Leap - Agile Readiness Assessments Done Right

At Agile 2010, Gerry Kirk and Michael Sahota led a workshop on Agile assessments. The format was more like an open space discussion where Gerry and Michael started out by asking the group to come up with some objectives for having an assessment:
  • Tuning of training according to needs
  • Maximizing value and effectiveness of training
  • Revealing constraints, building trust
  • Finding out motivations for going agile
  • Figuring out pain points
  • Deciding where to focus
  • Understanding fears smell
  • Understanding the state across of the organization
  • Defining success
  • Figuring out where the organization is currently at and their current practices
  • Setting the right expectations
  • Making the transition owned internally
Next Gerry and Michael suggested a format for the assessment and define 4 parts: Preparation, Data collection, Analysis, and Recommendation and next steps. They suggested that each group brainstorms and comes up with ideas for all the parts. They started us out with the following examples:
  • Prepare: 12 question survey from break all the rules
  • Data analysis: Lean value stream mapping with x-functional work group to show process and lead time
  • Analysis: From interviews write stickies for culture, technology, product, people, process
  • Recommendation and next step: Meet with key decision makers and workers to create a transition backlog

Next, each of the groups tried to come up with their own ideas but non where as detailed as the ones provided by Gerry and Michael. Below is a summary of what the teams came up with

Prepare:
  • Prepare checklist for us and the client
  • Conduct outside research on organization
  • Learn the organizational structure
  • Identify sponsors and stakeholders
  • Find a champion
  • Prepare non attribution statement
  • Present readiness and process group
  • Establish point of contacts for all logistics
  • Conduct survey to figure out current process
  • Conduct Schneider culture survey
  • Conduct a survey to gauge urgency for change and current company health
  • Compile a list of various articles, videos on agile introductory topics
  • Present a related experience report
  • Get organization aware of agile through training

Data collection:
  • Meet the team and the leaders
  • Observe the team at work and identify the different roles
  • Identify and document current agile practices
  • Identify and document current agile non practices
  • Document the current approach for managing and organizing work
  • Document the goals of the movement to agile from execs to team members
  • Create a baseline metric

Analysis:
  • Determine waste in value stream map
  • Perform Kano analysis on techniques
  • Try to identify potential pilot project and pilot team
  • Look for feelings by team
  • Look for variation in perspective
  • Distill interview into mindmaps
  • Look for often mentioned bottle necks
  • Perform futurespective (innovation game)

Recommendations and next step:
  • Create statement of work on improvement goals
  • Create cross functional transition team and backlog
  • Establish target metrics
  • Create training plans
  • Create transition timeline with goals
  • Have a workshop for executives to share findings
  • Establish ground rules and agreement
  • Perform retrospective to improve future assessments

This is all very much a work in progress and Gerry and Michael are going to continue to gather ideas and eventually publish an assessment guideline.

Saturday, August 14, 2010

Project Vital Signs

The Thoughtworks Anthology: Essays on Software Technology and Innovation (Pragmatic Programmers)At Agile 2010, Stelios Pantazopoulos gave a presentation on project metrics entitled “Project Vital Signs”. Stelios starts by pointing out that IT has lost trust and credibility with the business due to projects having a poor track record of success, poor visibility and ROI that is hard to quantify. Projects are over budget, late, or fail all together. To restore trust and credibility, we need to show how and why a project is on track throughout the project’s lifecycle.
Stelios, suggests applying the metaphor of medical care and their use of “vital signs” to help form a holistic view of the state of the project. In medicine, doctors go over the patient’s medical history, review lab test results, look at vital signs, and then use their experience to diagnose the condition and recommend a treatment. Stelios defines vital signs as simple, quantitative, near real time metrics conveyed via a chart published to a location and easily referenced by all. There are 5 vital signs that need to be monitored. 4 are based on PMBOKs Scope, Quality, Schedule, and Budget. In addition, Stelios feels that monitoring the team’s overall health is also very important.
The 5 charts are:
  1. Scope Burn Up: Backlog burn up chart (stories in each state vs. time) that tracks schedule and scope to show expected delivery date. Number of stories or story points are be tracked. Stelios mentions that if you have a big enough back log, tracking number of stories worked well for him.
  2. Current State of Delivery: Backlog Scrum board that tracks scope and team and shows real time state of delivery. Tracks the state of each story and who is working on which story.
  3. Budget Burn Down: Burn down chart (total $ vs. time) that tracks schedule and budget to show remaining dollars.
  4. Delivery Quality: Dot Chart (bug category vs. time) that tracks schedule and bugs to show overall quality. Bugs are categorized into 4 categories:
    1. High priority/High severity
    2. High priority/Low severity
    3. Low priority/High severity
    4. Low priority/Low severity 
    At the end of each iteration, each bug is represented as a dot in the corresponding category. Ideally, as the schedule nears release date, most bugs should fall into the low priority categories. Stelios also mentions that alternatively one can track automated test results as opposed to bugs.
  5. Team Dynamics: Chart (state vs. time) that tracks the state of the team and schedule to show the state of team at different stages of delivery. The state is collected in the retrospective by asking team member to have a secret vote on where each feels they are on the Tuckman model of group development (forming, storming, norming, performing). Similar to the delivery quality chart, each team member’s opinion is represented as a dot in the corresponding category.

The 5 project vital signs are combined to create a project dashboard that is placed on the wall for high visibility. Stelios wraps up by going through different sample scenarios and demonstrates how the dashboard provides a holistic view of the project. He then diagnosis the project and performs what if scenarios for different treatments showing the state of the project before and after treatment.

Stelios provided the slide deck for the presentation at http://projectvitalsigns.com/

Wednesday, August 11, 2010

Agile Coaches Dojo

Agile CoachingAt Agile 2010, Rachel Davies gave a workshop on Agile Coaches Dojo. The Dojo was modeled based on the developers dojo where a bunch of developers get together to solve a challenging programming problem. The group collaborates to solve the problem and along the way learn new tools and techniques.

In the Agile Coaches Dojo, instead of solving a coding problem, coaches solve a challenge faced by an agile coach. Rachel recommends the following format for the dojo:

A seeker presents a specific challenge to 3 coaches. The coaches each take 5 minute turns to discuss the problem with the seeker and provide advice. Meanwhile, 2 to 3 observers take notes documenting interesting perspectives while a facilitator ensures the dojo moves along smoothly. At the end of the discussions, the group has a 5 minute retrospective on what went well in the dojo and what did not.

The Agile coaching Dojo gives participating coaches a chance to see how other experienced coaches tackle the same situation based on their own personal style and reactions to different context.

Tuesday, August 10, 2010

Building a More Accurate Burndown Using Range Estimation in Scrum

At Agile 2010, Arin Sime gave a presentation on how to build a more accurate burndown. Arin started by asking how long does the drive to work take? Various answers were given (15 minutes, 8 minutes, 45 minutes, 20 to 30 minutes). Arin pointed out that some estimate were precise but might not be accurate (for example 8 minutes, but what if we hit traffic?). Other estimates were less precise but allowed for more accuracy (20 to 30 minutes). He mentions that single point estimates are a problem because we tend to be overly optimistic and use different methods or have different biases. He then presented a scenario and asked if we can build a CMS website within 2 weeks. Some answered simply yes or no while other asked for more info and then gave a range of 3 to 4 weeks. The point was that even though a range was a better answer, the original 2 weeks presented in the question created an anchor for the response and any answer will be close to that range.

Arin moves on to discuss Scrum and mentions how Scrum uses planning poker to generate a consensus group estimate, and how using story points ensure relative estimates. However, estimates are still a singe point. Range estimates recognize uncertainty, alleviates our tendency towards optimism, incorporates risk, allows for better financial projections, and better informs our bosses and clients.

Arin then demonstrates how he uses range estimates. Basically, he still uses planning poker with his team, but each team member now raises 2 estimates. The team still discuss differences between low and high estimates, but eventually settle on a range between the 2 estimates. On the sprint burndown chart, both the high and low estimates are tracked. A 3rd estimate (the 2/3 of range estimate) is also tracked. Now the chart shows an ideal burndown and a low and high deviation limit. The actual burndown should fall somewhere in between this range

Arin warps up by warning against some pitfalls of using range estimation. He mentions that not everything can be estimated using a huge range otherwise you will lose all credibility. Try to meet the ideal estimate and don’t use the high estimate as an excuse to miss deadlines. He also stresses on always using the range estimate and not slowly moving back towards relying on the single 2/3 estimate.

Arin provided the slide deck for this presentation at http://www.slideshare.net/o19s/range-estimation-in-scrum

Effective Questions For An Agile Coach

Arto Eskelinen and Sami Honkonen gave an agile coaching workshop at Agile 2010. They presented the GROW framework in which coaches can structure effective questions. They started by stressing that sustainable change has to come from inside and as coaches we should not be tempted to give advice but instead create better awareness to help the team take ownership and feel empowered. They recommend favoring what and when questions and recommend avoiding how, who and why questions. The goal is to keep things at an observatory level and not at the analytical level.

The GROW structure provides questions that lead to exploration, aim at descriptive answers, avoids judgment, and avoids an unproductive state of mind. The idea is to look at the goal 1st, then look at the current situation, and analyze what are possible ways to move forward. Finally, make a decision and follow through.

Arto and Sami describe each stage of GROW as:

1. Goal: A description of the desired or ideal state. Make sure it is meaningful and specific and stated in a positive way (use: Catch the ball vs. don’t drop the ball). Ideally, how would you like things to be? What will you get out of it? What do things look like when we get to that ideal state?

2. Reality: A description of the current state? Try to expand coachee’s view of the situation by testing current assumptions, exploring different angles and exposing feelings to different situations. Do not be tempted to just gather data and make a decision. Try to ask questions that lead to moving away from reality and lead to exploring and seeing things from a different angle. What if we have more time? More people? What does the other team see in this situation? What does this solution feel like?)

3. Options: State the existing ideas (how would you solve this?) and challenge the limitations (if this limitation was not there, what would you do?). Also, make sure to discuss “stupid” ideas. These might lead to exploring other interesting angles that were not considered before. Try to have at least 3 options to consider. Keep asking: what else? Until there are enough good option to evaluate.

4. What will you do? The last step is evaluating the options and formulating and action plan. Make sure a timeframe is set, obstacles are removed, uncertainties are cleared and done is defined. What are you going to do? When are you going to start and how do you know when it’s done? Are there any obstacles? What prevents you from achieving your goal? On a scale of 1 to 10, how do you feel about this solution? If they answer 8, then ask what is stopping it from being a 10.

A questions checklist is provided at Sami’s site at http://sami.honkonen.fi/checklists.pdf

Tuesday, July 27, 2010

Distributed ScrumMasters

At the August DC Scrum user group meeting, David Bland gave an Agile2010 preview presentation on Distributed Scrum and the Art of Digital Facilitation. David recommends trying to use light weight tools even in distributed environments and emphasizes concentrating on the process as opposed to the tool. He also recommends video conferencing over phone/email/IM.

One very interesting point that David discusses is dealing with the Daily Stand up across different time zones. David mentions that the 3 questions have to be re-phrased when working across major differences in time zones so that

1. What did you do yesterday?

2. What will you do today?

3. What’s in your way?

becomes:

1. What did you do today?

2. What will you do tomorrow?

3. What’s in your way?

So due to the difference in time zones, one team (A) is talking about what they will do today where as the other team (B) is about to go home and is talking about what they already did today. David emphasizes that the product owner and scrum owner must quickly address any issues that team B bring up, otherwise, team B will come in the next morning without clear guidance on the stories or priorities and with impediments still blocking progress. Team B will have to wait almost the entire day before the next Daily stand up and before getting any updated guidance from the product owner. Having the product owner address any issues while team B is asleep ensures that team B will be productive first thing in the morning.

You can follow David on his blog http://www.scrumology.net and view the presentation slide deck at http://www.slideshare.net/7thpixel/distributed-scrum-masters-d-bland-agile2010.

Saturday, July 10, 2010

The Waterfall Manifesto

In a recent blog entry entitled Beyond the Manifesto, I discussed the different agile related manifestos that came out after the Agile Manifesto. Today, I found one that I had missed entitled the Waterfall Manifesto by the Waterfall Alliance!

It states:

Our experience has taught us to value:
  • Processes and tools over individuals and interactions
  • Comprehensive documentation over quality software
  • Contract negotiation over customer collaboration
  • Following THE initial plan over responding to change
Check it out at http://www.waterfallmanifesto.org/

Monday, July 5, 2010

Defect Reduction Cocktail

The Art of Agile Development
In a recent presentation, James Shore introduced the Defect Reduction Cocktail to continuously produce quality software. The equal parts of the cocktail address 4 types of errors:
  • Programming Errors: Test driven development, pair programming, energized work.
  • Requirements Errors: On site customers, customer examples, Bring testers forward, customer reviews.
  • Design Errors: Slack, simple design, incremental design, refactoring, fix bugs promptly.
  • Process errors: root cause analysis, fix your process, exploratory testing.
Find out more at
http://jamesshore.com/Blog/Alternatives-to-Acceptance-Testing.html
http://jamesshore.com/Agile-Book/no_bugs.html

Wednesday, June 30, 2010

Java vs. Net

So which platform is better? Is it Java or .Net? The answer might be in this new movie coming soon to a theater near you. Check out the trailer.

Friday, June 25, 2010

Code Leaders and Beautiful Teams

The Art of Unit Testing: With Examples in .Net

At QCON London 2010, Roy Osheroveshared shared his experience of working on great teams.

He discussed things that good teams do:
  1. Automate everything: Configuration, deployment, builds, and tests.
  2. Test and buy the right tools: automation tools, bug management, source control…
  3. Throw out the wrong tools.
  4. Master your tools: shortcuts, macros, refactoring.  A good exercise is to try working without a mouse for a couple of hours.
  5. Get quick continuous feedback from tests and CI, from customers, from peers
  6. Show big visible process: Have a whiteboard.
  7. Communicate without meetings: stand-ups, pair programming, peer code review, team rooms, and visual progress.
  8. Visual board: Create a metaphor for your system and put inside it the components of the system and color code each process.
  9. Code reviews and test reviews before every check-in.
  10. Build by feature and not by layer.
  11. Small team, same room, big feedback.

Then Roy covered things that good team leaders do:
  1. They are bottleneck ninjas. Sit in the same room as your team. Be aware of the conversations going on and problems that arise and step in when necessary.
  2. Grow people with integrity.
  3. Remove obstacles and help the team on how to remove their own obstacles. Ask them to find solutions.
  4. Connecting it all.

Roy recommends that these be used as a check list and be reviewed on a daily or weekly basis so that the team and the leader continue to improve.

Thursday, June 17, 2010

How about a Game of Ping-Pong at Work?

That's ping pong programming of course. It's a combination of Test Driven Development and Pair Programming. The 1st developer writes a test and then passes the keyboard to the second developer who writes enough code to make the test pass and then writes a second test and passes the keyboard back to the 1st programmer who in turn writes enough code to make the second test pass and then writes a third test and so on. This keeps both developers involved and focused. What do you think? Ready to give it a try?

Thursday, June 10, 2010

Bad Code, Craftsmanship, Engineering, and Certification

Clean Code: A Handbook of Agile Software Craftsmanship
At QCON 2010, Robert Martin gave a talk about Bad Code, Craftsmanship, Engineering, and Certification. Uncle Bob started the talk by showing an example of bad code which consisted of two massive classes with hundred of methods. He asked why do we write bad code that we know will impede us? And wondered if it is due to deadlines, laziness, boredom, or job security. Bob stresses that the way we go fast as professionals is to do the best job we possible can. He encourages us to wear a green band on our wrist that symbolizes a commitment to write the best code we can at all times.

Uncle Bob then makes the following recommendations:

1.      Apply the boy scout rule: Always leave the camp ground cleaner than the way you found it. That is, whenever you work on a class or function, spend some extra time to refactor it and clean it a little.

2.      Apply Extract till you drop: Function size should be small. Keeping extracting until you can no longer extract the function. This takes all the concepts in the function puts them in well named places.

3.      No argument is the best argument. Functions should have the smallest number of arguments possible. Try not to exceed 2 arguments. Do not pass Booleans as arguments; instead create two well named functions.

4.      Use long names to be as descriptive as possible.

5.      Avoid duplication. Do not copy and paste.


Next Uncle Bob goes over the Software Craftsmanship Manifesto which states:

1.      We value not only working software but also well crafted software

2.      Not only responding to change, but also steadily adding value.

3.      Not only individuals and interactions, but also a community of professionals.

4.      Not only customer collaboration but also productive partnerships.


He then covers the disciplines that the manifesto is based on. These include:

1.      TDD – verifies that our code works and also makes it possible for us to refactor and constantly improve the code over time.

2.      CI: Use tools like Hudson, CruiseControl, Bamboo, and TeamCity. If the build fails, immediately fix the build.

3.      Pairing: If you don’t want to code pair, at least make sure the team is communicating, sharing and working closely together.

4.      QA should find nothing

5.      Have pride in workmanship

To convince others, the best thing you can do is do the best job you can and be a role model. Soon others will observe that you are outperforming the rest and will realize why.

Uncle Bob next covers the engineering practices of small cycles feedback, source code as the design, and design patterns. He wraps up by discussing certification and how they over promise and under deliver. Instead he recommends actually talking to potential new hires and have several team members talk to them as well. Let them show you code samples. Ask for references and check those references.

This presentation is available on InfoQ at http://www.infoq.com/presentations/Robert-C.-Martin-Bad-Code

Monday, May 31, 2010

Sustainable Test Driven Development

Growing Object-Oriented Software, Guided by TestsAt QCON, Steve Freeman gave a talk on Sustainable Test Driven Development. Steve show examples of bad tests and gives us advice on how to write good tests that make development easier and easy to maintain. Steve recommends the following:

1. Test Readability: Make sure the tests are readable.

2. Test features and not implementation: Do not write a test for each method in a class, but instead write test for specific features and behaviors.

3. Use helper messages to remove noise and be more expressive.

4. Use self describing variables.

5. Use test data builders that fill in defaults for values not specified.

6. Test the what not the how.

7. Always add message in the assert to explain the test.

8. Overload toString to get descriptive error messages.

9. Specify precisely what should happen and no more.

10. Avoid brittle tests like hardcoding values. For example, when trying to assert for auto-incremental id values, simply test that the value got incremented instead of asserting against an actual value.

Test Driven Development: By Example11. Only enforce order of methods when it matters.
Steve concludes that tests are code too. They need all the same care and attention given to code. Tests need to focus on what matters. We should value expressiveness over convenience and make sure the tests are readable. If a class is hard to test then it’s a clue that our code is too complex.

This presentation is available on InfoQ at http://www.infoq.com/presentations/Sustainable-Test-Driven-Development

Tuesday, May 25, 2010

You Say Tomato, I Say Pomodoro

The Pomodoro TechniqueThe Pomodoro technique (Italian for tomato) is a time management technique created by Francesco Cirillo. The technique uses a timer to break down periods of work into 25 minute intervals separated by breaks. It is based on the idea that frequent breaks can improve mental agility.
The technique uses a form of timeboxing and relates well to Scrum and other agile methods. The process is as follows:
Pomodoro Technique Illustrated: Can You Focus - Really Focus - for 25 Minutes? (Pragmatic Life)
1.    Choose a task to be accomplished
2.    Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
3.    Work on the task until the Pomodoro rings, then put a check on your sheet of paper
4.    Take a short break (5 minutes is OK)
5.    Every 4 Pomodoros take a longer break

Tuesday, May 18, 2010

Splitting Stories

Agile Estimating and PlanningMike Cohn provides guidelines on splitting stories in his books Agile Estimating and Planning as well as User Stories Applied. Stories need to be split as they rise to the top of the product backlog and near implementation. Some reasons for splitting a story are:

1. Size – Too big
    • a. Cannot give an accurate estimate: A story needs to be more manageable and enable a more accurate estimate.
    • b. Cannot fit into an iteration: If for example an iteration is 1 week long and the story in longer than a week then it needs to be split to fit into the iteration.
    • c. Cannot fit into what’s remaining of an iteration: A team has already committed to 38 story points and there is still room for a 2 point story but the remaining stories are 3 story points or more.
  • 2. Dependency: A story is dependent on another story. This makes it hard to give a correct estimate. The story needs to be split where one story handles the dependency and the others handle the specifics.
  • 3. Risk: A story is complex and risky. The story needs to be split to create a spike story which is experimental in nature and its main goal is to gain technical knowledge.
  • 4. Compound: A story contains multiple sub stories that are large enough to stand out on their own.
Succeeding with Agile: Software Development Using ScrumSome of the techniques for splitting stories include:
  • 1. Along data boundaries: For example, separate local requirements from international requirement, or handling one type of credit card from another.
  • 2. Operational boundaries: This typically is done along CRUD boundaries where for example a story is split into 3; one to create an entity, one to retrieve and update an entity, and one to delete an entity. Another example might be separating a story into search which simply return search result count and then search display which displays the actual results of a search.
  • 3. Cross Cutting Concern: Features that effect multiple aspects of the application like security, logging, error handling can each be separated out of main functionality features. For example, a screen that will have different menu options or links based on the login user’s credentials. This security specific feature can be split from the main functionality of the screen.
  • 4. Performance constraints: Functional requirement from non functional requirements can be split into separate stories. For example, a feature can be enabled without caching and then another story can handle caching specifics.
  • 5. Priority: Within a story, there might be multiple priorities. For example, a login story might have different priorities for authentication than for handling error conditions like locking out a user after multiple logins.
User Stories Applied: For Agile Software DevelopmentIt is important to not split stories into tasks like design, code front end, code middle tier, code back end. It is almost always better to deliver a cohesive subset of all layers of a feature than delivering all of one layer as a standalone. Having the entire backend ready without a corresponding GUI is not very useful, but having a feature that allows the user to add an entity through the GUI and have it persisted is functionality that can be useful and provides some value.

Finally, there might be cases where we might want to combine many small items onto one larger story. For example, bug reports can be combined into one Fix Bugs story.