AGILE IN ACTION

A man's errors are his portals of discovery - James Joyce.

I've finally joined the APLN . I've been planning to join for a while but I was eventually spurned into action by the creation of a London Chapter . The primary aim of APLN is to make people great project leaders by focusing on value, customers, teams, individuals, context and uncertainty. Read about APLN and the Declaration of Interdependence for more information. Lately, I've been reading about collaboration techniques and collaborative leadership so I'm particularly interested to see what gets discussed in this forum. A few hot topics of interest to me at the moment include: Learning and developing techniques that help inculcate Agile values into team members so they become guided instinctively by the principles of Agile as they perform Extreme Programming practices. Learning and developing techniques that help customers to take ownership and responsibility that is commensurate with their role, and to engage proactively as a full-time member of the project. Finding new ways to help team members understand the empowering effect of being in a self-organising team, and within this context, to achieve their capabilities for creativity and effective teamwork while demonstrating collective responsibility. Exploring the dynamic nature of leadership as a part of collaboration in a self-organising team. Links: Collaborative Leadership Collaborative Leadership Training Tools Books:

The creation of knowledge depends on an enabling context, or ba , that is shared by people and fosters relationships among them. The knowledge created depends on the situation and the people involved. Scrum creates ba by fostering relationships and effective collaboration, and facilitating interdisciplinary activities between the scrum team , which is a self-organising and multi-disciplined organism, and the product owner representing the business. Scrum builds a social environment that connects the product owner , the scrum team and the scrum master . In the sprint planning meeting, the process of socialisation allows the product owner and scrum team to share their tacit knowledge with a mutual exchange of ideas and viewpoints. The product owner 's tacit knowledge includes subjective insights and experiential wisdom about the features they desire. Whereas, the developers' tacit knowledge includes their intuition for the product owner 's needs and their technological know-how. Based on their collaboration to explore and understand selected user stories they create new tacit knowledge. This is converted into explicit knowledge, in the form of evolving code and emerging features, by the process of externalisation which proceeds throughout the sprint. While the enablement of knowledge creation relies fundamentally on the emotional attachment of the people involved and their care for the organisation and their colleagues, it also includes the facilitation of the relationships and the conversations. The scrum master 's broad responsibility is to facilitate collaboration by encouraging active communication among the scrum team and between its members and the product owner , and by channelling the energy created by their interactions to create ba . References: [1] Hititsubashi on Knowledge Management [2] Ba [3] The courage to be creative

Ten-minute build It's worth developing an automated, reliable and reproducible build for your project that builds the system and runs all the tests. It should be run many times a day, initiated by a schedule or in response to some asynchronous event such as checking source code into the repository. You should also be able to initiate the build on demand, e.g. from the command line or from within an IDE. The build needs to be fast if it's going to run frequently. Therefore, you need to invest in continual improvement and optimisation to maintain a ten-minute build cycle. Any longer than ten minutes and the build won't be used as often and won't provide as much feedback. Continuous integration Traditional integration is a big-bang affair, highly unpredictable and typically fraught with problems. A build that runs frequently allows developers to integrate and test their changes often, perhaps every 2 to 3 hours. There's no rule of thumb here; it depends on your code and how you've broken the functionality down into chunks to be developed, but the longer you wait to integrate, the more risky and unpredictable integration becomes. By integrating often, integration is broken down into many small integrations that are performed as part of the cycle: test-code-refactor~~integrate . The integration nightmare goes away and the number of integration problems are reduced. A continuous integration tool like Cruisecontrol can be configured to start the build asynchronously, triggered by a check-in of source code to the repository. If problems are encountered during the build, which includes running all the tests, the developers are automatically notified by email, RSS, or a text message (also take a look at some alternative extreme feedback devices ). The rule here is to react immediately and fix the build. A broken build should not be tolerated. Developer rhythm A ten-minute build automated with continuous integration helps developers establish a rhythm as they develop software. This rhythm reminds developers to integrate regularly. Integration should happen at least once a day and only working tested code should be checked-in. Source code should not be checked-out for days on end, and broken code should never be checked-in. The following diagram shows the steps a developer performs in the test-code-refactor~~integrate cycle. developerrhythm Originally uploaded by sjb140470 I always do a local clean build before I commit any changes to the repository. With a ten-minute build I don't have to wait long before I know whether I can proceed with the check-in. This time gives me a chance to come up for air , grab a drink, or reflect with my pair-programming partner on the work we just completed. If you don't do a local build you'll know about any integration errors as soon as the continuous integration build runs. You can then assess the problem and decide whether a quick fix can be found or whether the changes need to be backed-out of the repository, so that the builds works once again. Continuous integration tools: Cruisecontrol , Beetlejuice , Continuum

A user story containing unknown elements should be split into a spike to investigate the unknown elements plus a story to develop the functionality. This enables the customer to prioritize the research separate from the implementation of the new functionality.

Planning in detail too far into the future can be wasteful because changes will inevitably happen and they can't be predicted. The horizon of predictability marks the point where predictability moves into uncertainty. This horizon is the duration of an iteration. It's safe to plan in detail up to the horizon, but beyond it you should plan with a decreasing level of detail and precision. Adaptive planning defines a high-level plan or roadmap that contains the user stories to be developed over a distance such as a release, and creates a detailed plan for the next iteration only. User stories are well suited to adaptive planning because they're easy to use with different levels of precision. The figure below (adapted from James Shore 's Beyond Story Cards article) illustrates this effect. userstorycone Originally uploaded by sjb140470 . Beyond the current release, user stories are typically epics that focus on broad or vague features. During release planning, the selected user stories may be split into smaller user stories that focus on narrower features. However, the purpose of release planning is to quickly establish a sense of how big a release might be. It's not necessary to split the user stories too far. You can tolerate a larger inaccuracy in their estimates because changes will occur over the period of the release. As the user stories approach the next iteration, they should be split further to focus on progressively smaller and more specific functionality. As the user stories become smaller, they become easier to estimate and their estimates will become less inaccurate. By the time the user stories are planned into the next iteration you want them to take between 1 and 2 days to complete, as a rule of thumb. During an iteration, it's difficult to start developing the software for user stories when you only know their names. Recall the conversation element of a user story. The developers and the customer need to collaborate and talk about the details of a user story at the latest responsible moment, i.e. when the details become important. Typically this collaboration to reveal the fine details of the user stories begins in the iteration planning meeting and facilitates a translation of the user stories into acceptance tests. As part of the collaboration, it's important that the developers understand the benefits of, and the motivation for each user story. Rachel Davies suggests that the developers use a simple checklist: Do we understand the value to the business that this user story provides? Do we know who the beneficiary of the user story is? Have we defined all the acceptance tests? Next post in this series: User stories part 3: Using spikes to help estimate user stories Previous posts in this series: User stories part 1: What is a user story and who writes them? References: [1] Mike Cohn 's Agile Estimating and Planning [2] Kent Beck and Martin Fowler 's Planning Extreme Programming

What's a user story? A user story is a distinct unit of customer-visible functionality, which does not have to represent value to the business but must represent progress to the customer. It's meaningful to both the customer and the developers. Ron Jeffries uses 3 Cs to describe a user story: 1. Card: The name of the user story (no more than a word or two) used to facilitate collaboration between the customer and the developers. 2. Conversation: Collaboration and discussions that drill-down into the details of the desired functionality. 3. Confirmation: Acceptance tests capturing the details and used to determine when a user story is complete. Think of user stories as representing a collaboration between the customer and the developers, as opposed to documenting customer requirements. The purpose of this collaboration is to reveal and understand the details of the user stories, which are recorded in the confirmation. Some people write a short description of the user story on the index card, while others like a statement of the format: [Role] can [capability], so that [benefit] . I prefer Rachel Davies' suggestion, and put just the name of the user story on the index card. A verbose story card encourages people to think of them as requirements documents. A simple name, written in large capital letters, encourages collaboration that continues throughout the iteration William Wake advises us to INVEST in good user stories : 1. I ndependent: Dependencies between user stories should be avoided because they can lead to prioritisation and planning difficulties. 2. N egotiable: User stories are reminders to collaborate. Collaboration between the customer and the developers involves a negotiation to balance the desired functionality with the cost of implementing it. 3. V aluable to the customer: Whether a user story represents value to the business or simply conveys progress it must inherently be valuable to the customer. This enables the customer to intelligently prioritise user stories. Avoid user stories that have only technical value. 4. E stimatable: There are three reasons why user stories may not be estimatable: Developers lack domain knowledge. In this situation, collaborating with the customer will help them understand a user story. Developers do not possess the right technical knowledge. They should split the user story into a spike to gather information, and a user story to do the real work. A spike is an experiment that allows the developers to learn just enough about the technology to be able to estimate the user story. A spike must be time-boxed. This defines the maximum time that will be spent learning and fixes the estimate for the spike. A user story is too big. It should be split into smaller user stories during collaboration between the customer and developers. When development starts on a user story, it should take between one and two days to complete (including acceptance tests). 5. S mall: If user stories are too big they are difficult to estimate and cannot be planned into a single iteration. 6. T estable: User stories must be testable. A user story that passes all its acceptance tests (and all its unit tests) can be considered complete (subject to a final visual approval by the customer). Without this capability, developers will not know when they're done . Who writes the user stories? The customer writes the user stories because she's in the best position to know the desired functionality. Each user story must be written in the language of the business. This enables the customer to prioritise the user stories according to their value to the business and their cost, and select the user stories for each iteration. The developers can assist the customer but the responsibility for writing stories must reside with the customer. Next post in this series: User stories 2: Adaptive planning References: [1] Mike Cohn 's User Stories Applied For Agile Software Development [2] Kent Beck 's Extreme Programming Explained, Second Edition

Roughly translated, Ba means place . Ba is a time and space where creative energy flows, existing knowledge is shared and new knowledge is created. Through their interactions with one another and the environment, people become attuned to the context of ba and they're able to look beyond their own limited perspective. They view problems as opportunities to learn, and they're inspired to be creative and to develop innovative solutions. Here's an extract from one of the case studies in Hititsubashi on Knowledge Management :

You can probably tell from some of my recent posts that I've been thinking about how I plan and estimate with user stories, how I use tasks, and how I track progress. While I was reviewing some of my experiences and working through my ideas, I exchanged a few emails with James Shore who gave me permission to adapt one of his diagrams. You'll see this adapted diagram in a mini-series describing my approach, which I intend to post over the coming days.

To deliver working increments of software, it's not enough to show all the tests passing. You also want to know that each user story has a production-quality implementation. This is why knowing when you're done on a user story includes a mental check of the design and all the code. Some teams at Thoughtworks use a single information radiator to convey both the functional completeness of a user story and its implementation quality. Using both dimensions of a whiteboard, the x-axis represents the functional completeness and the y-axis represents the implementation quality. The story cards being developed in an iteration are placed on the whiteboard. A card is moved to the right as it becomes more functionally complete, and moved upwards as its implementation quality improves. I plan to reconfigure the Current Iteration area of my planning board to be like this. Reference: Alistair Cockburn on Communicating, Cooperating Teams .