AGILE IN ACTION

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 owner

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 burnout Use 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 schedule Strategic 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 iteration The 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 iterations The 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?

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.

This blog is now published at the Artima Agile Buzz . All I had to do was modify my FeedBurner feed to RSS2.0.

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 theme It 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 .

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.

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.

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.

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.

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 effect Task switching increases busyness but most of it is thrashing, non-productive and ineffective work.