AGILE IN ACTION

At the Agile Business Conference , Ken Schwaber in his workshop - When will Microsoft go out of business? - said 2 things I liked:

Here are some notes I took during Mary Poppendieck 's keynote speech comparing Lean Product Development and Lean Software Development: Change isn't the enemy. Anticipate change . It's there to make things flexible. The 'soft' in software is there for a reason. Software is meant to change so stop trying to nail everything down. Write change-tolerant software by employing change-tolerant practices. Complexity is the enemy. Perfection is achieved when there is nothing left to take away. Write less code . Build what you need now and don't build today what you might need tomorrow - just-in-time not just-in-case. Add features only when you really need them - no features ahead of their time; no features after their time. The rhythm of doing iterations helps to level the workload by establishing a predictable workflow and a reliable pace. Don't force an increase in the workload beyond what can be achieved with a sustainable pace. Create a stop-the-line culture . Invest is systems that detect the moment a defect is infected into the code, and then fix it. You won't achieve fast throughput by maximising person utilisation. If your more than 10% of requirements are changing as you progress, you've specified them too early. If you have separate test and fix cycles you're testing too late. Think 'systems' . Build complete systems, not just the software. Focus on the flow of information otherwise you'll realise Conway's Law . Crisply define value. Don't batch-and-queue. Appreciate the lifecycle.

For the last 2 days I've been at the Agile Business Conference . After last year I said I wasn't going to go this year but I was tempted by the prospect of seeing Ken Schwaber and Mary Poppendieck again. I've heard the material before, but they're both engaging speakers and I was pleased that they were speaking at this conference because the audience is primarily business and project folks rather than the techies you get at XP Day . On the whole, for me, the conference was "same old, same old" but I still left happy. Why? Because there were 2 sessions about Lean. First, Mary Poppendieck's keynote speech comparing Lean Product Development and Lean Software Development. Second, experience reports from BT and Lloyds TSB about their use of Lean. Lean needs more exposure because more people need to know about it.

On the first day of the Agile Business Conference , Roman Pichler talked about the Role of the Agile Product Owner. It was a succinct presentation of the basic responsibilities of Scrum's Product Owner role. Roman conveyed the likelihood that the Product Owner would not be available all of the time (he mentioned hot-desking) nor be colocated with the team. He showed a hypothetical calendar day for a Product Owner that had an hour blocked out in the morning dedicated to collaboration with the team. This set-up is a reality for many companies, indeed it's probably the accepted norm. That's bad! The Product Owner should be a full-time member of the team and be colocated with the team. If he's not then, in my opinion, the team's agility is compromised . The team cannot possibly achieve all that they are capable of achieving on the project. Time-boxing interaction between the team and the Product Owner constrains collaboration with the business. In my mind, collaboration is not something that you turn on and off depending on the time of day. It's a hive of conversation and activity that permeates the environment generating hustle . If you want to achieve hyper-productivity, one of the things you need to be able to do is talk with the Product Owner, as and when you need to, and to demonstrate vertical slices of a user story many times a day to get feedback. If the project is vital to the business, then the company can always find a way to provide a full-time and colocated Product Owner. If they say they can't, it really means they won't. Quite simply, they're not prepared to do what is necessary to achieve it, and frankly, if they're not going to take the project seriously why should you? Usually, the obstacle relates to a silo'ed organisation where departments are arranged by role rather than product stream. Hardly an insurmountable obstacle ... really.

The weasel is agile and fast. But Kent asks "would you trust one? Other than agility what else do individuals, teams and organisations need?" He identified the following: Trustworthiness : People are trustworthy when they do what they say they'll do, promise no more than they can deliver and maintain good intent. Responsibility : "How would you develop if it was your money? Would you spend it on a PRD?" You want low cost and high value delivery. Be aligned with the vision because "it's easier to choose features when you know why you're doing it." And "software is a long game so a sustainable pace if essential." Accountability : "Being accountable is a step towards being considered trustworthy." Be honest. Have nothing to hide. Work in steps of real functionality. And ship early and ship often.

Here are some of the smaller snippets of wisdom I took from the Agile Business Conference : If a man is hungry, you can give him a fish. Better still, you can teach him to fish. Better still, you can teach him to invent a way to fish - Sean Hanly . Extreme Programming forces the business to come down to the developers' level. Scrum forces the developers to come up to the business level. Focus your customer on results not methods. You want repeatable results not repeatable process - Sean Hanly . If it was your money would you spend it on writing a PRD? If it was my money I'd want to see working software - Kent Beck . Self-organisation pushes decisions down and out. Have the customer define the budget. And let the team own it. Sean Hanly talked about Shu Ha Ri as the phases of learning reflected in the adoption of agile methods. Shu: Dogmatically follow the techniques to learn their intricacies and understand how and why they work. Ha: Break away , using your expertise in the techniques to adapt them and learn their limits in different situations. Ri: Achieve fluency with adapted techniques. I liked Todd Little 's analogy for planning with uncertainty using Hurricane Rita's projected path. You couldn't predict where Hurricane Rita would eventually hit the south coast of the US but you could manage for the uncertainty.

It was good to finally meet Diana Larsen at her Retrospectives for Change workshop. Retrospectives help to build trust and morale in the team while improving productivity and capability and increasing quality.

At the Agile Business Conference I went to the Exploring Agile Factors session hosted by Rachel Davies and Steve Freeman . I'm a big fan of chartering because it helps a team to identify the project vision and its community, the project success criteria, its constraints and assumptions, and it also helps a team to establish working agreements regarding how they will apply agile methods. I came away from this session with lots of new ideas and questions to use in my next chartering workshop.

Simon Voice at Connections Recruitment Originally uploaded by sjb140470 .