Confessions of an Agile Coach

Pair Programming Jokes

2011-10-13T11:06:00.000-07:00

Ok, I have only one, but it is a goody. Especially told by a guy named Arkadiy who delivers this with a Russian accent. If you know more jokes, please add them into the comments.

Dude, dude, refactor
Two drug addicts are driving down the road. Suddenly one of them says, "Dude, dude, watch out there's a bird," and the van drives over it. Later, he says, "Dude, dude, slowdown, there's a cat," but they run over the cat too.
Then there's a dog and the guy says, "Dude, dude! Lookout, there's a dog."
The other guy says, "Dude, you look out. You're the one driving."

Developing Organizational Standards to Support Agile Teams

2011-09-20T07:16:00.000-07:00

Abstract
At the department level, Agile processes are less descriptive on how to increase delivery excellence across all their teams. One approach is to provide implementation-free constraints/goals that drive teams to better delivery and then encourage a culture of cross team information exchange. The constraints/goals will create direction and incentive for teams throughout the organization, while information exchange at the team level allows new 'best of class' solutions to these constraints/goals to propagate across the organization. By inserting a few organizational standard items into team Working Agreements, using Build Monitors to make quality visible, and learning events such as Book Groups, the organization can create a minimum "bar" across teams that will force some teams to improve their delivery excellence, yet won't get in the way of teams who already have good delivery excellence (yet potentially non-standard though innovative development methods).

Introduction
Most agile methodologies come with a built-in form of information exchange at the team level:
daily standup meeting, retrospectives, sprint demos, pair programing, planning meetings that include the entire team, retrospectives, and code reviews. eXtreme Programming, for example, contains the most extreme form of team viral information sharing--pair programming, which has developers working with each other and improving all their development craftsmanship on a daily basis (including soft skills), but sometimes people can't get along with each other. Other forms are lightweight and helpful, but reduced efficiency--code reviews, for example, help people become better OO programmers (a part of craftsmanship), but the practice increases work-in-progress, creates an additional future integration point (integration of design ideas), discourages code experimentation (might not make it past the code review), and doesn't help people learn how to use their software tools such as the IDE more efficiently.

Although most Agile methodologies come with good information exchange at the team level, finding how to direct efforts across the organizational is rarely discussed. (Scrum has Scrum of Scrum and Meta Scrum. Others practices? Please use the blog comments to add more knowledge if you see something missing.) Here are strategies that I've seen implemented to a good effect across an organization and creates a minimum bar of delivery excellence across all the teams, forcing some teams to discover better ways to deliver code, yet doesn't disrupt teams that already are excellent at delivering code.

Working Agreements
The best working agreements have fewer than eight items and are visible in the team's working area. Here is Fred. Off camera is the rest of his team. Although this working agreement was developed by the team, organizational standards were incorporated without being "too" proscriptive. This way, the team takes ownership of their "implementation" and use their own tools/processes to accomplish the working agreement.

Team Working Agreement
Teams get a lot of value by having a written agreement on how we work together and handle day to day issues. This agreement often puts into writing the answers to the "typical" questions that non-self directed teams recieved by asking their project manager, "hey, this happened, what should I do?" This working agreement is often referred to by the following names: Team Working Agreement, General Working Agreement, or Daily Working Agreement. The editorial comments in parenthesis aren't explicitly written down on the working agreement, but are understood by the team.

Example:

Team Working Agreement
- Automated tests are added for all discovered production issues before the code is written
- Standups always include a dial-in (for teams that have remote team members/PO)
- solving production fires is top priority
- stop what your doing to address failing automated unit tests
- the state of all automated tests is visible in the team area
- all system tests, unit tests, UI tests are executed by CI
- all unit tests are executed at least daily
- comprehensive test passes are executed before release to live (all automated + manual)
- all code changes are developed using TDD (legacy code and new code)
- QA starts writing system tests on day one of sprint
- everyone is a tester

Organizational Standard
Setting some core standards across all teams about what few items must be in Team Working Agreement works well. Common subset of the above that I've seen in practice are:

all system tests, unit tests, UI tests are executed by CI
all unit tests are executed at least daily
visible burndown chart
Scrum is practiced (this is usually implied)

Story Definition of Done
This is the team's agreement on what "done" means when they say, "this story is done." All the steps to the story being done must be met to get "credited" with the story being finished so the team can accumulate the story's estimate in Story Points/Units into the team's Velocity. When the team starts a new Definition of Done, the SM needs to be vigilant until the team has got it. If the team can't follow it, then we look for "why not" in the Retrospective and find some way to handle the impediment (fix some problems, adjust definition of done) This definition of done is important for maintaining the team's standard of potentially shippable at the end of each sprint. The editorial in the parenthesis isn't typically added to definitions of done but understood by the team.

Example:
Story Definition of Done
- All public methods are unit tested (except for machine generated code that isn't changed by human hands, or DataValue objects that are "identity--I=I" getter/setters)
- Story functionality is tested with an automated system/UI test (also called acceptance tests, functional tests, ...)
- Manual tests are executed
- Rally is updated (Rally is an electronic story tracking tool)

Organizational Standard

all public methods are unit tested
stories have automated system tests (also called acceptance tests, ...)

Sprint Definition of Done
Because a sprint is time boxed, the sprint is finished regardless of the "pass/fail" of the items in the Sprint Definition of Done, but the retrospective should be used to identify the root causes and create actions to solve problems.

Example:

Sprint Definition of Done
- Each sprint, the code coverage increases
- All automated tests are green at the end of the sprint
- All manual tests for the stories are executed

Organizational Core Standard

code coverage increases each sprint

Other Working Agreements
The following working agreements may also be useful to teams. The art is to find the fewest agreements so we aren't buried by paperwork and yet have the ones that are necessary because problems happen when we don't have them: Task Definition of Done, Release Definition of Done (contains activities to be done before the software goes live, such as performance testing, security testing, or other things that for some reason, there are impediments to getting them done during typical sprints.)

Build Monitors
These devices show the "headlines" of the projects quality status. Anyone can "click" for details. This team modified the continues integration system's CSS to get the clear and simple style they wanted. (Unfortunately, most CI environments have overly complicated dashboards.) The monitor the left has the biz tier (unit tests) and web services tier (system tests) for the SAME app. The build was split into logical levels. The first level compiles, then runs unit tests for the biz tier, and then runs system tests for the web services tier. The monitor on the right is the system tests that test the UI. These three levels are common. It's not hard to imagine adding a SQL level would be useful for a team doing work with stored procedures. The success of one level cascades to the next level. A failure at level one (can't compile) stops it all.

Book Groups
Books a great way to get information across many people in an organization. Just buying everyone in your department a book is a weak play (I still haven't read "The HP Way" which was given to me by my manager when I started work at HP). Books are great learning tools if they are actually used. I don't recommend buying people books unless they ask for them or it comes with a plan reading and using the knowledge. Book groups are groups that get together and discuss reading and using the knowledge (or actually demonstrating the knowledge). To encourage the Cross Pollination of Information, find someone to start a cross organizational book group that meets each week over lunch (companies often buy lunch and the books, and if people are meeting about the books). Encourage the group to develop activities to put the knowledge to work: get members to sign up to teach or demonstrate or lead discussion for each chapter of the book. DO-CODE-ON-PROJECTOR with a mob watching is my personal favorite tactic. Books I recommend are: Martin Fowler's Refactoring, Diana Larson's Agile Retrospectives. Teams I've been a part of have done this with books on Refactoring, GOF Design Patterns, eXreme Programing Explained, and Java Concurrency.

Conclusion
Delivering to all your teams core standards for their working agreements creates quality bars that teams aim for and hurdle over. If the organization focuses on the desired outcome and allows the teams to develop how to reach those outcomes, the teams will find solutions that work best for their personal and project makeup, and they'll become vested in the implementation. Adding in collaborative cross-organizational sharing and learning events such as book groups that are driven by employees, will give the employees a process for driving their own development and collaborating/learning with other team members.

Troubleshooting
Here is a troubleshooting guide that covers some common problems that may occur implementing the above activities.

Team finished sprint with zero velocity.

Maybe their working agreements were too hard. Inspect and adapt for next sprint. Maybe they need to embedded a coach for a sprint.

Team releases with bugs.

Not enough testing. Zero bug releases are expected.

A team's CI environment isn't visible

Are their tests failing? What are they hiding?

Team refuses to try new practices/process for even a sprint.

Too much release pressure? Team embedded in their old ways? Is the company culture so risk adverse that any failure has political implications?

References:
XP practices http://en.wikipedia.org/wiki/Extreme_programming_practices

What do studies say about Agile?

2011-09-08T06:07:00.000-07:00

Agile Studies
This is going to be a different posting. This one will be organic and added to as I find other good bits of information. I need something like this to make it easier to go over an inventory of studies. I need this to solve my "searching for studies" impediment which comes up periodically.

Help me keep this up to date. If you have an Agile paper you want cited, comment about it.

Test Driven Development:

TDD Improves Quality
Abstract: A paper first published in the Empirical Software Engineering journal reports: "TDD seems to be applicable in various domains and can significantly reduce the defect density of developed software without significant productivity reduction of the development team." The study compared 4 projects, at Microsoft and IBM that used TDD with similar projects that did not use TDD.

Does Test-Driven Development Really Improve Software Design Quality?
David S. Janzen, California Polytechnic State University, San Luis Obispo Hossein Saiedian, University of Kansas
Lance's summary: TDD allows simpler design == less lines of code to do the same thing
Summary: Software developers are known for adopting new technologies and practices Software developers are known for adopting new technologies and practices

Test-Driven Development and Software Quality
Lance's summary: a blog that comments on the IEEE paper "Does Test-Driven Development Really Improve Software Design Quality."

Pair Programing:
A good summary about the practice along with a little satire at wikipedia.

The Costs and Benefits of Pair Programming
Alistair Cockburn & Laurie Williams

Lance's summary: Pair programing creates a lot of value over the total product lifecycle (higher code quality, lower defects, reduces team bottlenecks, and increases work satisfaction) at the cost of 15% more development time.

ABSTRACT
Pair or collaborative programming is where two programmers develop software side by side at one computer. Using interviews and controlled experiments, the authors investigated the costs and benefits of pair programming. They found that for a development-time cost of about 15%, pair programming improves design quality, reduces defects, reduces staffing risk, enhances technical skills, improves team communications and is considered more enjoyable at statistically significant levels.

Evaluating Pair Programming with Respect to System Complexity and Programmer Expertise
Erik Arisholm, Member, IEEE, Hans Gallis, Tore Dyba ̊, Member, IEEE Computer Society, and Dag I.K. Sjøberg, Member, IEEE

Abstract—A total of 295 junior, intermediate, and senior professional Java consultants (99 individuals and 98 pairs) from 29 international consultancy companies in Norway, Sweden, and the UK were hired for one day to participate in a controlled experiment on pair programming. The subjects used professional Java tools to perform several change tasks on two alternative Java systems with different degrees of complexity. The results of this experiment do not support the hypotheses that pair programming in general reduces the time required to solve the tasks correctly or increases the proportion of correct solutions. On the other hand, there is a significant 84 percent increase in effort to perform the tasks correctly. However, on the more complex system, the pair programmers had a 48 percent increase in the proportion of correct solutions but no significant differences in the time taken to solve the tasks correctly. For the simpler system, there was a 20 percent decrease in time taken but no significant differences in correctness. However, the moderating effect of system complexity depends on the programmer expertise of the subjects. The observed benefits of pair programming in terms of correctness on the complex system apply mainly to juniors, whereas the reductions in duration to perform the tasks correctly on the simple system apply mainly to intermediates and seniors. It is possible that the benefits of pair programming will exceed the results obtained in this experiment for larger, more complex tasks and if the pair programmers have a chance to work together over a longer period of time.

All I Really Need to Know I Learned in Kindergarten
By Robert Fulghum (Fulghum 1988)
Lance's Comment: Not really a study, but important information for people interested in pairing studies. This paper contains a lot of the behaviors needed for successful pair programming.

Abstract:
Share everything.
Play fair.
Don’t hit people.
Put things back where you found them.
Clean up your own mess.
Don’t take things that aren’t yours.
Say you’re sorry when you hurt somebody.
Wash your hands before you eat.
Flush.
Warm cookies and cold milk are good for you.
Live a balanced life – learn some and think some and draw and paint and sing and dance and play and work every day some.
Take a nap every afternoon.
When you go out into the world, watch out for traffic, hold hands and stick together.
Be aware of wonder.

Pair Programming Testimonials
Abstract:
If you would like to share your pairing experiences or read about other people's, this is the place. Describe the good and bad of your experiences pairing to help others in a similar situation - just a paragraph or two would be great . . . what worked well, what didn't work so well, what kinds of things did you 'attack' together, tips and tricks, etc. A great example of a testimonial is by Ron Jeffries in the July/August 2000 IEEE Software page 25.

The ONE right way to Scrum

2011-09-02T20:50:00.001-07:00

What is the right way to Scrum?
This question is brought up a lot in organizations that are transforming to Scrum to improve their ability to deliver products. It's a natural question for smart people to ask when they are receiving Scrum training and then discover other teams adjusting from the "default" or "standard" implementation of their company's Scrum process.

Is there one way to do Scrum?

It's better to ask yourself, "should there be one way?"

When anthropologists talk of societies and biologists talk of evolution and virus colonies, history has shown that the results of monocultures are dangerous. The societies, governments, organisms, or colonies that survive are those that could respond to a change that wiped the others out. Having everyone thinking and agreeing all the time means new ideas aren't getting tried out. On the other hand, having only conflict/chaos means poor productivity/survival.
Computing monoculture
agricultural monocultures

What is Scrum?

Scrum has been around for over 10 years. (You can read Martin Fowler's 2005 overview of Scrum in
The new methodology called Scrum)

Scrum says once the planning meeting has finished and the sprint starts, the planning conflict (conflict over resources) is over (or at least is moved outside the team) and the execution of the plan begins. For the team, conflict moves to technical implementation as they discover the best designs (test plans, class designs, craftsmanship) to meet the plan's goals. At the end, the team, ScrumMaster, and ProductOwner inspect the results and proposes a "new experiment" to improve software delivery.

What is Scrum (or basic scrum)

Three roles: team that does the project work, a ScrumMaster, and a single person to be ProductOwner.
A fixed backlog of work for a sprint. A sprint is a fixed length of time.
A quick planning meeting.
Retrospective and sprint demo.
Daily standup meetings that are no longer than 15 minutes.

*Velocity, burndown charts, and task boards are also expected but aren't necessary for the empirical process other than adding more visibility. But since visibility is necessary, like a microscope is necessary to a biologist, I'm including them too.

You may ask six Agile Consultants "What is Scrum" and get six answers but I expect all six will have at least all the above.

Why six different answers?
How I Scrum today is different than how I Scrummed in 2006. How I Scrummed in 2006 is different than 2004 (my first Scrum project). But in all cases, I did Scrum. Before 2004, I did eXtreme Programming, and did not do all the above that is Scrum and instead did other things, XP practices (pairing, TDD, system test) and how my team executed those practices changed every month/year.

Why did my practices change? Because my teams inspected the WAY we did things and ADAPTED. We talked to and learned from others doing agile and tried out ideas for a sprint. Using the rigors of the experimental process (control/fix everything else but what you want to change, and then measure the results at the end) we decided what new adjustment to keep and what not to keep.

Standards

Should there be a standard way across an organization?
Are you saying that you want a monoculture? Is Scrum itself a monoculture? Maybe, but if each Scrum team is a little or a lot different so I think it's not a monoculture. I think that doing "basic" Scrum (just Scrum) as a standard is a good idea because then everyone from development to the CEO understands the culture enough not to:
Ask team members multitask across different projects
Ask POs to change the team's sprint backlog while they are in mid sprint
Discourage highly collaborative practices like Pair Programming
Discourage differences between Scrum teams
Ignore impediments discovered by teams

We want how we work together standard enough to not break each others' Scrum processes and to support teams' inspection and adaption of their own processes.

Directing an organization without standardizing a monoculture

Standardizing on organizational goals that allow teams to self organize is a good idea. Here are some I've seen in the industry:
burndown chart of some kind, definitions of done,
Automated system tests, automated unit tests, a system to show how many tests are passing/failing in the last hour, collocated teams, a highly visible team task board the team can use throughout the day, current code coverage and sprint by sprint history so we can see the trend.

The one TRUE way to Scrum

When an organization leaves Waterfall for Scrum, people need to be well trained on what is Scrum and asked to do things they are uncomfortable with, maybe even things they can't imagine could work. They need this pressure to get started doing Scrum otherwise, before even their first sprint, they decide to inspect and adapt to something they are comfortable with, Waterfall, out of a sense of comfort rather than out of quantifiable measurements that come out of the Scrum process (Velocity is a big one). So to get a team started, they will need to take a starting Scrum model on faith until they get the idea and see results good or bad. After a few Sprints, I expect to see that the cumulative affects of inspect and adapt to show some changes from their starting Scrum model but to still see the basic Scrum model intact.

If someone says that they have one true way to do Scrum, I'd start walking the other way because that person doesn't understand that Scrum requires teams to inspect and adapt their process to become efficient for their specific situation. If a team isn't inspecting AND adapting, then their Scrum process is broke.

Hello World, Hello Quickest end to end Implementation

2011-02-13T20:40:00.000-08:00

What is the fastest your Agile team can bring something to market? If you don't know, it's time to find out. You might be surprised at the answer. When working with clients who struggle to understand potentially shippable, I found that talking about releasing a Hello World story is a good way to learn how well their development, technology, and QA processes work.

Recently, I worked with a ScrumMaster who said his team would need more than 1 day but less than 2 to build, test, package, deploy, and then system test the installation. This was much better than his first answer: we don't test the package during each sprint, we don't do a Sprint Deno because we can't. Talking about adding a Hello World story is a good way to structure people's thinking about an easy to visualize goal. Then it's easier to talk about what impedes realizing the goal.

It's also a good way for the team to learn how to do all the engineering practices for from one end to the other: acceptance test, tdd, pair, ... And measure the overhead (what impedes them).

Agile Resource Management and the "Perfect Method"

2011-02-03T23:56:00.001-08:00

Managers whose companies are in the agile transition period often have questions about resource management. With Agile, it's quiet different than what they are used to. If we understand what got us in this situation, we'll better understand how to fix it. Here's a look at Agile's Planning Game versus traditional project management and resource allocation.

The Planning Game
The goal of planning is to get the most value for the business/customer for the amount of time spent on the project. To achieve this, we need to get development and business working well together. If the relationship is poor or if there are many layers of middlemen (management, analysts) separating the layers, then the planning outcome will suffer, even the project is considered an Agile project. This is why XP and Scrum both want the customer (or the Product Owner--one person who can make decisions as if she were the costumer) directly involved in the planning meetings and interacting with the team as often as possible. Agile methodologies also ask that the team work differently together: cross-functional, small releases, pair programming, production quality code released at the end of each iteration, etc. (See the following for more: http://www.extremeprogramming.org/rules.html)

Traditional Project Management in the Enterprise
Traditional project management evolved into having layers of people between those who can make decisions about requirements and those who are building the software. Among other reasons, this was done as a way to scale work out to hundreds or thousands of people. A number of middleman roles were created and these middlemen worked more or less as a negotiating layer between the business and the development, maintaining records of decisions. This slowed down decision making due to the team or business working through layers analysts/management to communicate with each other, and often using media (documentation, email) that was inferior to face to face communication.
The outcome of a slow decision making and communication process is that people on both ends found other things to do while they waited. The business people would start another project and generate business specifications, the development team would be managed by a resource manager who would find them another project to work on during this wait time. This other project would then execute using the same traditional planning style. Since making decisions is slow in this process, following THE PLAN became very important because changing the plan meant more meetings, more decisions, more waiting. Sometimes, team members could be on three slow moving projects, or maybe even four. Resource managers became very busy in making sure people's time was as fully allocated as possible. To make their management easy, each project needed to add to THE PLAN how they were keeping each person busy. If a project's PLAN changed, this created change in personal (adding or removing). If estimates were found to be poor, people would do their best to come as close as possible so that THE PLAN wouldn't change, and sometimes the schedule slip was disguised for months. If the business wanted something different done, this would also create a change in THE PLAN that everyone wanted to avoid. THE PLAN evolved to measure the work in Perfect Engineering Days (the "Perfect Method"). If a task takes 11 Engineering days, and you have 5 Engineers, then it will finished in about 2.5 days multiplied by some Overhead constant to represent meetings, email, communication that takes the engineer away from work. So those 11 days are "perfect engineering days."

Agile and the Planning Game in the Enterprise
The biggest reason to move to Agile methodologies is that they make business sense. Time to market is an important measure of a company's ability to bring new products to market. If your product is up for sale before anyone else has a similar product, you have a huge advantage in being the only choice. If your 2nd generation product is out for sale while the competitors only have their first generation, again, you have a captive marketplace that can only buy from you. Some members of the market will wait for their favorite vendor, but they won't wait forever.

An Agile team team is set of people who work on one project because for a long time, we knew that multi-tasking over multiple projects creates "wait states." Wait states within the project and wait states across the other project that the engineer is working on at the same time. For example, engineer A on project Z waits for something from engineer B, but B is working on his other project V because his manager wants to see more progress because V is becoming the "long line" in a multi-project release. After engineer A spending some time discovering the wait state, she finds something else to do: re-remembering what her other project, Q, is doing, setting up a build environment, and paying other Costs of Task Switching. Everyone knows that multi-tasking adds to overhead, it's only a matter of debate about how much overhead, and finding an alternative. The trouble is, multi-tasking breads more multi-tasking, as you saw with engineer A.

The Agile Alternative
Part of Agile's better execution speed is realized by breaking away from making plans that mixing business requirements and individual resources together, by simply deciding that everyone on the team is full time on that project until it releases, and the team can manage balancing the work load. Agile's productivity measure, Velocity, is a team wide metric. Velocity measures team productivity and is updated each iteration. Each iteration we have a Planning Meeting where we play the Planning Game
[source: http://www.c2.com/cgi/wiki?PlanningGame] where the team's latest Velocity and their estimates of the backlog of stories/requirements are used to give the business the most up-to-date data on what stories can/cannot be done. Re-planning happens each iteration based on this information (stories are adjusted, people may be added/removed from the team). We expect to re-plan, where Traditional project management expects THE PLAN to never change (which is a false assumption since it always changes). The team, uses its Velocity to guide how much work to pull into the next iteration. Perfect Engineering Days aren't used because it brings along with it a stipulation that only one person is working on each task (the ability to divide and conquer is implied). The team members may use the practice of Pair Programming in order to have fully reviewed code, better designed, and a fully cross functional team where everyone understands what the software is doing. (Note: You could choose to use Perfect Paired Engineering Days http://xprogramming.com/Practices/PracIterations.html. But there are better systems out there which are a better fit for how human brains work: http://www.renaissancesoftware.net/files/articles/PlanningPoker-v1.1.pdf ) [*]

What's a manager in a transitional organization to do?
If people demand that you express your team's allocation by engineering days so they can add it into a planning tool, then find a way to make them happy without having "resource allocation reporting" affecting your team's agile process (Pair Programming, using Planning Poker with a numbering system rather than "Perfect Method", cross functional team members, ...). For example, if you have six people on your team, and based on the team's most recent Velocity, they are going to finish the most up-to-date version of the backlog in two months, then you have twelve engineering months. Find a way to fill out the report to make the organization happy. Eventually, and by educating your organization, you'll be able to drop this "Perfect Method" Wrapper.

"Perfect Method" Wrapper Patterns
Since many companies are in similar straits when transitioning from a traditional organization to an Agile organization, many project managers turned ScrumMasters or XP Coaches are faced with this problem over and over. Wouldn't it be nice to have a list of solutions that people have done to solve this impediment? That's where you, dear reader, come in. If your are in a transitioning organization or have just finished a transition, use the comments section (moderation is turned off, so go for it) beneath this blog to describe what you did or going to try to keep your team agile when your department wants you to report on your use of human resources via perfect engineering days.

[*] I'm more proscriptive than James Grenning in that I ask teams to resist adding more numbers into their numbering system. If you're using the Fibonacci system (1 2 3 5 8 13...), stick to it! Otherwise the team'll waste time deciding between 5 and 6 rather than quickly finishing planning by deciding between 5 or 8. I'm even more extreme in that I recommend a geometric series instead (1 2 4 8 16 32) which has even bigger gaps. Having gaps are important because humans are better at making quick decisions over these gaps between numbers rather than a long debate with a liner system where there isn't much difference.

ScrumMasters should believe in UFOs!

2010-07-11T21:04:00.000-07:00

I've been working with some new ScrumMasters that used to be project managers and the biggest thing holding them and their teams back is the attitude around resolving impediments:

They rely only on the team *reporting* impediments to them instead of sleuthing for impediments.
They collect information about impediments in a notebook.
No one on the team or management knows the status of the impediments, how many there are, or how bad they are.
The ScrumMasters are writing email reports about the impediments.

Instead of the above behaviours, I'm encouraging them to believe in UFOs. Everyone should believe in them, but it's the ScrumMaster who should give UFOs their professional treatment.

U -- Who is responsible for resolving impediments? U!
F ast -- U shouldn't wait long before trying to resolve them. Don't schedule a meeting in the future or craft a report for something you can take care of now.
O bservable -- Impediments should be easy for anyone to see at any time.
S tatus -- The status of the impediments should be clear and known so the team feels something is being done beyond someone nodding their head, writing in their notebook, and crafting CYA emails. It's best to make the status observable.

I've put together a video called Living with Impediments which illustrates the problem and also goes over UFOs. You can also find more Agile videos at my YouTube channel.

Tell your ScrumMasters about UFOs.

Agile Coach Debriefings: Sprint Planning and Planning Poker

2010-06-20T00:01:00.000-07:00

Lancer is going to confess on camera about discussions he's had with clients by going over his coaching notebook. As of now, he discusses how to schedule and organize for Sprint Planning in a day, and how to have a quick session of Planning Poker using the team's group intelligence.

You can subscribe to his YouTube channel to receive new updates.

Burn, baby, burn (part 2/2 to having great standups)

2010-04-29T18:44:00.000-07:00

Something a SM should do every morning right before standup: take a look at the burndown chart and try to find an easy 'win'. A win is a story that is almost done and could make the line on the burndown chart burn (go) down.

Then at the beginning of Standup, 'set the stage'[1] by telling the team that they almost have a story finished which will show great progress during the sprint. Ask the team to figure out how to get THAT story (creating focus) finished so they can get an early win, burn down the chart, and show their PO that progress is being made.

This also gives you, the scrum master, focus: solve any difficulties that get in the teams way around finishing that story. If you get a TEAM of people focused on a goal, great things always happen. But it requires finding the right thing to focus on. A story that is near finish is a good thing to focus on, until it meets our definition of done.

And for a bonus, you can run the story by your PO for Story Acceptance before the end of the Sprint. That will really get the PO and the team excited.

Flow my tears, the ScrumMaster said (Part 1/2 of Having Great Standups)

2009-05-22T18:12:00.000-07:00

A ScrumMaster has a tough job. He is supposed to help his team perform without actually diving into the work himslef, for if he did, then when someone has an impediment, he would be busy and likely not have the broad context needed to solve the problem outside of his immediate work. Preserving a big picture perspective is important. Firemen don't leave the station without their Fire Captain. The Captain isn't allowed to enter the building and must stay in the fire engine (or near it) and coordinate his team via radio. (I've even heard that Fire Captains are literally locked inside the fire engine to prevent them from abandoning their post to rush into a burning building.)

Everyday, the ScrumMaster's job is to figure out how to get the team perform better, which is much harder than developing code. The worst situation a ScrumMaster can be in is have a team that isn't delivering software in a predictable fashion, and the team always claims that everything is going fine.

Day after day of standups where nothing interesting is spoken of, and sprint after sprint of missed sprint goals is enough to make a ScrumMaster cry. If this is the case for you, then you need to fix this!

Here are some methods on "loosening up" a team so they share their problems:

Ask questions about tasks which aren't progressing very well (a 1 day task going into its third day)
Encourage risk taking and nontraditional ideas, activities and actions
Figure out how to make it OK to "call uncle" so you know they need help.
Don't immediately judge impediments: "That is too big to tackle, just live with it," or "that is such a small impediment when I know there are some really large ones that are holding us back."[1] The team is supposed to air impediments, not be told to air only the impediments the organization wants to handle.
When an impediment is discovered, track them! Put them on a big visible chart of some kind. Don't try and be a "waiter" that takes their teams "orders." Unlike working in a diner, the cycle time of solving impediments takes more than twenty minutes, and usually up to 24 hours. Within thirty minutes after standup, no one remembers what happened though the person who brought it up will remember at standup the next day. The impediments should be visible in the team area so that everyone knows the status of them.
Celebrate whenever an impediment is brought up. Usually an "atta-boy" will work.
Acknowledge people in a public setting for exposing impediments.

For each day that your team reveals "no impediments" get worried because something is really wrong with the process. If they are consciously avoiding to reveal them to you, there is a trust issue. If they are un-conscious of their impediments and living with a lot of burden, then figure out how to change their perspectives. (I'll blog on this topic next.)

It's a tough life being a ScrumMaster. You rely on those doing the work to tell you what ails them, and you can't help them if you don't know what the problems are. You can't be a ScrumMaster if they won't tell you of their problems. You can't be a ScrumMaster if they don't trust you to take their problems and treat them in a way that works both for the team and for the organization.

You can't solve problems that you don't know about.

If all else fails, embarrass them: Tell them you'll cry if they won't do their jobs and open up about what isn't working.

No one likes to see a ScrumMaster cry.

[1] One time during a standup, I brought up two impediments, each of which were quickly judged by an attending manager as one being too hard, and the other too small when there were other bigger problems. These are signs of a reluctance to change. If an organization can't be bothered to fix small problems or is unwilling to do so, then the adapt part of Scrum is broken outside of the team's scope and that is a sad situation.

Good stories have Great titles

2009-01-16T15:18:00.000-08:00

When you read a good book, you can quickly refer to it by its title: We, Animal Farm, The Left Hand of Darkness. Having a title saves you the time of recapping the plot in order to establish that you and someone else know what the story is about.

Every day, Scrum teams do a 15 minute standup during which they describe to their team how they've spent their development time. I've noticed that teams which have been coached to use the "as a user" format of stories (credited to Rachel Davies & Tim Mackinnon, promulgated by Mike Cohen and many others including my self), create an impediment by giving their stories ID numbers instead of titles. "I worked on client authentication" turns into "I worked on story 6933," and most of the team doesn't know what this is and often just lets the information fly overhead. Even if they were familiar with 6933, there is less information and more abstraction when assigning numbers, and it's hard to feel an emotional attachment when sharing this number to people ancillary to the team, such as stake holders or perhaps the product owner. These story serial numbers become an impediment to communication.

For a while I coached teams to save that first line for the story title. It's easy to forget though and violates the principle of "once and only once" since the portion of the "as a user" format already contains that information. As a second measure, I coach them to underline the key words on the story card. But teams still end up adding an ID number, and in the heat of giving standup, it's actually hard to parse all the words though easier to rattle off the ID prominently displayed in the upper left-hand side of the task card, so I sometimes end up wasting my breath by saying the number.
Today I was writing some new stories and struck upon something that made felt right:

WHAT I WANT
so ROLE can BUSINESS VALUE

For example:

I've been using this format on my last two projects and have been very happy so far. I like how the story title has the important element coming first: What I Want.

Give it a try, and tell me what you think. I'd love to here your comments. Let's not try to describe Animal Farm by giving it some meaningless number, unless we're talking about 1984.

NO info DUMPING

2008-12-15T12:11:00.000-08:00

No Dumping

In the pursuit of good Karma, riches and fame, employees want to provide value to their employers and colleagues. This leads to a compulsion towards DIY (do it yourself), which results in project teams not working in pairs. Working in pairs allows for superior information sharing but due to socialization of DIY, those who avoid pairing are not even conscious of the inefficient mechanisms that they have created to allow them to work alone. One of these mechanisms is the info dump.

What is an info dump?

The other day I was working at home and needed a stapler. I knew it should be in my wife's office so I went there and looked in the drawer where it was supposed to be. It wasn't there so I guessed that my wife, being a busy woman, possibly left it somewhere else. I looked around on the desk and then on some shelves. After five minutes had passed I realized I was going to waste a lot of time unless I got more information. "Honey! . . ."

She was in the living room busy doing work on her laptop. I interrupted her and she knew right where the stapler should be. She said she had left it in a pile of magazines shoved into a different drawer. It took a while to describe the details of the information, which drawer, which desk, what corner to look in, but she eventually dumped the information on me and I went back into her office. I tried to reproduce the steps but after some time I gave up and went back to the living room. "No, not that drawer!" she said and she gave me further instructions. I tried again until I was frustrated and asked her to come take a look.

After a moment she said, "I remember using it when I was cutting out photos." She opened another cabinet and looked. It wasn't in there, but then I remember a pile of photo paper near the printer. I pointed at the purple scissor handles sticking out from beneath the printer stand. It only took a minute to find them!

Why did this work so well?

As soon as she entered the room, the context of her surroundings jogged her memory of where she had last put it. We were working with up to date information about the room. She provided additional information where I could help because I was in the moment. It took very little time when we worked together. While trying to perform DIY, I used up over twenty minutes, randomized my wife's work, and I still didn't get the job done.

Engineering

Coworkers, bosses, and employees asking a small favor, they all want to get things done with minimal disruption to others. People working on the same project often divide the work and then DIY until they are really stuck like I was. This leads to waste and each individual becomes a silo of information of how the work was performed. This also leads to conflict when the team members integrate their work and their designs don't fit together. Instead, if they immediately work together, their collaboration will result in a usable design. When they each DIY, they heavily invest resources in each of their own designs so when they integrate their code, they have to decide who wins. They both lose in the end since the project will finish only as fast as the slowest item of work.

Conclusions

Now that you know what in info dump is, watch for it in your office and you'll see it happen over and over. Two people will get together to discuss adding functionality and invest time in one of the below Info Dump Anti-Patterns. Each requires a significant amount of time and then also requires future iterations of doing it over again once new information is found. From my experience, it always takes more time to use info dumps and try to work in parallel, than to serialize the work and have two parties work side by side at one workstation. At that workstation, they execute a "doing" strategy where, in the moment of "doing", the pair can immediately discuss, make decisions, and execute; discuss, make decisions and execute; . . . Below are some anti-patterns I've observed in the wild.

Info Dump Anti-Patterns

Each pattern has two roles: the "implementer" (the person doing the work), and the expert (the person who has a little more history and more knowledge about how the work could be done).

Mental Gymnastics - This occurs when two (or more) people discuss a coding related problem for 20 minutes or more. It's not possible know the code base well enough to be this detailed. The discussion will contain inaccuracies but the participants continue like it's some kind of limbering of the mind, or mental gymnastics. Even more waste happens when these two gymnasts argue over their recollections on how the code operates. When the gymnastics is over, the implementer goes to her workstation and within minutes, discovers that the code works differently than either of them thought. At that point, she either redesigns a solution by herself (DIY) or goes back to the expert and updates him, and then they have another session of mental gymnastics. I've seen this process repeated up to four times in one day.

Tome of Knowledge - The expert spends half the day (or more) writing a design document. At best, it is written immediately after reviewing the code so the information is accurate on that day. The tome is given to the implementer and hopefully the implementer does the work before the information is out of date. Even with an up to date tome, the implementer's knowledge is incomplete and has to visit the expert for a session of mental gymnastics.

No Do, just Code Review - The expert and the implementer sit together at a workstation to learn how the code works. The benefit is that the information is completely up to date and the session is interactive between the implementer and expert. But since they don't actual "do" any coding, they perform mental gymnastics to predict design changes and guess at how the new functionality will hook in. Ideally, the implementer immediately develops the code after the code review. But before the hour is over, the implementer starts to find challenges in getting the code to work as expected. So the implementer performs DIY or often needs to visit the expert for more mental gymnastics, tome updates, or code reviews.

Agile's PR problem--people who don't do it right give Agile a bad name

2008-12-04T14:17:00.000-08:00

Jim Shore posted an interesting blog, The Decline and Fall of Agile.

It's well thought out and genuine and I agree with him except saying it's the "decline and fall of agile" felt like a fear tactic to get notice. (terror!)

I'll go this far: Agile is going to have a PR problem.

Scrum allows one to teach agile planning without agile engineering.
Sometimes you can't fix everything at once. When you go into an organization that is doing up-front (but not really since the requirements always change) and teach them to do agile, if you can get them to at least execute Scrum and have them doing it all rather than Scrum (but not really) you have improved the situation.

Are they going to struggle if they aren't doing XP practices? Hell yes. Some of them evolve a little to automate their tests and many evolve to Water Scrum (a waterfall life-cycle during the sprint so two weeks development, two weeks of "stabilization for testing", terrible stuff really, but they do a lot of planning just like Jim said. And that's an improvement because they have closer to truth about the state of things).

Also, I have been involved in agile roll outs that teach both Scrum and XP. It's really expensive to the organization to do booth, both in time and money. I'm with Jim in saying that it's going to be cheaper in the long haul, but it does create a high barrier to winning business.

The existence of consulting gigs to make Agile teams better is a better situation for the client because their mistakes are costing them less.

Just another Westside Story (the Wiki's versus Sharepoint)

2008-11-10T09:45:00.000-08:00

There has been a battle at my company over how to store and disseminate knowledge. We (speaking as a member of development) have used the Confluence wiki for many years and were happy with it. But less technical staff such as managers, marketing, and sales really hated it. So there was a shift at the IT management level to move everyone to Sharepoint. Their main argument was that Sharepoint was free due to our MS licensing agreements.

It turns out that it wasn't really free because it required many resources from IT to actually get the system up and running in an organized and useful fashion, and even then, development hated it because managing content using a word processor was heavy weight compared to editing a wiki page. (Using a wiki page is nearly as simple as writing things down into a text file.) The non-development types will disagree with this saying that Sharepoint is easy because it is like a word processor, a tool they are familiar with. But the type of work they do is more akin to publishing results where development uses a wiki for knowledge dissemination and creation, more akin to jotting down notes. If it isn't quick and easy to do, developers will just live without doing it at all and this will create some efficiency losses. For development tools, throughput is king, not tools for making things look pretty.

Sharepoint supporters will also say that there is a wiki in Sharepoint. But its really an abuse of the term. It comes with a rich-text editor which gets in the way of everything that makes using a wiki nearly as easy as creating plain text files. The Sharepoint wiki is a great way to persuade everyone to retreat back to the word-file/upload/download paradigm that is native to Sharepoint.
This creates problem's in development. The best team collaboration pattern is a community of cross-functional team members that change/maintain the team's knowledge sharing system with little effort. (It's like Web2.0 content communities versus Web1.0 web pages.)
IT's push to sharepoint caused some splinter groups in development: one faction moved to Sharepoint, a faction of development stayed with Confluence (though under threat from IT that they would pull the plug), and a new faction organized around media-wiki.
The later two groups formed out of frustration of using Sharepoint.

Recently, I was coaching one of the team's that kept their documentation in Sharepoint. Only one or two people bothered to put add/maintain information in Sharepoint. Many did use the site as readers. This created a culture of very little documentation which was out of date. When I moved some of their documentation to mediawiki, suddenly more people started updating any problems they saw and added more documentation. It was amazing to see how using the right tool enabled this to happen.

I've been working with wikis since 2001 and one thing that holds true is that there is a small learning curve that some members of the team may not cross, unless they are pairing with someone to get them going. I've found one simple exercise that quickly gets people using wikis is to ask them to add their contact information to the team's wiki. (Put it on the backlog if they aren't taking it seriously.) To perform this milk run, they are exposed to a few tools which gets them immediately productive, and with that critical mass knowledge, they know how to find more advanced features or how to use existing pages as pedagogical devices. Learning from existing pages is a property that Sharepoint lacks. Sharepoint relies on the usual hunting through menus and buttons because there isn't any "markup source" that can be used to learn from other people's postings.

Remember that wiki means quick. If a wiki doesn't fit this term, then find one that does. Otherwise, no one will use it and that free Sharepoint tool is going to cost you.

VBA script for cleaning .XLS when Gettings Stories out of Rally

2008-10-14T17:42:00.000-07:00

Remember in a previous posting about The Mail Merge method of exporting your stories from Rally where I complained about the work necessary to remove all the markup from the spreadsheet? A listener to this agile confessional took it upon himself to create a VBA script to automate this step. Let's give Pete Turner an Internet thanks for sharing! :-)

Paste the VBA text file into your into your “personal macro workbook." Yyou should be able to open with ALT+F11. If that doesn’t work, try unhiding it using View > Window > Unhide.
You can run the macro with View > Macros

Have fun!

Maven: The coolest build tool ever!

2008-10-03T14:25:00.000-07:00

I've been through the grinder on build tools: typing in VIC20 BASIC, building from the command line, building from .sh scripts, building from make, building from xmake, building from IDEs, building from nant.

It's been a glorious twenty-eight years of software development (including grade school years of software development). I've been hearing things about maven. A few people love it; many don't like maven. I've stayed away from the arguments and kept clinging to my Nant and Eclipse build tools, but now I've landed on a project that's using maven 2.0.9. I have an excuse to dive in!
And I really love it!

It was tough at first, but when I look at the time I dumped into learning Make and its implied rules, it really wasn't so bad. The documentation on "the internets" (thank you Mr. Bush) is pretty minimal, maybe enough if you already understand the big concepts. There is a new book out this month that looks promising: Maven: The Definitive Guide With only the Internet, I probably would have stayed a frustrated Maven user except a smart cookie named Jeff Ramsdale gave a colleague and I a thirty minute intro. To give back to the internets and to put my notes on maven somewhere, here is my high level understanding of organizing a maven project. I'm sure you'll correct me by commenting if I'm out in the weeds.

Lifecylce

Maven drives everything via a lifecycle. This lifecycle is built into maven:

validate - validate the project is correct and all necessary information is available
compile - compile the source code of the project
test - test the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed
package - take the compiled code and package it in its distributable format, such as a JAR.
integration-test - process and deploy the package if necessary into an environment where integration tests can be run
verify - run any checks to verify the package is valid and meets quality criteria
install - install the package into the local repository, for use as a dependency in other projects locally
deploy - done in an integration or release environment, copies the final package to the remote repository for sharing with other developers and projects.

A portion of this lifecycle is called a phase, so the above is a list of phases. Maven has a configuration file called a pom.xml. When you invoke maven: $mvn, it looks at the nearest pom.xml and by default, it uses the "install" lifecycle. Since install is number 7 in the above list, maven goes through phases 1, 2, 3,...,7 and may perform operations based on what is in the pom.xml. You can also do a $mvn deploy and mention the phase right in the command line.

Profiles

Profiles are an abstraction layer on top of the lifecyle. Creating a profile allows you to create configurations which affect how things are done. For example, on our project, we have some integration tests which take two hours to run and we have two integration tests that take ten seconds to run. Before we check in, we want to run those quick integration tests but not the long ones. So we explicitly named the two integration tests in the configuration for the surefire plugin (a junit test runner in maven) which runs the two quick integration tests in the integration_test phase when $mvn is executed.

For the slow integration tests, we created a profile "all_integration_tests" which re-configures the surefire plugin to include running the slower integration tests too (using the naming convention of *IntegrationTest.java) when $mvn -pall_integration_tests is executed.

Goals

Goals are like arguments you use to tell a plug-in what to do. By the way, everything in maven is a plug-in so plug-in's are first class citizens in maven. A goal is an argument that you pass to the plug-in. I don't have more to say about goals because I haven't had to use them much. :-)

After all, you've gotta save something for later.

The Mail Merge method of exporting your stories from Rally

2008-10-02T10:55:00.000-07:00

Chris Sterling, a great agile coach who I get to work with, showed me how to export stories from Rally in a more sophisticated fashion than the PowerPoint method. These steps build upon what he had shown me. Again, this is all about getting the story information out of Rally and into a physical medium which can be easily interacted with by a large group of people, thus removing impediments to collaboration when we are in the same physical space.

This process will produce stories on "cards", two "cards" per sheet of paper. Before the planning event, I use a cutting board to split the sheets into two. I'd give myself an hour before the planning event to get through this process until you are experienced.

Getting the stories out of Rally and into Excel

Use the same steps mentioned in the PowerPoint method and stop after doing the Processing the CSV with Excel step. If you want a stack of cards at the end of this process that are sorted by rank, then make sure your spreadsheet is sorted by rank (or that Rally is sorted by rank) so you won't have to do this by hand.

Setup the Mail Merge

The following directions describe how to do this in Word 2007. Download the mail merge template and open it into Word. The first time you open the file it will give you an error message saying: "Opening this document will run the following SQL command:" because it is trying to load up the .xls file which I used for mail merge. You should tell it "No," though no harm is done if you say yes other than getting a cranky error message.

In the toolbar, click on "Mailing".
The buttons in the "Mailing" toolbar are arranged in a type of life cycle arrangement. Since I'm providing the template, you won't necessarily use all the buttons to get to the last one, "Finish & Merge." Notice the merge fields, which are the groupings surrounded by "<<" and ">>". These are the same as the column names in the .xls file. The data that is inserted into the merg fields will match the font characteristics of the merge fields.

Loading the Excel file & Preview

Because we are using a mail merge utility, it's wording things in the way of "mailings." For us, our set of stories are mail recipients, so the language of the buttons is going to be weird. Click "Select Recipients"->"Use Existing List" and select the .xls which was produced in the earlier step.
Now you can click on "Preview Results" and see how things look.
Now you can exit the preview and adjust the styles as you want. I made the first line largest and easiest to read and loaded it with what I've found to be the most important info we needed for planning. I also crammed as much info as I could onto the sheet of paper. You may have different needs so you may want to exit preview mode and edit the template. The "«Next Record»" merge field means to populate the 2nd "card" on the sheet of paper with the next record. Without this, you'll end up with two copies of the same "card" on each sheet of paper. The darkened background uses up more printer toner, though the team I was working with was taping the "cards" to a white board so they wanted them to stand out.

Finish & Merge

MSWord's mail merge preview has bugs so don't be surprised to see duplicate story cards show up. A phenomena I've seen is where the last story on the virtual sheet, shows up as the first story on the next sheet. This actually isn't the case. Click "Finish & Merge"->"Edit individual documents" to prove this to yourself before selecting "Finish & Merge"->"Print documents..." and sending the job to the printer.

Split the sheets in half with a cutting board, and find a roll of tape, and now you are ready for you planning event!

Further Improvements

An impediment list can be made stronger by exposing the cost to our processes. In the below list, the bigger the number the bigger the cost. I'm using a geometric series.

16 I'd like to avoid the "cleaning" of the markup from the spreadsheet. Anyone know how to turn those Excel cells into something that accepts the markup? Or perhaps there is a Rally configuration that will scrub that markup out of my .csv?

2 I did this process a few times with Avery card stock but this seemed wasteful since there is a lot of paper boarders that aren't used and the cards, albeit nice and thick, aren't necessary. It would be great to buy reams of paper which are perforated to tear in half.

Update: Thanks to Pete Turner, I've added a later posting about a VBA script which cleans up the .xsl file: VBA script for cleaning .XLS when Gettings Stories out of Rally.

Exporting From Rally to task cards--the Power Point method

2008-09-24T14:44:00.000-07:00

Exporting from Rally is possible though not pleasant. I spent at least 2 hours trying to work it out the first time with someone's help. Even after I got the the process down, it still takes about one hour. In theory, I think I could do it in fifteen or thirty minutes, but every time I try, something comes up that I need to react to. (Like printing off the wrong backlog.) So I'd practice this once and then give your self at least an hour before the planning event to get ready.

Here are the tools you need:

Rally -- This contains the backlog. You'll need to create a custom view to get the "Description" on the card. We'll use the CSV export feature.
Excel (or OpenOffice) -- Use this to clean up any formatting HTML that rally has exported, read in the CSV and then copy past the rows into Word.
Word (or OpenOffice) -- Use Word to create a .doc file.
Power Point (haven't tried this with OpenOffice's Present) -- Read in the word doc which will covert the content into slides, and then print the slides.

The steps to get a Rally backlog into cards/paper:

Export to CSV

You need to show your backlog on a Rally view. My favorite is at "Backlogs & Schedules"->"User Stories" because it seems to be the most flexible with filtering. If that isn't good enough, you can create your own custom view.

When you select Action->export to CSV, Rally will export whatever you are showing, in the order you are showing. So if you are missing a column of information, like the story's description, you'll need to create a new view (see the icon with the plus above the Release column in Rally, circa 8/22/2008, use this to add what columns you need). You'll probably want to sort by the *Rank* column.
Columns I like to have in my custom "Export to CSV" view are : Rank, Formmatted ID, Name, Schedule State, Blocked, Description, Release, Plan Estimate, Notes, Iteration, Owner, Last Update Date.

Processing the CSV with Excel

In Excel, open the CSV that you've exported.

Cleaning the RTF-markup from the Story Description
If you've exported the story description, there is always some work in cleaning the data of rich-text markup. Take a look at the description column and you'll see what I mean.
If you've never used any of the rich-text features (bullets, underlining, copy and pasting from a rich-text document such as MSWord) then cleaning up any remaining formatting is tractable.
Using Find-Replace-All, you can clean up the markup. Replace the following with nothing:

Replace the following with a space: "&NBSP;"
Look over the Description column and remove more choice bits of markup cluttering your data:

Other things to do:
If you exported the Blocked field from Rally, you'll want to select that excel column and do a find-replace-all on "True" to "blocked", and "False" to nothing.

Make a Word Document

Swap the excel columns so they show up in an order that makes sense, and delete the columns that you don't want. Highlight the rows you want to print out, copy/paste them into a word processor, and then save the file to a MSWord .doc.

Adjust the layout in Power Point

In Power Point (I'm using power point 2007), the name of the game is adjusting the format of the font so that it fits on the slides without pushing into the next slide. When you get it looking pretty, print it. What I do to get things looking good is edit the master slide to be one big text box and change the font size to about 20. Then I leave the master slide view, go to the left hand slide selection area, do a ctrl-A, click on Layout->select my theme. And then all the slides are using my theme.

Power point is great if you are OK applying one formatting style to the whole slide. Ideally, you want to produce something like in this:

But I don't know how to apply different formatting to different sections of the slide using this method. The only way I know how to do that is using Mail merge which I'll post about later. With this method, you can get a backlog out of Rally and onto paper and then tape the paper on the walls for your agile planning events.

If you know of any refinements to this or any other ways to get data out of Rally and onto cards or paper, then I beg you to comment!

A Tale of Tasks Boards and Electronic Project Planners

2008-08-28T14:40:00.000-07:00

Using electronic tools for agile planning initially seems like a great idea:

You have access to it anywhere you have access to the InterWeb,
You save environmental resources because you don't have to print things out,
You can quickly search through requirements since there is a DB,
Auditing and revision tracking can be applied so you can see what changed and pose the question to someone--why did you change to that?
You have a backup.

The problem with electronic planners is that:

They are easier to ignore than a big task board.
They are hard to use by a group during a meeting.
They don't allow spacial organization where task boards can have layout schemes that fit the problem at hand.
They suck the energy out of the users. The activity of getting up out of your chair and moving things around on a wall gets the blood and energy flowing.
They aren't as flexible. Task boards are limited to the imagination where electronic tools are limited by the code.

When I started doing eXtremeProgramming in 1999, we only used a task board. Today, many projects I work on use tools like Rally because nine times out of ten, we work with an off site product owner. This sucks and slows us down, but using Rally gives the product owner a way to manage the backlog.

Using Rally becomes an impediment when the product owner and team can meet and work together on release planning, backlog grooming, and sprint planning, because during these meetings, physical cards really get things done faster and with more energy than using Rally (with a project). Remember a principle of agile is interaction over documentation, and fiddling with Rally is much less interactive and quickly feels more like a document review than a discussion over acceptance criteria on a story.

It's critical that electronic planning tools make it easy to convert to physical collateral which can be worked with in our three dimensional space where it can be slapped on a wall via a sticky, (or a card with tape) and moved around.

This isn't easy to do in Rally. But it is possible. Watch for my upcoming posts on this topic.