The Code Christmas Tree

The Code Christmas Tree is a technique used to visualize the quality of your code. It is based on a treemap which is an information visualization technique to display hierarchical or tree-structured data as a set of nested rectangles. Branches are represented by rectangles and sub branches are represented by smaller rectangles and so on. The leaf node’s rectangle has an area and color proportional to a specified dimension of data. In the case of the Code Christmas Tree these can be lines of code, cyclomatic complexity, and test code coverage. The different colors and sizes make it easy to see patterns that would be difficult to spot in other ways. Looking at the tree you can quickly identify which code areas are clean and which ones need more tests or major refactoring.

The chart examples shown here were generated by Michael Kaiser and Guy Royse using a utility that displays Big Visible Metrics (BVM). It takes XML metrics generated by Sonar and parses the data and converts it to CSV data that is then consumable using the Microsoft Treemapper and Excell Add-in to generate these colorful charts. The size of the rectangle represents lines of code. The color represents cyclomatic complexity or test coverage. The large red rectangles are the code targets that need to be refactored or need increased code coverage. BVM is on GitHub and you can find out more about it here.

Adapted from The Code Christmas Tree @Agile2011

Draw me a picture

Draw me a picture is a retrospective technique that can be used when people are tired of the same old routine and when verbal communications are failing.

The process is as follows:

1. Ask the attendees to silently reflect on the on the events of the last iteration or release 
2. Ask them to draw a picture reflecting their feelings 
3. Place the picture on the wall
4. In turn, let each participant describe their picture and provide a title
5. Try to observe patterns to highlight significant events or impediment

Adapted from: Putting the fun back in your retrospectives @ Agile2011

The 1st ever bug

In 1946, the 1st ever case of a bug was reported when an actual moth trapped in the relay of a Mark II caused it to malfunction. The bug was removed and taped into a log book and recorded as the 1st actual case of a bug being found! The log book (with attached moth) is on display at the Smithsonian National Museum of American History. How’s that for error tracking!


The term bug however was coined earlier as records show that Thomas Edison used it in 1878:

“It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise—this thing gives out and [it is] then that 'Bugs' — as such little faults and difficulties are called—show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached.”

Adapted from: Refactor your wetware @ Agile2011

The Kata in the Hat

At Agile 2011, Emmanuel Gaillot and Jonathan Perret performed a coding Dojo entitled "The Kata in The Hat." Emmanuel and Jonathan are behind the original coding dojos in Paris. Usually, katas are performed by practicing TDD and applying baby steps. The main kinds of Katas include:

1. Prepared Kata  where someone comes prepared with a full solution to the Kata and presents it to the group.
2. Randori Kata where the group rotates pairs so solve a particular problem.

The Kata in The Hat is a twist on these katas. Here, the hosts had a hat in which audience members can write-in rules and requests and drop them in the hat. The presenters start with a main idea, but every five minutes one paper is pulled out of the hat, the instructions are read and the timer is reset. The hosts continue to pair program, but now they incorporate the new requests into their code. And so on... The interesting part is seeing how they can finish each request by doing the simplest thing that can possibly work. They quickly adjust and keep the code moving as they try to solve the main problem no matter what is thrown at them. This type of Kata is definitely not for the beginners, but it’s a great show that is fun, entertaining and educational. If they are ever touring at a conference near you, I highly recommend you attend.

"The big idea we want to get across is that programming can be beautiful, and that through creativity and beauty and poetry programmers have much more power than they think."
 http://thekatainthehat.com/ 

Organizational Agility

The Economist Intelligence Unit published a paper entitled "Organizational agility: how businesses can survive and thrive in turbulent times." The paper is based on in depth interviews and surveys of 349 executives around the world on the benefits, challenges and risks associated with creating a more agile organization.

The report finds that organizational agility is a core differentiator in today’s rapidly changing business environment. Agility may also be linked to profitable growth as research conducted at MIT suggests that agile firms grow revenue 37% faster and generate 30% higher profits than non-agile companies.

Yet most companies admit they are not flexible enough to compete successfully. The report finds that internal barriers stall agile change efforts and the main obstacles to business responsiveness are slow decision-making, conflicting departmental goals and priorities, risk-averse cultures and silo-based information.

Technology can play an important supporting role in enabling organizations to become more agile. Technology should function as a change agent in the use and adoption of best-in-class knowledge sharing processes, so companies can improve their use of critical data.

The report concludes there are a number of steps that management can consider to lighten the burden of agile transformation:

1. Minimizing excess spending and non-core programs so companies can better direct limited resources to satisfying customer expectations. 
2. Minimizing information silos so business leaders can improve collaboration inside and outside their enterprise and better align departmental goals and performance measures with overall strategy. 
3. Integrate and automate fundamental knowledge-sharing processes to improve decision-making, convert information into insight and enable IT to advance an organization’s ability to problem-solve. 

The complete report and survey results can be found here.

Captions

Captions is a retrospective technique that can be used as a collaborative and safe way to share feelings. The technique is fun and the results can be very insightful and hilarious at the same time.

The process is as follows:

1. Announce a specific topic for discussion 
2. Each team member gets n number of index cards where n is the number of team members. The cards are numbered sequentially in each stack. 
3. Individually, on card #1, members draw a picture to illustrate the topic at hand 
4. The decks are passed to the right 
5. On the new deck received from the left, members study the picture on top, then move the card to the bottom of the deck. 
6. On the next card, members write down a caption for their interpretation of the picture they just saw 
7. The decks are passed to the right 
8. On the new deck received from the left, members read the caption, then move the card to the bottom of the deck 
9. On the next card, members draw a picture based on the caption they just read 
10. This process is repeated for several rounds until each stack is back at card #1 
11. Members take turns laying out the decks and reading out and sharing the results with the team 

Note: If the number of team members is even, then start with drawing a picture, otherwise, start with writing down a caption.

Adapted from: Putting the fun back in your retrospectives @ Agile2011

The Nordstrom Innovation Lab

At the Nordstrom Innovation Lab, a new team is applying agile and lean startup techniques to move quickly from conception to deployment. The team is acting like a startup within a large organization. They work in a collaborative open workspace and go through several iterations using frequent customer feedback loops to plan out their next iteration. They keep their planning simple and light-weight by using sticky notes and index cards and following agile engineering practices like pairing and test-driven development. Watch this team in action below.

 

http://nordstrominnovationlab.com/