AGILE IN ACTION

Being an effective Product Owner is a full-time job and managing the Product Backlog is a constant activity. It's not as trivial as it might sound. The Product Owner is responsible for the features that are delivered. The team is responsible for the quality delivered. It's the Product Owner's responsibility to maximise the return on investment in every release and every iteration. The Product Owner needs to look after the Product Backlog because their decisions and actions govern the flow of value to the customers by effectively steering the efforts of the team. And to compete on the basis of speed a continuous flow of valuable features to the customers must be sustained. Managing the Product Backlog, which is a dynamic list of evolving user stories , is often dismissed as simply routine with insufficient time and attention dedicated to the activity. Consequently focus is lost resulting in a divergence from the project vision, the coherence of the backlog dissipates, prioritisation becomes based on fancy rather than on feedback, return on investment diminishes, the team stalls and is unable to sustain creation of value at a steady velocity, and ultimately the customers become dissatisfied because they're not receiving the features they deem to be valuable. Managing the Product Backlog requires constant care and attention. It requires diligence, discipline, awareness and business acumen , and decisiveness. It takes business marksmanship to realise the vision for the product by hitting each goal in turn and generating the biggest bang for the buck. Before shooting, a sniper will first assess a number of criteria - distance and elevation, weather conditions, etc - while constantly surveying his surroundings. In a similar fashion, the Product Owner has to be aware of a number of factors making up the goal - value, cost, risk, priority, etc - while keeping an eye on the big picture. The difference is the Product Owner has many opportunities to assess and re-aim en route. It's fire and aim, aim again, and keep re-aiming until you hit the target. First fire in the general direction of the vision. Then repeatedly re-aim at goals that move you towards that vision, iteration by iteration, all the while keeping an eye on the big picture just in case the vision changes in response to the market, competitors, or modified business objectives. The Product Owner must be continuously engaged with the team, collaborating and providing feedback as user stories are being developed, and he must be prepared to accept or reject the features delivered at the iteration review. The Product Owner must always be looking ahead to coming iterations and beyond, and planning adaptively to evolve goals and evolve the user stories that satisfy them. To be able to look ahead with sufficient clarity, the Product Owner needs to engage, on a regular basis, with the sponsor, key stakeholders, and other executives to preserve strategic direction and maintain visibility. This involves a demonstration of the goals achieved together with an appraisal of the quantified value delivered per investment period (iteration or release), and discussing coming goals, while obtaining feedback, to ensure alignment with the vision and business objectives. In effect, the Product Owner is empowered to pursue the strategic vision by defining and then steering by tactical iteration goals.

Are you exasperated at how organisations are transitioning to an agile approach? Are you tired of hitting the same brick walls with organisations that are trying to be agile (or claim to be agile)? Are you fed up with command-and-control and organisational intransigence? Disillusioned with organisation culture? Are you annoyed by the lack of concern many organisations have about value and quality? Are you saddened by the decline of craftsmanship in software development? What do you think about the state of Agile in industry today? Do you want to challenge the status quo? What ideas do you have for improving things or bringing about change? I'd like to hear what you've got to say. And so would others. I invite you to share your thoughts and ideas on the Agile Practitioners Blog . We're interested in what's going on in the agile world and what people think about it. We want to continue asking questions about agility, how it's being executed and what obstacles it faces. We want to debate the issues and topics that are percolating in the agile community. We believe there is an opportunity here to generate ideas and innovate new techniques that move us beyond debating current practices. The blog content is generated by the Agile Practitioners Forum, attended every 10 weeks by a boisterous group of contributors comprising some of the leading agile practitioners in the UK. However, we would really like to draw on the breadth of experience within the evolving agile world to complement, challenge and perhaps to disrupt the Forum, and certainly to stimulate new thinking and to elicit broader debate. You're free to comment against any existing post. If you wish to contribute a post of your own (as a guest) email your text to submissions at agilepractitioners dot com. We do hope you'll choose to contribute. Please note: We do reserve the right to edit submissions to ensure that the content is appropriate to the goals of the Forum and to the audience.

A Scrum Master should trigger: Direction by steering the team with a light touch while letting people self-organise. Destiny by leading the team on a journey that realises a shared vision. Discovery by creating an empowering context for the team where people are free .

Brian Marick has identified four values the Agile Manifesto left out : 1) Skill You need competent people. 2) Discipline You need self-disciplined people to perform the practices correctly and maintain rhythm and frequency of delivery. You need people to execute well. 3) Ease You need people who invest effort into making their lives easy. This is not about shirking responsibilities or avoiding making commitments. It's about reducing pain. For example, technical people maintain a code base that is habitable, where changes are comfortable to perform, by employing test-driven development and refactoring, and by fixing defects as they are found, minimising technical debt, and maintaining executable code through continuous integration. The value of ease should apply to everyone and all aspects of work. 4) Joy You need people who insist on experiencing joy. People deserve to have fun at work. When people are skilled and disciplined, experiencing joy at work has only healthy and beneficial side effects.

There's some discussion happening at the Agile Forums about refocusing the Agile Alliance . Brian Marick advocates a new focus on helping teams be ready to execute Agile:

Here is Jason Yip's more personable version of the Agile Manifesto .

Through the Agile Alliance , Brian Marick wants to stir things up to help address his disquiet over the state of Agile as it moves into the mainstream . To be entirely honest, I've been disillusioned with the Alliance for a while because I believed its focus to be limited (programs delivering questionable value from and a conference in America that, for the most of it, is not covering new ground). Now I'm smiling. The Alliance is hopefully going to get more involved and help us tackle some of the issues that have been keeping me up , in particular compromised agility , agile mediocrity , organisation culture , command-and-control management . This is a worthy effort and Brian should be applauded for initiating it. I sincerely hope it will invigorate the community, improve on the status quo, and pull agility forwards with renewed focus and energy. Please contribute at the Agile Forums .

I like this article about HTML prototyping and agile development . While I wouldn't call it prototyping, it does advocate building the real user interface iteratively, evolving behaviour based on received feedback, and adding functionality incrementally rather than produce a variety of static mock-ups such as wireframes. We've been building user interfaces iteratively. It works best when the creative and Web people are part of the team and are colocated. The benefits include: Tangible progress is visible. A working application is the only true measure of progress. Clients and stakeholders love to see results, even if they're evolving. The sooner you have something real to show off, the happier everyone is going to be. It's more engaging. Because it's tangible people can play with it. Their understanding of how it works improves and they can provide better feedback. It bridges communication gaps. A common vocabulary emerges as people discuss and interact with the prototype, rather than interpret a design document. Communication and feedback are focused and less ambiguous. It's more thorough. It's better to invest a bit more time developing the prototype to gain insight into many variables that are overlooked by wireframes, e.g. state, security, error messages, level of effort, page flow, scripting, etc. It's a reality check. You have to consider factors contributing to the total experience, which you might ignore when creating wireframes, e.g. response time, ease of implementation, cost of maintenance, interfacing challenges, etc. It helps you avoid document debt. You achieve more because you can spend more time with developers evolving a working prototype and receiving valuable feedback, rather than writing and then having to maintain documentation. Talk is cheap. Typically, meetings and design documents are waste. Start writing code immediately. The sooner you uncover issues, the sooner you can understand them and adjust your estimates, and the sooner you can resolve them, avoiding impact to the timeline. To develop user interfaces iteratively using HTML prototyping you need to expect and embrace change. You need to write good code because high quality code is easy to change, and you need to maintain a working interface, always. Start small, and employ varying levels of detail as required. And let things evolve. Being able to change user interfaces quickly gives you an advantage and contibutes to your ability to compete on the basis of speed .

A short while ago I said that fixed-price contracts don't work . Over on the Scrum Development group there's a discussion about competitiveness, estimates and organization culture . Dave Martin said: People underbid because it gets them the initial contract as many clients will just go for the lowest bid. Once the project is underway, the costs start to escalate and the client has 2 options - pay up or write the project off and start again. The client is often better off writing off their initial investment and starting over but its amazing how often they don't do that and continue to burn money. Keith Sterling responded: This is why so many large consultancies stick to the waterfall method. By bidding low and stipulating a waterfall approach, yet knowing that 99.99% of all projects will undergo 25-35% change during its lifetime, they know they will be able to make up the shortfall in their bid with high value change requests. It's a well known fact, yet unwritten rule that most large consultancies in the UK base their business model on the volume of change requests they can generate during a project, and why most of these organisations have some of the biggest legal departments I have ever seen. Where is the sense in awarding business based solely on the price? Price is meaningless without a measure of the quality being purchased. If clients award business to the lowest bidder they're likely to receive low quality and high cost. You get what you pay for. And the client-vendor relationship will become acrimonious as neither party is satisified and it falls to the lawyers to fight it out. Deming predicated that driving down the price without regard to quality and service will drive good vendors and good service out of business . He was right but it's actually worse. As Keith describes, we now see companies making money from providing poor quality by charging extortionate sums for change requests. It's part of their business models. What a truly sad state of affairs. Wouldn't it be better to enter into and nurture cooperative partnerships for the long-term that are built on mutual loyalty, trust and confidence, and which share the risks and the rewards? If you treat your partners as extensions to your business and align incentives so that everybody works for the good of the partnership, then quality will return, cost will fall, speed of delivery will increase, customers will be happy and everyone will realise prosperity.