Part 1 was all about setting the scene; there are many software development teams who are working in an ad-hoc way and are desperately looking for improvements in the processes that define their working lives and their business. This is important for everyone across the organization - there will be benefits for the developers, the management and the customer. As always a benefit comes with a price for each group - the developers need to pace themselves and get organised - the managers need to be more flexible with their communications to both and the customer will have some tough negotiations to make on priorities. But the detail of all that comes later - what comes first? Well in part 2 we're going to focus on gathering data about what's going on and starting to gain some benefit from that. The data is the content that makes up Card Conversation Confirmation, once you've got that data many things quickly become clear and the process of persuading and influencing the extended team and the entire organization that there is a better way of doing things can begin. But the most important thing is that the team needs to just get on with making the changes without waiting for executive decisions - there's no need for an executive decision because the team doesn't need to spend any new money - the team is presumably expected to do what ever is necessary to be as productive as possible - so what's holding that up?
The Agile Manifesto
But just before we do that lets anchor the rest of the journey with some key statements - key agile advice statements from the agile manifesto - it states the following:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on
the right, we value the items on the left more.
These statements from the agile manifesto are all encompassing for agile software development - when ever a team hits a situation where their doubt over how best to proceed the agile manifesto will give guidance (A practical discussion of these statements will follow in the appendix).
So for this first step we're going to anchor the team to the second statement in the agile manifesto "Working Software over Comprehensive Documentation". Card Conversation Confirmation will give the team a substrate for practise to facilitate this principle. The ad-hoc functioning team is already producing working software - at least its working well enough that they remain in business - after all nothing is perfect - but the team is accepting that there is room for improvement. Never the less the team is producing working software so this must be preserved once the collection of data for Card Conversation Confirmation begins. However, every change requires some kind of investment and in this case the team must accept and carefully manage and communicate a likely small reduction in the volume of "working software" they produce over the next short term period. This is likely because the team is giving itself another task to perform but isn't growing - there are no new team members coming on board. This additional task shouldn't have a significant impact - it doesn't require lots of time - it is more a case of requiring discipline to record what's happing. Its precisely because of these types of impact that a key datum in this initial exercise is estimates.
Card Conversation Confirmation
Known as the 3Cs there are 3 categories of data to start collecting. If the team is just running one project then this will be relatively simple - it is more complex if there are several projects but the best way to approach this is to apply the new practice to all current and new projects. It is important not to apply the practice retrospectively to work that has been completed as this is probably already "working software" at least in the broadest sense that the developer thinks he's finished. Initially this sounds odd - the team are 40% way through the project so they know that the latter 60% is going to be well documented but the rest is going to be in its usual ad-hoc state. This concern can take up space in the team's minds - it doesn't sit comfortably until they realise that this is perfect in fact because this dichotomy across the finished work will provide the first evidence that there are benefits. Suppose during the final testing just before a deployment and there are something like 3 P1 and 27 P2 bugs to fix after the first round - not a good place to be normally. But, on this first project where the new practice is being applied suppose the 3P1s the serious gated bugs are all from that 40% of the code that was written before the change in practice and 19 of the 27 P2s were also in there? These figures are there to illustrate my point - if the team gets to testing and the spread isn’t looking like this then the new practice isn't being followed properly - simple as that. Keep at it - keep making improvements and when there is significant data in testing that draws this kind of picture it’s possible to begin to make the case for change and influence future executive decisions that may be required for bigger changes down the line.
The medium for Card Conversation Confirmation was originally index cards but a simple MS Excel file quite useful (cardconversationconfirmation.com will be available in beta in April). One file per project is best and its useful to to have a summary page that shows the list of user stories and their estimates and status. One status may be "not defined" - so at least there is somewhere to start listing all the stories for more work later. This list can also be arranged into groups or themes - a theme should contain stories that have something in common. They can also be grouped into sprints or iterations - this is called a product backlog i.e. all the stuff that needs doing in priority order. The priority order is fundamental to the success of this process - only define a story when it is near the top of the list and don't start the development until it gets to the top of the list. This is a very disciplined way of deliberately not defining all the requirements at the outset but with a schedule of when it will get defined.
As Excel is more limited in how many tabs a workbook can have as to how many rows a worksheet can have, use a separate tab for each theme - if it s really big project define a second layer of themes and use several workbooks. Each sheet has a structure as follows repeated for how ever many User Stories are in that theme:
Card = As a user I want some feature so that I can perform some function.
Conversation = An initial question or statement in the first column and subsequent comments in subsequent columns.
Confirmation = A list of Satisfaction Criteria - not tests scripts - just low level definition of what the feature does, doesn't do and how it behaves if the user doesn't use it correctly.
Each section is then owned by different roles thus:
Card is owned by the customer and product owner - they are responsible for ensuring all the stories are present in the document.
Conversation is owned by the developers - they are responsible for making sure all the conversation necessary to clarify the User Story and mitigate ambiguity is present in the document.
Confirmation is owned by the testers - they are responsible for making sure there is a satisfaction criterion that covers all conclusions within the conversation.
Although the sections are owned by different roles they can be contributed to by anyone. The summary page is owned by the project manager. Once a story is in the document everyone on the team is responsible for making sure that actual conversation whether verbal, meetings or quick chats in the corridor, or on email or any other medium is recorded in the document. When a story gets to the top of the product backlog and is about to be worked on it must be reviewed in detail by the whole team and again at customer review or testing - this is accomplished through a regular meeting (ideally one that takes place on the first day of each sprint and the day prior to review). It’s at these two points where disputes over whether some conversation has been omitted are most likely to surface - more on how to handle that later.
In part three we'll look closer at the structure and process around each section of the Card Conversation Confirmation document.