Look after your product backlog
Stacia Heimgartner provides a useful
Product Owner's guide to the Product Backlog. Here's what I think are the key points:
- As the Product Owner you're responsible for the features that get delivered. Own the Product Backlog. Plan one iteration ahead of the developers.
- Product Backlog items should be high-level. Like user stories (in fact I actually use user stories as product backlog items), backlog items serve as reminders to collaborate continuously with the development team to progressively discuss details and to capture them as acceptance tests. I'll talk some more on adaptive planning, collaborating and making decisions at the latest responsible moment in a future post.
- Learn to prioritise effectively so that you get the biggest bang for your buck. Identify what is valuable to your company and find out the cost of each backlog item by getting provisional estimates from the development team. Then prioritise.
- The Product Backlog is a dynamic entity so manage it constantly. As new information becomes available through collaboartion, inspect and adapt the Product Backlog. Keep the Product Backlog publicly visible, at all times.
Other posts for the Product Owner:
Being an effective onsite customer or product ownerTags:
agile,
scrum
Links to this post
1-week iterations
I like 1-week iterations because they focus the mind and the effort. They're not for the faint hearted, however. They do have a downside, as
Mishkin Berteig points out in his post about
The Pros and Cons of Short Iterations. Here's some advice on how to avoid or at least minimise the affect of the cons:
1. Intensity of work can lead to burnoutUse the
Extreme Programming practice of
energized work. Work only for those hours where you are genuinely productive. Manage the time you spend at work carefully and protect your
flow time. When programming,
come up for air regularly. Take breaks often to refresh your brain and your senses. Work as many hours as you can sustain without a detrimental affect on the quality of your work, your health, and of course your personal life outside work. Burning yourself out today and spoiling the next two days of work isn't good for you or the team. It's important to retain a sensible perspective and find the right balance between work and play.
2. Strategic thinking can be hard to fit into the scheduleStrategic thinking can occur at many levels. The challenge is to do just enough strategic thinking from one opportunity for inspection and adaptation to the next.
If there must be regular strategy meetings with other stakeholders then the team's velocity should accommodate these. I prefer to avoid these meetings if at all possible. Instead strategic thinking should be part of the normal routine. I like doing monthly releases (even if they don't go into production) because they provide a release planning meeting every 4 weeks. This is an ideal forum in which to review the strategic roadmap and adjust it if necessary. When there's some strategic thinking to be done that's pertinent to an iteration, it can either occur during the iteration planning meeting, if it has possible consequences for the planning, or it can be done around a whiteboard following the iteration planning meeting. If someone deems a strategic issue to be worth discussing, any developer, or the customer, is free to start a whiteboard session at any time.
When coding you don't want to look too far into the future because, maybe,
YAGNI. You should rely on the developers abilities to refactor to evolve a suitable architecture and accommodate change.
Pair programming enables the person not driving the keyboard to think strategically about the coding goal - Can this method be avoided? What are the implications of this approach? Are there simpler approaches? We'll need to refactor so-and-so too - while the person typing is concerned with tactical issues writing the code.
3. Overhead tasks that must be done every iteration take a larger proportion of the time in the iterationThe durations of the iteration planning meeting, review and retrospective should be proportional to the iteration's duration, so they should consume no additional time. Overhead tasks, e.g. extra processes, task switching, waiting around, any motion such as chasing the customer, should be considered waste and should be eliminated.
Any other overhead tasks should be minimised. Invest in
continuous integration and a
10-minute build. In my last project, we continually optimised our automated build process. In one iteration we refactored the build to use
Maven 2 so that we could use profiles on the command line. These allowed us to deploy easily to different server environments. We also configured
Cruisecontrol with new projects, one for each server environment.These projects were programmed to fire at certain times, e.g. an overnight build would be automatically deployed onto the DEV environment, and at a certain hour every Friday (i.e. at the end of the iteration) the checked-in code would be automatically deployed to the UAT environment.
4. Waiting for resources or people outside of the team can make it more likely for work to span iterationsThe customer should be collocated with the development team. If other stakeholders are heavily involved, collocate them too. Beyond this, it comes down to aligning resources, coordinating efforts, and managing the risks of external dependencies.
Plan with appropriate buffering when you have an external dependency. If the external party is delivering code, and they're not doing
iterative and incremental development, you want to initiate their work so that delivery correlates with your release plan. When I deal with external dependencies I make a point of over-communicating. I set time-boxes for everything and insist that the external party does the same. I treat them as I would an opponent in tennis - I keep the ball in their court at all times. Everytime they ask a question or provide something, I get the answer to them or give feedback as quickly as possible. The worst thing you can do is keep an external party waiting.
As stated previously, waiting around or chasing around is a waste and should be eliminated. Ask yourself: Can you bring the code in-house and remove that external dependency? Are you empowered to make decisions on behalf of that absent or difficult to get hold of stakeholder?
Tags:
agile,
extreme programming,
iterative development
Links to this post
My brother is a
SixSigma consultant and my nephew is at that age where he asks "Why?" a lot. I'm wondering whether he's been trained by his father to use
SixSigma's root cause analysis technique, the 5 Why's?
The technique is simple. Write a description of the failure on a whiteboard. This helps formalise the failure and also helps the team involved to focus. Ask the team, 5 times, why the failure occurred, each time writing the answer given on the whiteboard. Repeatedly asking the question helps to burrow through the symptoms and identify a root cause of a problem (there may be more than one root cause). 5 is a rule of thumb. You may ask the question fewer or more times than 5 before you find the root cause of the failure.
5 Why's applied in a real retrospective
In a previous post, I talked about the experiences a development team were having in relation to
slop and slack. One particular problem was that planned user stories were being descoped from each iteration as the last day approached. Here's the analysis:
Failure: Consistently fail to deliver all the user stories to the Product Owner, that are planned during the iteration planning meeting.
- Why are user stories being descoped towards the end of each iteration and not being delivered to the Product Owner? Because we run out of time.
- Why do you run out of time? Because most of the user stories take longer than we estimated.
- Why do most of the user stories take longer than your estimates? Because most of our estimates are bad.
- Why are most of your estimates bad? Because we don't fully understand enough of the details of a user story when we estimate. And although we triangulate to completed user stories, the task effort recorded for those completed stories differs significantly even though they have the same story points. (The tracking data showed that user stories with 5 story points had tasks with a total recorded effort between 2 and 4 ideal days). [2 problems identified here]
- Why don't you fully understand enough of the details of a user story? Because we're not collaborating effectively with the customer during iteration planning.
- Why aren't you collaborating effectively with the customer during iteration planning? Because most of the story cards are a mess of notes, so we get the customer to read them to us. [Root cause identified]
- Why is the tolerance on recorded effort so wide for user stories with the same story point value? Because we're not revising the story point estimates.
- Why aren't you revising story point estimates? Because we focus on tracking the tasks in ideal days. [Another root cause identified]
To address the 2 root causes, the following fixes were applied in the next iteration:
- Encourage collaboration by using just a story name on the card (a technique suggested to Brian Marick by Rachel Davies). The customer rewrote the remaining story cards.
- At the end of the iteration planning meeting, each team member verbally state their commitment to deliver the planned user stories to the product owner and the other team members. This made the developers spend sufficient time with the customer, beforehand, discussing the details of the user stories to ensure they understood what was required before providing estimates.
- Start using ideal pair hours to estimate user stories and record velocity rather than story points. It seemed nobody really liked story points. Since there was some confusion about what they really were or meant, the developers were never entirely confident about their estimates. The customer was happy to see time come back, although the concept of ideal time had to be explained.
- Stop tracking tasks and start tracking running tests features.
- As part of the collaboration between the customer and the developers, split the user stories being planned for the iteration so that they would take between 1and 2 days to complete. Smaller units of work are easier to estimate.
It's been a while since these fixes were applied. They made a difference almost immediately with fewer user stories being descoped from iterations. Collaboration is increasingly more effective. There's still room to improve the estimates, but the developers' confidence has increased and now it's a case of practice, practice, practice.
FIT has been used but only to produce automated acceptance tests. The next step will be to start using
FIT to actually facilitate the collaboration with the customer. The aim is to produce the
FIT documents before development starts on the user stories.
Tags:
knowledge management,
toyota way,
lean,
root cause analysis
Links to this post
This blog is now published at the
Artima Agile Buzz. All I had to do was modify my
FeedBurner feed to RSS2.0.
Links to this post
Planning with the Horizon of Predictability
Planning is everything. Plans are nothing. - Field Marshall Helmuth Graf von Moltke
The further you plan into the future the less predictable things become. Change will inevitably happen and the 'where', 'when', and 'how' cannot be anticipated. There's a point where predictability moves into uncertainty. This is called the Horizon of Predictability. You can see clearly up to this horizon but not beyond it.
Therefore, you can plan in detail up to the horizon and expect things to remain reasonably stable. But when you move beyond the horizon you should plan with a decreasing level of detail and precision as things become less certain and more unpredictable. As time progresses the horizon shifts into the future by the same amount. Previously uncertain things move into the predictable zone as new information comes into focus and is understood. Because the planning landscape changes over time, you need to look out to the horizon frequently, assess what is known and what is not known, and adjust your plans accordingly.
horizonofpredictability
Originally uploaded by sjb140470.When you plan a release you are determining how many user stories can be completed in the allotted timeframe. The release plan looks the furthest out and uses the least detail and precision. Consequently, it should be reviewed and updated at the start of each iteration to ensure that it continues to reflect what is believed to be the achievable target content for the release.
Iteration planning doesn't look beyond the horizon. It focuses on the user stories selected for the next iteration only. This is planning close-up, where things are predictable. The iteration plan is more detailed than the release plan and disaggregates the selected user stories into the engineering tasks needed to produce
running tested features. At the start of each iteration, it's worthwhile re-assessing the release plan, based on information revealed during the last iteration, to see if it needs to be adjusted.
On a daily basis there is a Stand-up or Scrum meeting where the development team gets together to coordinate their work for the day and synchronise their efforts. This provides a regular opportunity to assess progress against the iteration plan and make any necessary adjustments.
Setting goals that define a themeIt helps to set goals for releases and iterations that define a theme. Goals are more ambiguous than plans, which make them more resilient to change, keeping them stable and relevant over time. In Scrum, a Sprint Goal is defined at the start of a Sprint. Setting a Sprint Goal allows the Scrum Team to react to change within a Sprint by adjusting the planned work such that the Sprint Goal can still be achieved. This enables the team to still deliver the value desired by the Product Owner.
Where is your Horizon of Predictability?It depends entirely on the volatility of your environment. How long can your customer last before he starts requesting that you do work not planned in the current iteration? How often do business priorities change? Do you need to be able to turn on a penny? In my experience, the Horizon of Predictability is seldom greater than one month. If it is, maybe your customer has forgotten about you and isn't interested in the project anymore.
Be aware of your Horizon of Predictability when setting your iteration length. You don't want to set your iteration length further out than your Horizon of Predictability. If you do, you're iteration plan is going to be unstable and the detailed planning you perform may be wasted.
Further reading:
1.
Mike Cohn's
Agile Estimating and Planning.
2.
Mishkin Berteig's
What to do with the Horizon of Predictability and
Change is constant.
Tags:
agile,
adaptive planning
Links to this post
The knowledge worker and the new organisation
This week's edition (21st January 2006) of
The Economist includes a supplement about
The New Organisation.
Fifty years ago William H. Whyte, an editor with Fortune Magazine, defined corporate life as one of conformity. He described
The Organization Man as leading a submissive existence having taken the vows of organisation life.
Organization Man lived in a structured, hierarchical world where lines authority was clearly defined and decisions were made above him. This environment suppressed individualism and self-motivation, and removed any need to take risks. The New York Times praised Whyte for
recognising that the entrepreneurial scramble to success has been largely replaced by the organisational crawl.
Today,
Organization Man has evolved into
Networked Person, a knowledge worker who thinks for a living, takes decisions all the time, is highly mobile and in constant communication with co-workers.
Tim Hindle of
The Economist says
the way people work has changed dramatically, but the way their companies are organised lags far behind. Current thinking sees innovation and growth depending on knowledge workers. Organisations therefore need to be restructured to accommodate and empower knowledge workers so that their creativity thrives.
The Toyota Way
Toyota's employees are self-motivating knowledge workers who think creatively about improving their particular area of the organisation. They are largely self-directing and their decision-making is guided by values inculcated from the organisation's culture. The supplement identifies the following Toyota values:
- Kaizen or continuous improvement. More a frame of mind than a process. Each day employees are determined to improve how they work.
- Genchi genbutsu. Go to the source, e.g. the factory floor, and deal with only the facts.
- Challenge. Employees are encouraged to see problems as opportunities for learning and improvement.
- Teamwork. Share knowledge and put the company's interests before those of the individual.
- Respect people, their skills, and their knowledge.
Toyota's just-in-time production decentralises decision-making and empowers the workers on the factory floor. They're responsible for the flow of supplies because they have the necessary information at their fingertips to maintain stocks at their lowest level, thereby minimising waste. Philip Evans and Bob Wolf of the Boston Consulting Group say,
leading is not treated as a discipline distinct from doing. Rather, the authority of leaders derives from their proficiency as practitioners.
The new organisation
The command-and-control style of management and
The Organization Man are becoming extinct. The new organisation empowers self-directing, self-controlling knowledge workers giving them the freedom to innovate, experiment, learn and improve, in order to attain the organisational objectives to which they're committed.
Tags:
knowledge worker
Links to this post
Setting Norms to help internalise Agile values
It takes time and plenty of coaching to instil Agile values in someone, and help them develop Agile principles into an intuition to
do the right thing. Also, there are many fuzzy, unpredictable, everyday situations beyond the scope of Agile principles and practices, which are governed by people factors such as mood, demeanour, intention, and motive, to name but a few. In these situations one should be guided by the Agile values to derive an appropriate course of action. Without experience, this can be difficult to do.
For a team that is new to Agile, I really like the idea of having them set some
Norms to be applied during the project. Conducted as a workshop at the start of a project, setting the
Norms can help novices translate abstract values into concrete behaviours, without guiding principles. And, as a team exercise that results in consensus, the team can begin to bind around some simple, basic ground rules. Applying the
Norms (or concrete behaviours) can help people to internalise the more abstract values. It's a good idea to keep the
Norms big and
visible, to serve as reminders, by posting them publicly around the workspace.
I reproduced the original list of
Norms referenced by
David Anderson in his blog post,
Where did the 40 hour week go?:
- Have fun!
- Honor time limits
- One speaks; all listen. Listen to understand
- Everyone participates; no one dominates
- It's okay to disagree
- Anyone can call a timeout
- Reaching consensus means that you're okay with a decision. It doesn't mean that you like it. It does mean that you agree not to talk down about it or quit over it.
I discussed these
Norms with a few colleagues and we liked them a lot. Here's a few additional norms we came up with:
- Be honest
- Learn from mistakes
- Take ownership and be responsible
- Commit publicly
I'll run a workshop with the next team I coach to see what
Norms they come up with.
Tags:
agile,
agile values,
agile coaching
Links to this post
Agile is ... Agile isn't ...
I am currently working on a short presentation which aims to communicate the justifications for and the benefits of employing Agile methods. The target audience is management, specifically the decision-makers, and includes those business people affected by the delivery of software and those people responsible for the development and delivery of software.
I want to conclude the presentation with the clear message that moving to Agile methods is not about following a prescriptive procedure of adoption (like you see with traditional methodologies such as RUP), nor is it about implementing a process, and it doesn't just involve techies.
Reginald Braithwaite-Lee provides some excellent material in his post,
Agile is an attitude, not a product. I have distilled the key points below:
- Agile methods are not a product that can be purchased as an off-the-shelf solution and installed by techies.
- Agile methods are about people whose attitude, or perspective on all things, is founded on open and honest communication, collaboration, empowerment, trust and respect.
- Agile methods are about living by a common set of values, being guided by a common set of principles, and interacting in a highly social environment.
- Choosing to employ Agile methods is the start of an extensive change process - Bob Schatz, Primavera. Employing Agile methods is a commitment to an effort, which weaves the values and principles into the cultural fabric of an organisation, and involves everyone in that organisation, from top to toe.
Obviously, I need to condense this text for the presentation, but nevertheless, I dig it! OK, maybe it gets a little fluffy but the message is a powerful one, IMHO. The question is: Will the audience get it? And that depends on how I deliver it.
Comments are always welcome.
Tags:
agile
Links to this post
It doesn't have to be about business value
Recently,
Mike Roberts said
If it really was all about business value my life would be so much easier. I've consulted in organisations that had no idea what business value was, let alone care about it. So I can empathise with the situations
Mike Roberts describes having failed, in early consulting engagements, to introduce the concept of business value to project stakeholders in order to facilitate the adoption of agile methods.
It struck me at that time, that it doesn't have to be about business value. I realised that just because an organisation isn't yet practicing agile methods doesn't mean that they won't already know what is valuable to their business. What's important is to understand exactly what the organisation does value and use that (rather than business value) to drive agile projects.
Update:
William Caputo responds to
Mike Roberts post and talks about
Aligning values. He says that it's important to understand what a customer values and to align the development effort with the customer's desires, and not the other way round.
Tags:
agile
Links to this post
Task-switching is waste
I've worked with a few companies where it was common practice for developers to work on more than one project concurrently. Guess what, parallel software development doesn't deliver projects more quickly, even if they're small projects. Task switching from one project to another incurs a cost in the form of a time penalty and impacts productivity. When there are a number of projects to complete using the same resources, they'll be delivered more quickly and usually with better quality if they're developed sequentially.
In
Lean software development task-switching is waste. Every time a developer switches between tasks, about 15 minutes is required to enter the
flow of the new task. When frequently interrupted, frustration kicks and more time is required to calm down and become settled once again. If a developer is working in a group or
pair programming there's a productivity boost due to binding and working on a common goal. This is lost when one of the developer's switches tasks. In his book
Slack,
Tom DeMarco defines the penalty of task switching as:
Task-switching penalty = Mechanics of moving to a new task + Rework due to an inopportune abort + Time to enter flow + Time to defuse frustration + Loss of group binding effectTask switching increases busyness but most of it is thrashing, non-productive and ineffective work.
Tags:
agile,
lean
Links to this post
Flow, ideal time and the E-factor
In their book
Peopleware: Productive Projects and Teams,
Tom DeMarco and
Tim Lister describe
flow as a highly productive state of concentration. It takes around 15 minutes of concentration to enter
flow and during this time you're not really doing work. Each time you're interrupted your
flow is broken and it'll take another 15 minutes to re-enter it. A metaphor here would be having to shift down the gears to negotiate the obstacle or interruption, and then having to gradually change up again until you reach cruising speed and enter
flow.
Clearly what matters is the amount of time spent in
flow and not the amount of time you're present. Flow-time is
ideal time, which was introduced as a unit of estimation in
Extreme Programming and was defined as the time where you can concentrate, working on a task without interruption, and be fully productive.
When recording effort, instead of logging elapsed time (which includes everyday overheads such as meetings, phone calls, responding to emails, task switching, etc), developers should log the
ideal time spent working on a task. When tracking
ideal time, developers become acutely aware of the time they spend in
flow, the level of interruption they are subjected to and its effect on their productivity. Based on their empirical tracking data, they should expect a certain amount of
ideal time each day and they should protect it.
The ratio of
ideal time to elapsed time is known as the Environmental factor or
E-factor:
E-factor = Ideal time / Elapsed time
Where
ideal time and elapsed time are both measured in the same unit, either days or hours.
When the
ideal time is a reasonably high proportion of the elapsed time, the environment can be considered conducive to developing software because it allows developers to get into the
flow when they need to. Here's a graph showing our
E-factor over the last 8 sprints.
E-factor
Originally uploaded by sjb140470.Compared to previous development environments that I've worked in, I consider our
E-factor to be blissfully high. The reason for this is simple: We are a contracted development team working at the client's site to deliver a specific project. Given the importance of the project to the client, we've worked effectively with their
Product Owner but otherwise they've trusted us and left us alone to get on with it.
Tags:
agile
Links to this post
A Scrum Master is like a music conductor
A
Scrum Master is like ...
...
a conductor coordinating the efforts of musicians, helping them to play together. Some teams are like jazz bands, so they need a leader who encourages improvisation. Some teams are like symphony orchestras, so they need a leader who keeps everyone on the same sheet of music. Conductors have to be deeply familiar with each instrument and with the music, yet they don't play in the band or tell the musicians what to do. They let the music provide detailed guidance; their job is to bring out the best in the musicians, both individually and as a group.Adapted from
Mary Poppendieck's
Lean Development.
Tags:
agile,
scrum
Links to this post
Slack != Waste
Slack isn't waste, it's spare capacity or buffering. Shit happens, so having
room to react, maneuver and adapt when something unexpected occurs can help protect deadlines (to a degree) and avoid potential catastophes.
Tom DeMarco refers to this
room as
Slack.
Kent Beck has added a practice called slack to
Extreme Programming Edition 2 that advocates including some minor tasks in each iteration, which can be de-scoped if the team falls behind. I've also used slack as a feature buffer comprising low priority user stories.
In
Lean Development waste is typically any of the following:
- Partially done work
- Extra processes
- Extra features
- Task switching
- Waiting
- Motion
- Defects
The practice of slack reduces waste because it helps to avoid partially done user stories. Partially done user stories are waste because they have no business value precisely because they are incomplete.
Tags:
agile,
extreme programming,
slack,
lean
Links to this post
Spike
A
spike is an experiment that allows developers to learn just enough about something unknown in a user story, e.g. a new technology, to be able to estimate that 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.
William McKnight of 3M once said "Give it a try - and quick". Apply this advice when using a
spike.
Tags:
agile,
extreme programming,
spike
Links to this post
Go on. You know you want to. Say 'Hello'
Since I started blogging I've been fortunate enough to acquire a number regular readers. I want to offer you all my thanks for coming to my blog and reading the
blurb that I write.
Next time you're here, say "Hello" by adding a comment to this post. I'd like to know more about you so please feel free to tell me a little about yourself. I'm very interested to know my peers who share the same agile interests as me. And you never know, maybe we'll meet at one of the many agile events and conferences that happen around the world each year.
Thanks.
Links to this post
I said this today:
80% of the business value is typically delivered by 20% of the features.
I was speaking with someone who was trying to convince me that all 267 features identified and specified by the business analyst were absolute must-haves for the product to be attractive to end users.
I guess he'd never heard of the
Pareto Principle more commonly known as the
80-20 Rule.
Links to this post
Why agile principles are important
The principles of agile methods such as
Extreme Programming and
Lean Development are simple rules that govern behaviour. They guide practices and facilitate decision-making at the 'coal-face' rather than restricting it to the management echelons of an organisation by providing a framework that enables experienced agile developers to make intuitive decisions quickly without having to wait for instructions or permission.
An experienced agile software development team is a highly social group that is
self-organising around these principles and acts with coordination and collective behaviour. This collective behaviour comprises:
- Collective mind [1] where individual team members develop shared understandings of the team's tasks and of one another, and come to understand how their work contributes to the work of the team thereby facilitating team performance.
- Swarm intelligence which gives a team the ability to adapt to changes, and robustness which enables them to still perform and deliver even when one or more members fail.
Extreme Programming principles:- Humanity: Acknowledge human frailty, leverage human strengths, and balance individual and team needs.
- Economics: Enhance the option value of the software and the team while remembering the time value of money.
- Mutual benefit: All activities should benefit everyone.
- Self-similarity: When something works in one context, try it in another. Even if it eventually doesn't work, it's a start.
- Improvement: 'Perfect' is a verb and not an adjective. Always seek to improve.
- Diversity: The team should comprise people with different backgrounds, skills and perspectives.
- Reflection: Think about how you're working and why you're working.
- Flow: Deliver a steady flow of business value by engaging in all activities simultaneously.
- Opportunity: See problems as opportunities for change and learning.
- Redundancy: Don't be afraid to include redundancy, e.g. a distinct testing phase after development, if it helps prevent disaster.
- Failure: If you're having trouble succeeding, don't be afraid to fail.
- Quality: Always push for higher quality.
- Baby steps: The overhead of small steps is less than when a team wastefully recoils from aborted big changes.
- Accepted responsibility: Responsibility cannot be assigned. It can only be accepted.
Lean principles:- Eliminate waste and spend time only on what adds real value for the customer.
- Amplify learning and increase feedback when facing tough problems.
- Decide as late as possible to keep options open as long as practical, but no longer.
- Deliver as fast as possible, aiming to deliver value to the customer as soon as they request it.
- Empower the team so that people adding value use their full potential.
- Build integrity in, don't try to tack on integrity afterwards.
- See the whole, don't optimise parts at the expense of the whole.
References:[1] K. Weick and K. Roberts, "Collective Mind in Organizations: Heedful Interrelating on Flight Decks," Administrative Science Quarterly, 357-381 (1993).
Tags:
agile principles,
extreme programming,
lean
Links to this post
My interaction style
In my post
Getting to know people, I referenced a simple
questionnaire that I use in my coaching which is based on the
Myers-Briggs Indicator and classifies a person's
type (alternative descriptions of type are available
here). I thought it only appropriate to share my
type with you:
ENFJ
Team Technology says
ENFJs direct their energy towards the outer world of actions and spoken words. They try to build harmony in important personal relationships. Their lives are organised on a personal basis, seeking to develop and promote personal growth in people they value. Here are 2 detailed descriptions of ENFJ:
Tags:
agile coaching
Links to this post
An 'aeroplane in flight' metaphor for agile tracking
During development we want to constantly measure
how much more work we have to do and
how fast we are doing work so that we know where we're at.
Mike Cohn uses a nautical metaphor in his new book,
Agile Estimating and Planning, to explain tracking a release. He identifies 3 factors that should be taken into account:
- The amount of progress that has been made by the development team.
- Any changes to the requirements.
- Developers may have learned things that make them want to revise estimates for future work in the release.
While discussing tracking on
Mike Cohn's
Agile Planning newsgroup, I came across a similar 'aeroplane in flight' metaphor. Unfortunately, I cannot find the original article to provide a reference. In this metaphor our measurements become:
- How much more work we have to do = Relative distance still to be travelled by the aeroplane.
- How fast we are working = Aeroplane's velocity.
The factors identified by
Mike Cohn are similar to the forces experienced by an aeroplane whilst in flight.
aeroplanetrackingmetaphor
Originally uploaded by sjb140470.Drag (changes in requirements) will cause the aeroplane to travel less distance than expected, and if the cross-wind (changes in the estimates) blows from the north while the aeroplane is heading west, the aeroplane will also drift to the south. Without course corrections, the aeroplane will take longer to get to the target destination.
The metaphor has more mileage (if you'll forgive the pun :-) ...
- Adding legs to a flight is like adding user stories to a release. You can add all the legs you want, but unless you can increase the aeroplane's speed you are going to arrive at your destination later.
- Increasing the speed of the aeroplane by increasing the engine size is like adding more team members. Installing new engines will cost installation time.
- Increasing the speed by pushing the engines harder is like working overtime. But this will decrease the engine's life span.
- Aircraft maintenance is like unit testing and merciless refactoring. Neglecting ongoing maintenance can be expensive with an aeroplane (project) grounded when it's supposed to be in the air or an aeroplane crashing to the ground.
Tags:
agile planning
Links to this post
A Scrum Master is like a skilled helmsman
A
Scrum Master steers a
Scrum team like a gifted helmsman steers a boat. He uses the lightest of touches because he knows that each use of the rudder produces drag, which holds the boat back.
helmsman
Originally uploaded by sjb140470.This is based on an analogy found in
Tom DeMarco's book,
Slack.
Tags:
agile,
scrum
Links to this post
Fun and games
One of the branches I've had on my to-do mind map for ages is to build a personal agile consulting toolkit. This is simply a collection of cheat sheets, artifacts, articles, links, etc. One of the sub-branches is to produce a list of games and simulations that are available.
- The infamous XP Game, which introduces a development team to the planning game, velocity, user story estimation, yesterday's weather and the cycle of life.
- Jean Tabaka's 59 Minute Scrum, which simulates a sprint planning meeting, a sprint with daily scrum meetings, and a sprint review meeting.
- James Shore's Offing The Offsite Customer demonstrates the difference between having an onsite customer or product owner that works directly with the development team and having the same customer or product owner located offsite working indirectly with the development team through intermediaries or documentation.
- Screen Test, a complete simulation of Extreme Programming.
- eXPlanations informs people of particular customer and programmer problems and difficulties that arise from unresolved problems.
- XP War explores some of the typical problems and their solutions that can occur when using Extreme Programming.
- Restrospective Roulette helps a development team learn about what is working well and what needs improvement on their project.
- Value Squares teaches how the values map onto the practices in Extreme Programming.
If you know of, and can recommend any others please add a comment to this post.
Links to this post
After
XPDAY5 I contacted
Scott Gilbert at
enthiosys and asked for a set of the
innovation games cards used by
Steve Freeman and
Andy Pols in their session
Getting To Know Your Customer. These cards arrived over the Christmas break while I was away in Austria and I'm now really looking forward to using them as part of my consulting
To my surprise Scott also kindly sent me a copy of
Luke Hohmann's new book
Beyond Software Architecture, Creating and Sustaining Winning Solutions. I'm looking forward to reading this.
Links to this post
Thomas Edison on 'Lean'
The time is coming when every person who lays claim to ability (i.e. agility :-) will keep the question of waste before him constantly. The scope of thrift is limitless.-
Thomas EdisonTags:
lean
Links to this post
The speed of thinking
In his post
Doing fast things or doing things fast, Jeffrey Phillips says "there's a difference between efficiency and effectiveness, mostly in terms of intent". The difference between efficiency and effectiveness is one of the topics discussed in
Tom DeMarco's book,
Slack. In the book,
Tom DeMarco quotes
Tim Lister as saying "
People under time pressure don't think faster".
Basically, when working with software, thinking takes as long as it takes and there's nothing you can do to think more quickly. So if you want things to go faster you have to find other areas in which to accelerate.
Tom DeMarco identifies the only options for making things go faster as eliminating wasted time, deferring non-critical work, and working late. If you're using agile techniques you'll be addressing some or all of these options already.
- Eliminating wasted time: Tom DeMarco says that healthy 'knowledge-workers' don't waste a lot of time anyway because they're more likely to be frustrated by it. One of the rules of lean development is to eliminate all waste, including wasted time in the form of extra processes, unwanted features, task switching, waiting around, and motion or chasing around, perhaps seeking answers to questions.
- Deferring non-critical work: Tom DeMarco says that healthy 'knowledge-workers' derive satisfaction from accomplishment and are therefore likely to work on tasks on the critical path. Extreme Programming uses an onsite customer and Scrum uses a product owner to prioritise the work by business value, and the development team selects an amount of work equivalent to their velocity from the highest business-value items.
- Working late: Tom DeMarco says that, in the short-term, working late can boost productivity but in the longer term excessive hours cannot be sustained. When you work late for extended periods your personal life and your health are not the only things to suffer. More directly, your concentration levels, your ability to focus and think clearly, and your attention to detail deteriorate and ultimately degrade the quality of your work. This style of working rapidly becomes a negative spiral. Extreme Programming employs the primary practice of energized work, which states that you should work only as many hours as you can be productive and only as many hours as you can sustain.
Tags:
agile,
scrum,
extreme programming,
slack,
energised work
Links to this post
