Keeping progress visible
It's essential to make the progress made during a sprint or iteration visible to the team and to the product owner or onsite customer. This can be achieved with
Big Visible Charts. I consider the minimum charts to be a burn-up or burn-down chart and a chart showing the acceptance tests passing or failing.
1. Burn-up or burn-down chart
Both types clearly show status and velocity or rate of progress against predications, and provide a visible indication of whether the team is going to finish on time, early or won't finish everything they committed to do. They facilitate early conversations with the onsite customer or product owner regarding a de-scope of user stories from the iteration. I like to have 3 variants of the chart on display: one for the current iteration or sprint, one for the current release, and one for the product backlog.
Personally i cannot decide whether i prefer the burn-up or the burn-down chart and so i employ the one that the team is most comfortable with. Does it matter which version is used? It can do. Firstly, there's the psychological factor of representing progress. Some people prefer moving up such as in mountaineering when climbing towards the summit. Others prefer moving down, where you whittle away until there's nothing left to be done. I think the burn-down chart is more emotionally powerful because reaching zero has special significance for me, motivating me to push ahead and complete my work. Secondly, there's portraying expanding scope.
The burn-up chart copes with this a little more naturally than the burn-down chart. As additional user stories are added, the story point value representing '100% done' on the y-axis is raised.
burnup
Originally uploaded by sjb140470. The burn-down chart (alternative by Mike Cohn) drops the baseline by the amount of extra story points so that the total amount of remaining work is given by the sum of the story point value of the current position on the positive y-axis plus the lowest story point value on the negative y-axis (ignoring the sign), i.e. the new baseline.
burndown
Originally uploaded by sjb140470. 2. Customer acceptance tests passing/failing
I like Ron Jeffries' version of this chart which shows how many customer acceptance tests there are (automated with
FIT,
FitNesse or
Selenium), and how many are pass and fail over time. This provides visibility of progress in terms the onsite customer or product owner understands (because they should have wrote or at least participated in the writing of customer acceptance tests). It's reassuring to see lots of red (failing) tests at the start of an iteration or sprint, with more and more tests turning green (passing) as the functionality evolves and the iteration or sprint proceeds.
fit
Originally uploaded by sjb140470. A variation on this chart displays the acceptance tests in a matrix, with each cell assuming a green or red colour depending on whether the test passes or fails.
Tags:
agile,
information radiator,
big visible chart
Links to this post
Being an effective Onsite Customer or Product Owner
Agile projects demand Real Customer Involvement. To be an effective Onsite Customer or Product Owner, you must either be a real customer, or be in a position to accurately represent the real customer. You must acknowledge the elevated status you hold and accept the responsibilities that accompany it (Accepted Responsibility). You must be a stakeholder and a fully integrated member of the team. You must be accessible and you must participate in the project proactively and continuously. You must recognise that through your actions - writing user stories and acceptance tests, prioritising user stories by business value, deciding which user stories are developed next, providing rapid feedback, etc - you are effectively steering the project and are ultimately responsible for the business value that is delivered. As the driving force behind the project your presence must be visible, vocal and objective.
Communication is a value of 'agile' and collaboration is an intrinsic behaviour that contributes to the success of agile teams. As the Onsite Customer, you must demonstrate from the outset that you are an equal team member. Respect peoples time. Do not pass on business related activities, e.g. writing user stories, to developers. The developers may assist you with this particular activity but as the business representative and the authority on what is valued by the business you should be making the business decisions and ensuring that the requirements are communicated clearly and are understood. Some of the most valuable information is carried in simple conversations that occur all the time in the War Room. You can pick-up these nuggets by osmosis if you are collocated with the team. Communicate the project vision to the team using clear, elevating goals (Larsen, LaFasto) so that the team is better equipped to help realise it.
You should have high expectations and demand completed and demonstrable code at the end of every iteration. Insist on high test coverage (80-100%), automated unit and acceptance tests, automated builds, continuous integration, and clear visibility of progress. Present the team with challenges that will invigorate their efforts. Don't set unachievable goals and always be prepared to listen, negotiate and compromise. Don't set impossible deadlines or expect the developers to reduce the quality of their work. Development that is rushed inevitably needs to be fixed later resulting in a more costly project.
Define clear priorities based on business value and have the team deliver the highest value user stories first. But understand and assess the risks before making judgements. Priorities are relative so if you say everything is 'top priority' you are not doing your job properly. In this situation you can expect to receive an arbitrary set of completed and incomplete user stories at the end. Insist on knowing the cost of a user story before prioritising. Have the developers estimate the user stories using a unit of magnitude such as story points (this technique provides relative estimates quickly but appreciate that there is a larger tolerance for inaccuracy given the size and potential ambiguity of the user stories at this stage). You're entitled to change your mind but be decisive and avoid making random changes. Changes will occur for many different reasons so regularly assess your priorities and reprioritise quickly.
To facilitate adaptive planning you must express the features you want as user stories so that the team can estimate them. Learn how to write user stories properly and practice evolving their details through discussions and conversations with the developers. Practice expressing those details as acceptance tests.
Provide support, encouragement and recognition to the team both through your words and actions. Use every opportunity and don't save it up until the end of the project. This will motivate the team to do their best for you as the project progresses.
Tags:
agile,
scrum
Links to this post
Here's an article on Scrum that i originally read in the FT on 27th July 2005.
There's not much substance to it but there are a few endorsements from companies using it which helps improve the overall visibility and credibility of Scrum.
Rapid results without a rugby scrumTags:
agile,
scrum
Links to this post
Do agile planning tools fit in an informative workspace?
A few people i've spoken with recently said that agile planning tools do not really fit into an Informative Workspace because the information they contain is not directly visible to passers-by. They have a point.
Just about every agile planning tool available provides a dashboard containing charts conveying progress information in terms of completed user stories, user stories being developed and those to be started, but they're not Big Visible Charts. You also have to login to the tool and navigate to the appropriate page to view the dashboard.
A simple way of making the dashboard more visible is to display the page on a plasma screen such that the dashboard becomes an information radiator (the update process is manual because someone has to refresh the page to display the latest data).
Of more value would be a dashboard page that automatically refreshed periodically.
Tags:
agile,
agile planning,
big visible chart
Links to this post
Informative workspace
Designing the layoutA team workspace layout that is conducive to social interaction facilitates the sharing of knowledge and improves the performance of the team, increasing their productivity. The workspace should be an open space large enough to accommodate the team and their equipment comfortably, and should be organised to satisfy practical, social and personal needs. The team should be encouraged to organise and maintain their own workspace so that it reflects their individual personalities and team character.
A practical area enables team members to Sit Together so that the physical proximities enhance face-to-face communication and facilitate pair programming. Team members should be able to easily talk to those sitting adjacent and to passers-by. It's important that conversations can be overheard because they often carry useful information and help provoke knowledge sharing. Team members learn to tune-out background noise when they are concentrating in such an environment.
A public area provides a communal space where team members can work as a group. The area should encourage sociability and stimulate interaction with features such as a round meeting table, white boards, flip charts and other pertinent displays. It's nice if part of the area is arranged in a 'chill-out' fashion with sofas or beanbags.
Both of these areas should be located on a route through the team workspace so that people passing through can make casual contact.
A number of private, owned spaces provide personal workspaces for concentrated, individual work. Team members should personalise their workspaces to create a home. This improves their attitude towards work.
Extreme feedback devices and information radiators
The public and practical areas of the team workspace should be about work. Kent Beck says:
"An interested observer should be able to walk into the team workspace and get a general idea of how the project is going in 15 seconds. He should be able to get more information about real or potential problems by looking more closely."An Informative Workspace centres on Big Visible Charts that communicate big picture goals, planning information such as the dates and content of releases and sprints/iterations, progress, test results and the domain model. The charts must be immediately understandable and prevent misinterpretation. The information they convey should be easily and quickly absorbed by passers-by without the need to interrupt developers. Charts can assume various guises but can be categorised generally as Information Radiators and Extreme Feedback Devices.
Information radiators typically require manual updating. A user story/task board is an information radiator. The spatial arrangement of the index cards communicates the product backlog, the sprint/iteration status in terms of completed user stories, user stories being developed and those not yet started. Coloured stickers and post-it notes can be used to provide additional information and enhance visibility. Another information radiator is a
burndown chart which is a graphical representation showing what had been done and what is still to do. (An alternative burndown chart can be seen at
Mountain Goat Software.) Whiteboards provide an effective medium for capturing short-term information such as reminders or design discussions.
Extreme feedback devices are simple, highly visible indicators which convey simple progress information in terms of passing/failing unit tests and passing/failing acceptance tests automatically derived from the continuous integration/build process. One popular device uses a pair of Lava lamps, one green and one red, connected to the build system such that a successful build with all tests passing turns on the green lava lamp, and a failed build containing failed tests turns on the red lava lamp. (See
Pragmatic Programmer for more information). An alternative device uses a plasma screen to display the build results from continuous integration using
CruiseControl.
Tags:
agile,
informative workspace,
tdd,
information radiator,
big visible chart
Links to this post
Ken Schwaber talks about
Scrum at the SDForum Agile Summit held July 21, 2004 in Palo Alto, California.
You Thought it was Easy: Wrestling Gold from Today's Software ProjectsTags:
agile,
scrum
Links to this post
The presentation was recorded at the Developer Testing Forum held in Palo Alto, California, November 17th, 2004.
Kent talks about how the developer tests produced by test-driven development directly contribute to the health of software, and how they can give a developer a sense of accountability without apportioning blame.
The health of softwareKent is interested in developing healthy and quality software emphasising that health is not the same as quality. Health is a continuous measure of the state of software while quality is an instantaneous measure of software at a point in time. Healthy software responds well to stress, e.g. making frequent refactorings and changes to the code. Having automated unit tests helps to make coding changes easier and gives developers courage and confidence to persist.
Developer accountabilityKent talks about the culture of
plausible deniability where a developer says "I think this code works" and checks it into the version control repository. In a culture without
plausible deniability, the developer is required to prove the code works as expected with developer tests (and automated FIT tests).
Accountability helps to build trust between people - team members, scrum master, customer/product owner, etc. Each developer is individually responsible for the health of the software.
Kent writes developer tests for himself because they make his world run more smoothly while developing and they enable him to think about the design of his code while he's working on it.
Developer TestingTags:
agile,
extreme programming,
tdd
Links to this post
