Don't be afraid to make mistakes
A man's errors are his portals of discovery - James Joyce.
We learn by trial and error. When you fail, you learn what doesn't work and you get an opportunity to try a new approach. Go on a journey of discovery and use the negative feedback as a stepping stone that leads to new thinking and new ideas. How else will you find
improvement?
Related posts:
The courage to be creativeThe knowledge worker and the new organisation
Links to this post
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 LeadershipCollaborative Leadership Training ToolsBooks:
Tags:
apln,
leadership,
collaborative leadership
Links to this post
Scrum ba
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 creativeTags:
knowledge management,
toyota way,
lean,
scrum
Links to this post
User stories part 3: Using spikes to help estimate user stories
A user story containing unknown elements should be split into a
spike to investigate the unknown elements plus a user story to develop the functionality. This enables the customer to prioritise the research separate from the implementation of the new functionality. Without a
spike to substantiate the estimate for the user story, the customer may incorrectly assume the estimate to be valid and prioritise the user story accordingly. Facing a
spike and an associated user story, the customer should prioritise the
spike ahead of the user story to obtain a more reliable estimate for prioritising the user story.
Next post in this series:
User stories part 4: Collaborating to write acceptance tests
Previous posts in this series:
User stories part 1: What is a user story and who writes them?User stories part 2: Adaptive planningReferences:
[1]
Mike Cohn's
Agile Estimating and PlanningTags:
agile,
extreme programming,
user stories,
spike
Links to this post
Ten-minute build, continuous integration and developer rhythm
Ten-minute buildIt'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 integrationTraditional 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 rhythmA
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 sjb140470I 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,
ContinuumTags:
agile,
extreme programming,
tdd,
continuous integration,
ten-minute build
Links to this post
User stories part 2: Adaptive planning
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 storiesPrevious 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 ProgrammingTags:
agile,
extreme programming,
user stories,
adaptive planning
Links to this post
User stories part 1: What is a user story and who writes them?
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.
Independent: Dependencies between user stories should be avoided because they can lead to prioritisation and planning difficulties.
2.
Negotiable: 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.
Valuable 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.
Estimatable: 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.
Small: If user stories are too big they are difficult to estimate and cannot be planned into a single iteration.
6.
Testable: 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
Tags:
agile,
extreme programming,
user stories
Links to this post
Ba
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:
Seven-Eleven Japan uses the shop floors of its stores as ba to create knowledge, where store employees accumulate tacit knowledge abut customers' needs through face-to-face interactions. Long-term experiences in dealing with customers give store employees unique knowledge and insight into the local market and their customers. They often say that they can just 'see' or 'feel' how well certain items will sell in their stores, although they cannot explain why. Seven-Eleven Japan emphasises the importance of its stores as ba to keep creating knowledge in order to adapt to ever-chaing customers needs.
Ba happens spontaneously, but it's possible to supply the necessary conditions that allow
ba to occur naturally: Autonomy,
self-organisation, creative chaos, and diversity. An
informative workspace provides a physical space that facilitates collaboration and encourages interaction between people. While a mental space transpires from the reciprocating trust and commitment felt among the people present, and from their common values and goals.
References:
[1]
Hititsubashi on Knowledge Management[2]
The courage to be creativeTags:
knowledge management,
toyota way,
lean
Links to this post
Watch out for the mini-series
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.
Links to this post
Ideal time vs. story points
When I first started using
Extreme Programming I estimated user stories in
ideal time. Later, when
velocity replaced
load factor, I switched to
story points.
A story point is a measure of magnitude. It's also a measure of the size of a user story relative to other user stories.
Story points enable effort to be estimated without trying to estimate how long it will take. To derive an estimate for the duration of a project you divide the
story points for all the user stories by the
velocity of the development team (given by the number of
story points completed in the last iteration). User stories can be estimated quickly using triangulation, e.g. I'm giving this story 2 points because it feels like it's twice as big as that 1-point story and about half as big as that 4-point story.
I like the concept of
story points, but I've seen development teams get confused by them and I've never met a customer who liked them. Why? Quite a few developers said something like:
I get the idea but estimating with them doesn't feel natural. It's true that their abstract nature takes a little getting used to.
For developers, the real confusion starts when a user story's tasks are estimated in
ideal time. After a while, developers think they see a correlation between
story points and time. They think, for example, that 1 story point = 4 ideal hours. An equivalence such as this isn't valid because a story point value actually corresponds to a distribution of time. A 1-point user story may take 4 ideal hours to complete, but it's also possible that another 1-point user story will take less, or indeed more than 4 ideal hours. To counter this variation in time and preserve equivalence, developers start to estimate in
ideal time first and then convert to
story points. When this happens the purpose of using
story points is lost. Paraphrasing
James Shore, the net effect is
increased confusion about how to estimate, and a corresponding decline in the team's confidence and commitment to their iteration plans.
Story points are equally unnatural for the customer, who's more used to getting estimates in time. I've often seen developers remind the customer that estimates are in
story points and not time, to which the customer responds,
Well what is it in time? This frustrates everyone and collaboration suffers because of it. The customer doesn't have an intimate relationship with the estimates like the developers do, so the estimates need to be easily understood. If the customer isn't comfortable with
story points, he may not trust the estimates and that isn't good. The customer needs to trust the estimates because they reflect the cost of user stories, and he measures this against their value to the business in order to prioritise.
I was interested to read that
Chris Wheeler had experienced
similar difficulties using
story points, and
James Shore reverted to using
pair-hours because he realised that
making estimating units more abstract made estimating and planning more confusing and difficult. Kent Beck also reverted to using time-based estimates in the
second edition of Extreme Programming Edition Explained. Is this a trend? I'm not sure, but I'm switching back to
ideal time too. I want to see whether the difficulties I encountered using
story points go away. And I want to see what new difficulties emerge with
ideal time.
Reference:
Mike Cohn's Agile Estimating and PlanningTags:
agile,
extreme programming,
user stories
Links to this post
Making the quality-factor visible
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.
Tags:
agile,
extreme programming,
information radiator,
big visible chart
Links to this post
User stories and tasks
The process of breaking down a user story is important because it helps me think about how I'm going to build the functionality. Many people disaggregate a user story into tasks and then estimate them (usually in
ideal time) because they're smaller units of work and can be estimated with less inaccuracy. Then they total the task estimates to obtain a better indication of how long it will take to complete the user story. Tracking each task's remaining time feels like micro-management, so I don't it anymore. I'm only interested in tracking the number of
running tested features. I want to know how many user stories are passing all their
FIT tests.
When I start developing a user story, I like to break it down into
vertical slices of functionality that I note on the back of the story card. I try to define these slices in such a way that I can build them one after the other (refactoring in-between so they fit together with the latest extending its predecessor). It's similar to erecting a fence. This approach allows the customer to see and play with the evolving functionality and to provide feedback, which I take into the next vertical slice.
As I work on a slice of functionality using
test-driven development, any tasks identified are written down as notes on a piece of paper or an index card. This task-list is just an evolving to-do list for the slice. As a simple memory aid used in conjunction with
test-driven development, it guides the way and reminds me of what I need to do. These tasks are very granular and because they're noted just-in-time they're not situated very far away, perhaps only minutes or tens-of-minutes away. Consequently, it doesn't matter where I write them because they'll be crossed-off soon enough when they're completed.
It doesn't make sense to track the time remaining to complete one of these tasks because it's too small. Tracking
running tested features focuses attention on the development team (and the user stories that they've committed to delivering) rather than on individual team members. Focusing on the team as a whole helps them to recognise their collective accountability and to develop their collective responsibility. This helps a team to become self-organising.
Tags:
agile,
extreme programming,
user stories
Links to this post
Knowing when you're done
Don't move onto the next user story before you know that the user story you've been working on is done. How do you know when a user story is done? I use the following check list:
- The code compiles.
- All the automated unit tests are passing and test coverage is between 85% and 100%. (Be guided by the need to provide tests for everything that could possibly break)
- The code has a simple design that uses the fewest classes and methods.
- The code is well factored and without duplication.
- The code is clean and structured to coding standards.
- The code is self-documenting and clearly communicates my intentions a the developer.
- The code is checked-in, integrated (and builds successfully).
- All the acceptance tests (automated with FIT) are passing.
- The customer has verified that the acceptance criteria have been satisfied. I don't wait for the end-of-iteration review. I like to get this approval as soon as possible after I've checked-off the items above.
You can take out some
technical debt on 3 and 4 if the situation absolutely requires it, but you should ensure that it's repaid quickly. Don't let your
technical debt build up. The interest repayments can be a killer.
Tags:
agile,
extreme programming
Links to this post
Switching pair-programming partners
How often should you switch
pair-programming partners?
Regularly switching partners supports the
collective ownership of
shared code and helps propagate knowledge and understanding throughout the team. However, switching doesn't come for free. Each time you switch partners, the
flow is broken and it takes about 15 minutes to enter that
flow again, plus any familiarisation time to bring your new partner up to speed with the current development thread.
I've seen two other factors come into play. The developers' level of experience and their level of familiarity with all the user stories planned in the iteration. If iteration planning is a team effort, which it should be, then the second factor is just about getting updated on the latest coding on a user story. With less experienced developers, it may take longer to re-enter
flow because they require more time to get up to speed on the new user story. However, having less experienced developers switch often can be an effective learning experience providing the wasted time re-entering
flow can be afforded. As a rule, less experienced developers should be paired with more experienced developers.
Here are 3 strategies that I've used for switching
pair-programming partners, in order of preference:
- Switch partners at recurring, natural breaks in the day (and not necessarily when developers come up for air). The flow will be broken at these times anyway. User story owners select new partners immediately following the stand-up meeting in the morning and first thing after lunch.
- Switch partners every 2 hours, but realise that in an 8-hour day approximately 1 hour per pair is wasted on re-entering flow following each switch.
- Over time, I like to progressively split user stories so by the time they are planned into an iteration they take between 1 and 2 days to complete. Given a smaller user story, it's feasible for a pair to stay together for the duration of its development. In this scenario, the familiarity with the details of the user story, which comes about through working on the user story, is not shared beyond the owning pair. However, the other team members should at least be familiar with the desired functionality in the user story from the iteration planning meeting. And through the stand-up meetings and osmotic communication they should also be aware of changes that emerged from collaboration with the customer during development. Providing the code has a simple design, is well factored, communicative and self-documenting, has a high unit-test coverage and comes with a comprehensive set of acceptance tests (see FIT), pairing until the user story is complete has a negligible impact on the team's collective ownership.
Tags:
agile,
extreme programming,
pair programming
Links to this post
