Agile 2006: Agile Requirements Workshop: Essentials for Planning, Design, and Facilitation – Ellen Gottesdiener

Tuesday 13:30-17:00

Abstract

Facilitating an agile requirements workshop requires a great deal of preparation and particular facilitation skills.

Summary

Workshops are different from meetings. They require more pre-work, and anything that must be decided in the workshop should be clarified beforehand. Workshops often encourage “serious play” rather than just discussion.

For Agile Requirements workshops, it may be necessary to hold one or more per release or iteration. The whole team participates, including customers, QA/testing, and developers. The customer can help to identify who needs to be represented. Good workshops should have no more than fifteen participants at the most. Surrogate users are not ideal – the customer’s needs can’t be guessed. If it can’t be avoided, get more training for the surrogate users.

The facilitator needs to use tools to jump-start workshops, e.g. for a workshop to produce use cases, provide a list of good verbs to use and some examples. The facilitator also needs to manage the “chaos”, and bring out the introverts. One of the greatest skills in facilitation is observation.

When designing a workshop, the purpose must be clear – why is this workshop being held? It may be necessary to consult with the participants prior to the workshop to ensure the purpose is correct. It must be linked to the project purpose, and for requirements workshops, the higher level scope should have already been agreed on.

It may be necessary to create a workshop planning team. If the workshop goes off target or isn’t working, the planning team can call a break and discuss how to adjust the process. The workshop facilitator must be neutral. The workshop should have defined behavioural rules – ensure the team know them, and call out if they are broken.

It must be clear what “done enough” means in the workshop. When are the models good enough, or complete enough? How precise must each deliverable be? The facilitator must know this in advance. The workshop products should be listed in components – models should be broken down to lead the group in tasks to get to them.

The workshop space is important – the room needs to be set up ahead of time, food is important – don’t work through lunch.

Kickstart the workshop activities – begin with an image – “imagine you are a user trying to … [fill in the blanks] – what pieces of information do you need to input?”

Always complete the workshop with a retrospective on the workshop – how did it go?

Key points

  • Prepare properly for agile requirements workshops.
  • Use energizer activities to get people involved at the beginning.
  • Define outcomes of workshops more clearly.

Recommended further reading

Decide how to decide – http://www.ebgconsulting.com/pubs/Articles/DecideHowToDecide-Gottesdiener.pdf
Ground rules resources – Roger Schwarz http://www.schwarzassociates.com/facilitator/37/Products/
Team Retrospectives for better Iterations Assessment – Ellen Gottesdiener
http://www.ebgconsulting.com/pubs/Articles/TeamRetrospectives-Gottesdiener.pdf
The powerpoint provides a great deal of further information and examples.

Agile 2006: Agile/Evolutionary Database Techniques – Scott Ambler

Monday 16:15-17:00

Abstract

Database design and refactoring can be done in an agile and evolutionary way.

Summary

Data is only one of the many important aspects of software development, and rarely a primary one. Agile is developed from the “object” community, and sometimes suffers from a blind spot with regard to database development.

Databases can be built incrementally, with an evolutionary approach within the agile model. At the start of the project, spend around ten or fifteen minutes with the business owner to define the database structure at a high level – at this stage, attributes and behaviors are not discussed.

Having a small amount of upfront modeling is useful to avoid major changes later – but it is not necessary to do the amount of upfront modeling advocated by traditionalists.

The database is then built iteratively, evolving in the same way as the objects, with just enough tables and attributes at each stage to support the system. Visual Team Studio for Data Professionals supports this approach for database engineers.

Often expectations of the data community are low, we don’t expect them to be able to do “trivial” things, such as adding a field to a production database. But databases can be refactored while retaining both behavioural and informational semantics – in other words, without messing up the data.

Databases are generally tightly coupled to applications. Refactoring a production database, for example changing a field name, therefore affects a lot of applications. However, it can be done by creating a new field with a new name, using triggers to ensure it is kept up to date, and using a short transition period to allow developers to update all of the applications that will be affected. The “scaffolding code” is then removed.

Coupling is the main enemy of database refactoring – if this can be reduced, refactoring databases becomes more straightforward.

Recommended further reading
Agile Model Driven Development: http://www.agilemodeling.com/essays/amdd.htm

Agile 2006: Team Dynamics – Esther Derby

Monday 15:30-16:15

Abstract

Only 5% of teams ever reach the “high performing” stage – but being aware of how teams form and what practices are needed can help to increase the chance of becoming a true high performing team.

Summary

It takes social engineering to make great teams – it doesn’t happen by accident. Good teams that people have worked on tend to be small, passionate, and focused on one common goal.

In teams with more than ten people, communication overhead grows, and teams tend not to perform as well. Good teams usually have an agreed-upon approach to the work – XP has specific practices that promote this – pair programming, refactoring, coding standards, and so on.

Teams should be made up of people with complementary skills – not the same skills, although there should be some overlap. Good teams have interdependent interim goals – such as user stories – which mean they can be successful quickly. As is especially true of agile teams, they make commitments to each other and are not hierarchical.

Team creation goes through several stages (refer to the powerpoint for the diagram of the model):

Orientation: “why am I here?”
The team need to get clear on this first!

Trust building: “who are you and can I trust you?”
Mistrustful teams are guarded, hold back and are less creative. Trustful teams accept feedback and deal with conflict. They trust in each other’s professional competence, and that their intentions for the team are good. In teams with one star performer, trust for others is low, and they tend to be less productive.
Avoiding conflict erodes trust, by resolving issues people build trust.

Goal clarification: “what are we doing?”
When teams aren’t clear on this, they become apathetic, and irrelevant competition starts to happen.

Commitment: the team ask “how will we do it?”
If this is absent, the team will snipe at each other. People who don’t have power and control over what they commit to, don’t commit. Removing the fear, and allowing people to make small promises means they can commit to something realistic.

Implementation: in agile projects, this is done through stand-up meetings, retrospectives, reviews, and talking to customers.
High performance: at this stage, teams are having fun, and producing. Only around 5% of teams ever reach this stage.

Renewal: There are some critical skills necessary to achieve high performance. Teams must navigate conflict. Often people don’t hear each other properly, and conflict can be down to misunderstanding – in these cases it’s good to review the data. Peer-to-peer feedback – not just up and down – is necessary to build trust on high performing teams.

Agile 2006 – Demonstrating Responsibility: the Mindset of an Agile Leader – Christopher Avery

Monday 13:30-15:00

Abstract

Responsibility is a skill that can be self-taught by becoming aware of the responsibility process, and refusing to operate from any of the stages below taking responsibility ourselves.

Summary

Being accountable is not the same as being responsible. Accountability, or being held to account, is external – determined through a management hierarchy. Responsibility is internal, having the ability to respond, a sense of ownership of the issue.

We know what responsibility means – so how is it that so many responsible people do highly irresponsible things? Many experts and books say we should take 100% responsibility – but few explain how.

People are more able than they realize to solve problems simply by responding to them in a different way. Responsibility is not a character trait – it’s a skill, which can be taught directly. The responsibility process goes through six stages or steps.

No personal learning occurs at the bottom levels of the responsibility process, until we start taking responsibility. The key is to become aware of the responsibility process, to develop an awareness of how we are reacting to problems, and refuse to operate from any of the lower stages.

It is a challenge to adopt – subconsciously we will resist it, and it can result in exposure that is humbling and politically unsafe. It doesn’t work as a management tool – it can only be self applied, and as a leadership tool, should be suggested after the problem – not during.

Key points

  • Become aware of where I am in the responsibility process and “refuse to operate from any of the lower stages”.
  • Can be used as a tool for a Scrum team to learn to become self-managed and take responsibility.

Recommended further reading

The Declaration of Interdependence – Six Principles to Benefit You and Your Agile Organization – Alistair Cockburn, Better Software Magazine, June 2006

The powerpoint contains further notes and explanations.

Agile 2006: Refactoring Games – Alan Harriman, Joshua Kerievsky

Monday 11:00-12:30

Abstract

There are many different types of code smells, refactorings, and quality criteria. The goal of this session was to use games to learn several techniques related to refactoring.

Summary

All of the games are played with a card deck produced by Industrial Logic, containing green Quality cards, yellow Code Smell cards, and blue Refactoring cards. The deck is fairly extensive – some examples are included below. Each card also contains an explanation of the quality, smell, or refactoring.

Overall, this was a decent, eye opening session that introduced a number of concepts in an interesting way. I do intend to try these with my team and report back on their success!

Game 1 – Rating the value of different types of refactoring using Refactoring War
This game reminded me of Top Trumps. Players have a set of cards of refactoring types, turn over the top card, and rate each one. The player whose card scores the highest keeps all of the cards.

The cards are scored on two criteria: frequency of use and design impact. The team works together to assign a score between 1 and 5 for each criteria and then add them together.

The “war” occurs when the team thinks that two or more cards are of equal highest value. In this case, players holding these cards flip over a new card on top and repeat the exercise.

The objective is simply to get teams discussing the different types of refactoring, get more familiar with the techniques and start to recognize when they can be applied. Without more background in refactoring, the game feels strange the first time it’s played, but over time it would probably be a useful exercise to keep teams thinking about the code that they’re writing and learn to recognize smells and apply refactoring techniques.

Game 2 – Identifying relevant refactorings in Refactoring Hunt
Players study several smelly code snippets and evaluate which of the refactoring cards could be applied to clean up the code. Each card can be applied to one piece of code or set aside if it doesn’t apply to any. Once all of the cards have been assigned, the team reviews the suggested solution.

The objective of the game is to help the team start to recognize how to apply refactorings. There was a lot of disagreement over whether the suggested solution was right, which wasn’t as constructive as it could have been. A better variation might have been to suggest that there;s no “right” solution, but simply let teams compare and discuss their own.

Game 3 – Relating code smells to qualities in Qualitaire
The team lay out the large green quality cards, then decide for each code smell card: “Which quality would be the best fix for code that suffers from this Smell?” Again, once the game is complete, the team reviews the suggested solution.

The objective of this game is to familiarize the team with code qualities, and identify the smells that prevent good quality code. As in Refactoring Hunt, the discussions were the most valuable part of the game, and having a suggested solution caused more disagreement than good discussion.

Example cards
Qualities: highly cohesive, loosely coupled, no duplication, simple, testable.
Refactoring: Substitute algorithm, unify interfaces, change reference to value.
Smells: Oddball solution, duplicated code, long parameter list, long method, feature envy.

Key points to apply

  • The team can learn to refactor in a structured way by familiarization with common code smells, qualities, and specific refactoring techniques.
  • The refactoring games are a great way of introducing this information to the team.
  • The games would have most value from focusing on discussion of solutions, rather than steering the team towards one right solution.

Agile 2006: Agile Testing – Brian Marick

Sunday 16:15-17:00

Summary

One role of an agile tester is to ask questions and catch the error and exception conditions. Testers generally focus on what goes wrong. They have a familiarity with bugs, they look at bugs, learn from them, and generalize. In agile projects, developers should get better at anticipating bugs.

With test driven development, the UI can be created, then the logic implemented. In test driven development, the sequence is:
Write a failing test -> Make it pass -> clean the code.

Cleaning the code is very important.

Exploratory testing or rapid testing is another form of agile testing.

Agile 2006 – Introduction to Agile Project Management – Sanjiv Augustine

Sunday 15:30-16:15

Abstract

Agile project management is different to traditional project management, lean principles can be utilized to manage at the value stream level and reduce waste.

Summary

Agile teams are self organizing – team members have a clear set of responsibilities, and they have the control and power to fulfil them. Trust the team, and they will learn to self organize, it requires a shift in mindset.

Often in large organizations, much of the agile mindset is already happening at grass roots level. Agile adoption just makes it explicit.

It is important in agile project management to manage at the value stream level. This concept comes from lean software development and manufacturing principles. This is the job of the agile project manager.

In traditional waterfall project management, work was done in large batches: design, dev, test, rework – there is a lot of “inventory”. In contrast with agile, small pieces of work move more quickly through the system. In agile projects, the focus should be on project throughput. Reduce utilization – developers should work on only one project at a time, and focus on only one story to avoid the waste in switching tasks.

With more trust between customer and team, a lot of waste in the process is reduced through collaboration. With agile, requirements do not need to be bloated upfront since change is allowed – this lifts a load since corrections are easy and fast.

Reflections, or retrospectives, should be used in agile projects to analyze, adapt and improve processes and practices. The team should answer the questions: what’s going well, what can we improve, and what obstacles or issues are facing the team.

Key points

  • Manage at the value stream level.
  • Reduce utilization of developers – they should only work on one story at a time, one project at a time.
  • Reduce waste through collaboration, and investigate other techniques.

Agile 2006 – Planning and Tracking on Agile Projects – Mike Cohn

Sunday 14:15 – 15:00

Abstract

The first question on a project is always “when will you be done?” Agile planning takes place on three levels, using relative story size and previous performance (velocity) to plan iterations and releases.

Summary

Agile teams plan at the release, iteration and daily level.

Release planning describes “Here’s where I want to be” – so that we can figure out the best way to get there. Releases usually comprise multiple iterations, because stories are “done” at the end of each iteration – not necessarily cohesive. Estimates at this level are ball park numbers – it should take no longer than 3 minutes to get to the estimate for each story. During release planning, the team explore the solution space and negotiate how they can satisfy the customer’s needs.

At the iteration level, tasks are estimated in “hours I thought a lot about”. There is no negotiation on schedule or budget at this level – long iterations with varied lengths don’t work. At the end of the iteration, get feedback of what’s done and left to do.

At the daily level, the daily stand up meeting is used to plan the next day’s work and synchronize the team. This should not become a status meeting.

Humans generally are bad at estimating the duration of a task, but relative sizes are more straightforward. Some teams use t-shirt sizes to estimate stories, but it is difficult to agree on the relativity – is a large story twice the size of a small one, or three times? Story points, which are the most commonly used now, make this straightforward.

A common mistake is to consider the skill of an estimator important – it isn’t. Regardless of time, people can agree on the size of a piece of work.

To estimate velocity, use a range. When considering the long term average, look back 4-5 months and no longer, as the team’s situation will have changed too much if you go back any further. Use the velocity to look at the release plan and estimate where we’ll finish at the slowest velocity and expected velocity. These estimates can be used to reprioritize the stories.

Burndown charts show progress. Teams generally work best when they have slightly aggressive, but not unrealistic, schedules – which is why the end of the burndown chart is usually steeper. Burndown charts raise questions – they don’t answer them, but they identify areas for further discussion and commentary.

The powerpoint contains diagrams, further explanations, and photos of example taskboards.

Key points to put into practice:

  • Use velocity to estimate the relative likelihood of stories being completed in a release, and use this to drive reprioritization.
  • Use burndown charts to identify areas for discussion, where further explanation is needed.
  • Track velocity only about 4-5 months back – changes in the team’s situation can cause velocity to change over time.

Agile 2006 – A Story of Stories – David Hussman

Sunday – 13:30-14:15

Abstract

How to collaborate and write effective user stories.

Summary
Requirements gathering has evolved over time into the form of use cases. Good use cases are short, simple, focus on the use cases and stay current through continued collaboration. Bad use cases replace collaboration, are long and expensive to write.

Burying requirements in long documents doesn’t work. People can’t find or estimate them. Testers, developers and customers interpret them differently.

As an alternative, collaborate to write small, short chunks of work as user stories. Write them down on 3×5 cards and post in a common area for easy access. Let the customer say what done means – and write it on the cards as acceptance tests. In a healthy community, everybody writes the stories.

Hold “story jams” to create the stories (think like music jams – let the creativity flow). Use a long table and invite lots of people. Create personas, and walk through a day in their lives. The list of stories doesn’t need to be complete after the story jam.

Good user stories conform to the INVEST acronym:

  • Independent – breaking dependencies increases agility, so that the business can choose the really valuable stories.
  • Negotiable – they can be changed. Build a ubiquitous language, so that everybody knows what the story really means.
  • Valuable – in terms of the customer, or whoever it’s being built for.
  • Estimable – sized appropriately for accurate estimates.
  • Testable – it’s a story smell if they can’t be tested as done.
  • User stories work because they are available, they bring people together, build trust, promote innovation and are humane. Stories are completed only when the customer signs them off.

Key points to put into practice

  • Review user stories against the invest acronym.
  • Create personas and walk through a day in their lives.
  • Don’t focus on completing ALL of the stories in a story jam.

Recommended further reading

Being Jane Malkovitch – the Life of an XP Customer (included in conference materials)

The powerpoint presentation contains photos and examples of personas, story jamming, and further explanations.

Minneapolis, here I come …

It’s taken me a while to organise, but I’m finally on my way to Agile 2006

I’ve heard mixed opinions on the conference – from the complete evangelist to “too much powerpoint but great networking”. Well, I’m not that averse to powerpoint, I’m definitely not averse to social events, and while I’m still pretty much an agile novice, I already know some of the main areas of difficulty in our organization so it seems like a perfect time to go and network with the experts. I’m also excited that Minneapolis hosts America’s largest indoor water park.

Having left it a bit late to book, I managed to get the last seat on my flight out. Since I’m combining this with a trip to our offices in Seattle, it took me a good hour or so yesterday morning to activate my new credit card and use it to arrange two round trip flights, one conference ticket, accommodation in Minneapolis and Seattle, and car rental for a week in Seattle (I’m hoping the conference hotel really is only four blocks from mine …) Thank God for the Internet, or it might have taken a lot longer … and more importantly, I couldn’t have done it in my pyjamas!

I then wandered over to Oxford Street and spent the afternoon clothes shopping in the sales (I did change out of pyjamas for that). I need new clothes for the conference, right?

See ya there!