Keeping Retrospectives Fun

At the May DC Scrum user group, we had a workshop on retrospectives. We covered six different techniques to keep retrospectives fun.
For all the techniques we followed this structure:

1. Set the stage: This entails ensuring that everyone feels safe to express their opinions. A good way is to start out with the prime directive:
   "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand"
2. Gather data: This is where we create a shared pool of data to ground the retrospective in facts instead of opinions.
3. Generate insights: This is where we observe patterns, determine root cause, and build a shared awareness of the situation.
4. Decide what to do: This is where we move from discussion to action and come up with a plan to resolve the top 2 or 3 items.
5. Close: This is where we review the findings, reiterate the action items, and appreciate everyone’s participation. 

The six techniques covered where:

1. Draw me a picture
2. Silent retrospective
3. The timeline
4. Team radar
5. 5 Whys 
6. and a special bonus technique called Retrospective Cookies courtesy of Adam Weisbart.

Spiral Matrix Kata

In the May DC Software Craftsmanship meeting we tackled the Spiral Matrix kata. The instructions for this one are simple and are best illustrated by the examples below:

3 by 4 matrix:

4 by 4 matrix:

3 by 5 matrix:

You Build It, You Run It

In my previous post, I described the changes that Jez Humble believes an organization needs to go through to enable DevOps. In this post, I’ll describe why Jez is encouraging organizations to align around products instead of projects.

On average 29% of an IT budget is spent on new system development while 71% is spent on maintaining existing systems and adding capacity to those systems. This is because organizations do not retire applications. A lot of money is being spent on maintaining mission critical applications. Some of these applications are even running on software no longer supported by the vendor. More money is being spent on applications that have part or all of their source code missing. This is mainly because once a product is delivered to production, the project team that built it is disbanded and team members move onto different projects. Organizations have no way to rationally decide what to retire. Everything is rolled up into one budget and there is no clear way of deciding what systems are generating value and which are not.

Amazon applies the motto “You build it, you run it”. This means the team that develops the product is responsible for maintaining it in production for its entire life-cycle. All products are services managed by the teams that built them. The team is dedicated to each product throughout its lifecycle and the organization is built around product management instead of project management.

Using this approach, teams can measure cost and value delivered per product team. Teams can rationally determine what to prioritize in their product backlog and teams can self-manage using a lean startup methodology. The architecture groups becomes responsible for regulating and monitoring system-level attributes while the PMO regulates and measures to prevent “market failure” and external factor. Some Ops team members will move to work with the product teams while other Ops team members are no longer responsible for supporting the application but instead manage the infrastructure that applications run on. It is kind of like an in house infrastructure as a service with Service-Level-Agreements for the product teams.

Using a product management approach, the organization now has budgets for product teams instead of new development or maintenance. Budgets are no longer lumped together, but are instead dedicated to specific product lines. Each product team needs to make the case why their product needs funding based on the business value that it generates compared to total life-cycle cost. Using this approach, organization can now make business decisions as to which products to innovate on and which to cut or retire.

Adapted from  Enterprise DevOps: Breaking Down the Barriers between Development and IT Operations @ADP East 2011

4 Parts to Delivery

In a previous post, I discussed how Jez Humble made the case for the need for continuous delivery and DevOps. In this post I’ll cover the changes that need to be implemented to enable DevOps.

Below is how Jez describes the 4 parts to delivery:
1. Culture
2. Automation
3. Measurement
4. Sharing

Culture is the most important part of DevOps. We need to make sure development and Ops are not treating each other as rivals and are instead working together frequently and efficiently. Ops need to be involved early on in the development process. They need to be in the inception meetings and in the demos. They need to know what is coming down the pipeline and provide their requirements in terms of monitoring, scalability, archiving, etc… Developers also need to rotate through the operations department. They need to be on call in case of production problems. They need to feel the pain and impact of not delivering production ready applications. Incentives between the development and operations department need to be reversed. Development needs to be measure on stability and operations needs to be measured on throughput. This gives development incentive to deliver production ready applications while encouraging operations to push applications into production.

Through automation, we can reduce the cost of making changes to the application and thus enable frequent delivery of software. This enables us to make smaller incremental changes that are less risky than big bang approaches. We want to create a deployment pipeline and automate the entire delivery process from build, deploy, test to release. Provisioning of infrastructure as well as database migrations and deployments need to be also automated so that we can always test in production like environment. All this creates transparency with a complete audit trail from when a change was introduced into source control until it was released into production.

Measurements are key to continuous improvement. We need measurements for all teams.
Are we generating business value? How many new users do we have? How many new orders?
Are we producing quality products? How many bugs are there? What changes are breaking things?
Do we have the right infrastructure? How often does a failure happen? How long to restore service? From these different measures we can decide on what areas need improvement.

Techniques like CI, TDD, and refactoring that developers use to improve their code can also be used to improve the Ops environment. Having the development team sharing and working with the operations team to improve their environment further builds trust and improves the relationship between the two until gradually the border between the two disappears.

All this is a major improvement on the traditional silo in the organizations. By building trust, aligning incentives, building a deployment pipeline, and measuring our processes, we can now eliminate the hardening and stabilization phases that tend to extend project plans. As the 2 groups move closer together, done no longer means dev complete but instead means released and in use. Developers now write production ready code and deploy to production like environments from day one. The conception to production cycle gets dramatically reduced to a matter of days and the business can now receive fast feedback and plan based on real user data.

In my next post I’ll describe how this enables organizations to align themselves around products instead of projects. Stay tuned...

Adapted from  Enterprise DevOps: Breaking Down the Barriers between Development and IT Operations @ADP East 2011

Managing Technical Debt

Thanks to all that attended my presentation on Managing Technical Debt at the 2012 Atlanta Scrum Gathering. Below are the slides and notes from the presentation.

Making the Case for DevOps

At the ADP East conference, Jez Humble made the case for continuous delivery and DevOps.

He described a simplistic view of an organization where you’ll have a business department that comes up with a new product and hands-off requirements documents to the development department. After a couple of years, the development team finally completes the application and hands it over to the operations department so that they can provide the application to the customers.

This cycle from conception to production takes a couple of years and the success criteria are based on on time, on schedule and on budget. Very few organizations go back to analyze the total life cycle cost of the product vs. the real customer value it is generating. According to the Standish group, about 60% of features delivered end up being never or rarely used. Since the business does not have a mechanism of delivering quickly and validating their ideas through early customer feedback, they instead try to forecast and predict the future by guessing what their customers will want. And since acquiring funding is hard and in order to ensure project success, they end up cramming the requirements documents with all sorts of features that cover all imaginable scenarios. This increases scope which in turn delays the project and further lengthens the conception to production cycle.

Agile addresses this problem by focusing on delivering working software early and often and avoiding the big batch death spiral approach to software development. However, even by adopting Agile, the organization needs to align the goals of these 3 departments. The business is being measured on innovation; development is being measured on throughput while operations are being measured on stability. These are competing goals that can impede Agile adoption as departments treat each other as rivals instead of partners.

Well what if these goals where reversed? What if development is being measured on producing stable, production ready applications while operations is being measured on throughput? In my next post I’ll explore how Jez believes DevOps makes this happen by addressing culture, collaboration, automation and measurement. Stay tuned…

Adapted from  Enterprise DevOps: Breaking Down the Barriers between Development and IT Operations @ADP East 2011

Share the Love

Agile encourages self-organizing teams and emphasizes team performance. This is at odds with the traditional employee performance review and the individual recognition system common in most organizations. Phillip Rosedal founder of Linden Labs (creators of second life) approached this problem with an innovative system that he setup at their offices. The system allowed team members to send each other short “Thank you” messages of appreciation in recognition of a job well done. The office also had large monitors that continuously displayed these messages of recognition while making everybody aware of what others were working on (information radiators). Rosedale also introduced employee driven bonuses, where each team member got a certain amount per year that he could allocate to other deserving team members. The idea is that people closest to the team know best who the peak performers are.

Rosdale has expanded on these concepts to create The Love Machine. This is a commercial product were companies setup thresholds for rewards and then team members send each other love messages showing their appreciation to others for a job well done. Each message received counts towards points that team members accumulate and later redeem for gift certificates.

I've heard that LivingSocial and Yelp use this system but besides that, I don’t know how widely companies are adopting the Love Machine or how effective it truly is. What do you think? Is your team ready to share the love?

Timeline Retrospective

The Timeline Retrospective is a technique used to reflect back on major events that occurred during a Sprint or a Release

The process is as follows: 

1. Silently write down on sticky notes the major events that occurred
2. Create a single timeline on a wall 
3. One by one, layout the notes in order of occurrence on the timeline
4. Place positive events above the timeline and negative events below the timeline
5. Discard duplicates
6. Have one person walk through the final timeline
7. One by one, rank the events on the timeline using dot voting 
8. Identify actions for the highest ranked events
9. Rerun the time line with the actions and see what changes and if you get the desired outcome. 

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

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/

The Spinning Lady

Look closely. Is she spinning clockwise or counter-clockwise?

Think of happy places, found memories, poetry, and music. Let your mind wander.

Look closely. Is she spinning clockwise or counter-clockwise?

Solve 3*5=?
Solve 15+5=?
Solve 20+5=?
Solve 25 + 3 =?
Solve 28/2=? 14.

Look closely. Is she spinning clockwise or counter-clockwise?




Did she switch direction? The idea here is that our brain switches between left and right. If she is spinning clockwise, then we are using the right side of our brain which is responsible for feelings, beliefs, imagination. If she is spinning counter-clockwise, then we are using the left side of our brain which is responsible for logic, math, and science.


Adapted from "Refactor Your Wetware" @ Agile2011

Effective Daily Standups

Thanks to all that attended my talk on Effective Daily Standups at the SA Scrum Gathering Conference. Below is the presentation slide deck and speaker notes.

Source Code Word Clouds

Here’s a neat way to look at code quality - use source code word cloud generators.
A word cloud or tag cloud is a visual representation for text data. Tags or words are listed and the importance of each word is shown with different font size or color. When applied to well written and clean code, word clouds give us a quick way of understanding what the code is about.
 
 Below is an example from http://fragmental.tw/2009/04/29/tag-clouds-see-how-noisy-your-code-is

Clearly, looking at the second cloud, we know a lot more about the domain than the 1st cloud.

Try it out using the original http://www.wordle.net or http://sourcecodecloud.codeplex.com

Adapted from "Code" @ Agile2011

Back to the Future!

At the conclusion of the Agile 2011 conference, Todd Little jokingly looked back to the 1st Agile conference in 2004 when agile experts made predictions of the future and came up with the top 8 things that will happen once main stream gets hold of Agile Software Development:

8. The 1st Agile software development conference will undergo historical revisionism, in which it will be told as originally taking place on a farm outside Sundance, with lots of music and on-demand pairing, and announcements in middle of the conference to not eat the brown acid.

7. The Spike channel will ask Ron Jeffries to host an Apprentice-type reality show where agile teams will compete against each other to build software for rocket-packs, X-ray goggles, and invisibility rays. The catchphrase when he gets rid of the failing team each week is “You’re dead fish!”

6. GE will develop 3 year, six sigma certification programs for becoming Agile Certified.

4. You’ll see personal ads like ”Certified SCRUM master seeks product owner with large product backlog for promiscuous pairing”, and “Single Agile Developer with data envy and analysis paralysis seeks customer for private requirements collection; expect failure”.

3. Sun will come up with an innovative, elegant Agile programming language, get people to use it, and proceed to totally screw up the marketing for it and name it with really confusing release numbers.

2. Woman out at bars together will refer scathingly to the guy at the end of the bar who keeps starring at them as a “scope creep”.

1. A paperclip in Windows will pop up periodically and say, “Looks like you’re trying the waterfall method. Want me to pair with you?

Measuring Code Quality

A common measure for code quality is to measure Cyclomatic Complexity. Cyclomatic Complexity is used to measure the number of linearly independent paths through a program’s source code. The more conditionals (if statements) or the more loops (for, while …), then the more branches run through the code and thus the code becomes more complex. But what is considered to be a good number for Cyclomatic Complexity? What should developers target?


A study by energy (http://www.enerjy.com/blog/?p=198) reveals the following:

There is a 50% chance of errors with a Cyclomatic Complexity of 38 and almost a 100% chance of error when Cyclomatic Complexity is 74. On the other hand, with a Cyclomatic Complexity of 11, the chances of errors drops to 28%.

So based on this study and the above graph, shoot for a Cyclomatic Complexity of below 20 per class.

Adapted from "Technical Debt Assessment and Reduction" @ Agile2011