Product Owner and business marksmanship
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.
Tags:
scrum,
product owner,
product backlog,
business marksmanship,
vision,
goal-driven
Links to this post
Say something
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.
Tags:
agile practitioners forum
Links to this post
Scrum Master pulls the trigger
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.
Tags:
scrum,
scrum master,
leadership
Links to this post
7 faces of leadership
1) What you say: Rhetoric. Speaking style and the language and vocabulary used to express meaning and communicate vision and intent.
2) Where you go: Create maps to a destination that realises a vision, which takes the organisation somewhere new. Take action. Lead people on the journey.
3) What you build: Build a physical environment, grow teams and nurture relationships to foster a sense of belonging. Create a mental environment, time and space, to produce ideas, visualise dreams, and chart adventures. Project and imagine a future and be conscious of building a legacy that leaves a positive impact.
4) What you care about: Personal values and principles drive what we say and do and the image we project. The value system within the organisation influences processes and rules.
5) How do you do it: What drives a person often determines the style in which he will act. As do the freedoms he is granted, the modes of collaboration possible, and the ethos he is trying to create.
6) What are you: Awareness. Feet firmly grounded, conscious of situation, surroundings, people, risks, constraints and other factors. Decisive with sound judgement. Responsible. Holds others accountable. Loyal, trustworthy and trusting.
7) What you do: Conscious of being a role model and sets an example. Acts by values, guided by principles. Seeks to bring about change.
Tags:
leadership
Links to this post
Left leg or whole body?
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:
If the teams could vault from novice to seasoned in a day, and if they were less affected by external political/organizational issues, they'd all do fine. The problem they have is getting to that point. That's where they need the most help.
George Dinwiddie responded:
Sometimes those external organizational issues are a part of the reason it takes so long to move from novice to seasoned. I've talked with organizations that want the benefits of Agile, but they don't want to give up the cubes and solo development work. They don't trust the team to self-organize and create valuable software, so they stick with organizational frameworks that prevent the very things they fear won't happen.
Michael Feathers added:
Elsewhere Brian mentions that perhaps we should leave larger organizational issues to others. We can, but if we do, we have to adjust expectations. Working with a single team in an organization is a bit like walking up to a person and saying "Let's see what we can do to make your left leg as healthy as it can be." And, sure enough, there are things you can do. you can inject vitamins, chemicals to foster local growth.. develop an exercise regiment.
You can do a lot for that leg, you can make the muscles bulge, increase its endurance, increase blood flow; but at the end of the day, the health of that leg is going to be sensitively dependent on the surrounding organization.
I think that when we work on the leg, we have to think about the body. If we don't, we have to be less surprised when, at times, the leg does well for a while and degrades or the leg doesn't respond as well as we wish.
Most of us have had success with individual teams. Some of us have had success with whole organizations. But, that link is there. If we look at execution through the lens of single teams, I think we're missing something.
The 'others' Brian refers to is the
APLN, which was established specifically to engage with the industry to bring about change for agility.
Earlier, in
another thread touching on the same issue, I said:
Agility is not sustainable unless the larger organisation is compatible and supportive. More often than not, the larger organisation needs to change, otherwise agility exists inside a very fragile bubble within a hostile business environment. In my experience, agility has always failed due to larger organisation issues. I think it would be remiss of the Agile Alliance to leave the concerns with the larger organisation to others.
The Agile Alliance needs to champion agility and the change required to support it within industries. Agility is never going to stick by supporting only bottom-up initiatives through teams. There needs to be a proactive strategy of engagement with industry, corporate business leaders and decision makers that challenges current thinking in organisations and aims to educate and dispel myths. Let's start trying to gain executive support for agility and indirectly initiate top-down changes in organisations that nurture the adoption of agile methods.
Upon reflection we need to continue to invest in improving people, and their attitude and skills, at grassroots through bottom-up initiatives, and we must also help to effect cultural and organisational change from the top down. Nobody really disputes this. However, I believe that whatever we achieve at grassroots will not survive without holistic change in corporate thinking and structure and that can only be accomplished from the top. Only with a two-pronged strategy can we achieve sustainable and pervasive agility in industry.
If the
Agile Alliance is to focus on one thing and the
APLN on the other, I sincerely hope they can create a collaborative partnership to implement such a strategy so that things can get better for everyone.
Tags:
agile alliance,
apln
Links to this post
Additional values
Brian Marick has identified four values
the Agile Manifesto left out:
1) SkillYou 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.
Tags:
agile manifesto
Links to this post
Layman's Manifesto
Here is Jason Yip's more
personable version of the
Agile Manifesto.
Let's talk to each other.
Let's just build it and show you.
Let's trust each other.
Let's respond to what is happening and what we learn.
I love it! It's on the wall of the
bullpen. And I'm also going to use it when trying to strike up relationships with people from the larger organisation.
Tags:
agile manifesto
Links to this post
Brian Marick wants to stir things up
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.
Tags:
agile alliance
Links to this post
Iterating user interfaces
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.
Tags:
html prototyping,
user interface,
agile
Links to this post
How did it get to be so wrong?
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.
Tags:
fixed-price contracts,
waterfall,
agile
Links to this post
Quality is ...
Quality is never an accident; it is always the result of high intention, sincere effort, intelligent direction, and skillful execution.
- William A. Foster
Links to this post
Lessons are learned ...
Via
Jack Vinson.
"Lessons are learned only when behaviour changes".
Tags:
learning
Links to this post
Does standardisation suppress innovation?
Standardisation doesn't have to suppress innovation (I'm referring to the
innovation that solves problems and helps create value). It certainly doesn't at Toyota but in many organisations it often does.
In
Peopleware, Demarco and Lister said:
Standards are good, but the great triumph of standards in the modern world is almost entirely the success of standard interfaces. A standard for a screw thread or an AA battery says a lot about the final product - how it interfaces with its corresponding parts - but nothing about the process for building that product. To extrapolate from the success of interface standards to the need for process standards is a bit of a stretch.
Identifying an ideal practice is a useful endeavour. But the programs that mandate such a practice are something else entirely.
Standards are seen to embody best practices. But they become institutionalised, revered by some and loathed by others, as systematic indoctrination occurs. Everyone is expected, if not forced, to conform without question or face sanction because adherence to documented standards is seen as a sign of maturity. The very term 'best practices' implies that the practices cannot be bettered. We're schooled to think that there's one right answer. There's not, there are many right answers. And there's no such thing as a best practice. We need to rekindle our innate childlike curiosity and learn to question everything, continuously. Process standardisation without continuous inspection and improvement breeds conformity of thought and that suppresses innovation. Always ask questions. You have
the right.
Toyota uses standardised processes to communicate the current best known way of working. Their standards exist to be questioned by the people doing the work and provide a baseline for change. Everyone is expected to eliminate waste from their jobs and continuously seek better ways of working. Through experimentation innovation happens and people devise and set new standards. There is a relentless pursuit of perfection.
Tags:
innovation,
standardisation,
lean,
toyota
Links to this post
Is there a better way?
Innovation is about solving problems. It's not about invention and technology; it's about economics and creating value. We are mesmerised by new gizmos, gadgets and widgets but we lose sight of the
why behind the
what.
David Neeleman, CEO of JetBlue said:
Innovation is trying to figure out a way to do something better than it's ever been done before.A great innovation is elegant simplicity imbued with the power to create change that matters. You won't find elegance in grand designs or beautiful looks. You'll find elegance in the solution that solves a problem with creativity, simplicity, subtlety and quality with minimum effort and cost. Elegant solutions are obvious only in retrospect.
Companies that have truly mastered innovation know that it can be de-risked by making a number of small bets across a portfolio of ideas, rather than one big bet on a would-be killer app.Tags:
innovation
Links to this post
It takes 1 woman 9 months to make a baby
But 9 women can't make a baby in 1 month. Despite popular belief, there isn't a direct relationship between coder-headcount and productivity. Developing software is a creative and often complex process. It's not data entry.
The other day
Gus was asked by a very senior executive why his team of 16 people were far more productive than another team of 150. Both teams work at the same company. The short answer is the larger team is following a waterfall approach in a bureaucratic and political environment, while the smaller team has achieved agility in an organisation enclave. Process has a lot to do with productivity. Ironically many processes, apparently designed to increase productivity, are actually impediments to throughput. They're more concerned with putting ticks in boxes and producing intermediate artefacts than they are about delivering business value with production quality software.
Jeremy Miller lists many of the scenarios that slow down a traditional team using waterfall:
- Waiting for missing requirements.
- Struggling through ambiguous requirements.
- Not having timely access to the business people.
- Delays from sequential hand-offs between disciplines.
- Testers and developers disagreeing over the interpretation of a requirement.
- Testers receiving code and not knowing what or how to test the completed software.
- Having completed code, but not being able to quickly deploy it for testing.
- Rework because requirements were misunderstood.
- Slow response time when the business people change their minds.
- Assumptions about requirements or architecture being overturned.
- Elaborate documents that quickly become obsolete.
- Code that was written because it will be needed later; it never was.
The
Agile Manifesto values
individuals and interactions over processes and tools. You can do away with prescriptive process and achieve significant throughput if you have a disciplined, colocated and cross-functional team (that includes the
product owner), with people who communicate effectively, collaborate intensively and focus on delivering business value. In an environment where they are trusted to self-organise and make decisions, and where they receive feedback continuously, I bet these people will always deliver more than a traditional team (
more a group than a team) in a
command-and-control environment. Why? Because empowerment and ownership breeds responsibility, commitment, accountability and motivation. You'll see delivery, early, often and regularly. Disempowerment and control breeds mediocrity, apathy, fear and demotivation. People turn up but they lack commitment and they don't really take responsibility. You'll see missed deadlines, a distinct lack of delivery, and ultimately you'll smell the
dead fish of failure.
Skills and practices also affect productivity. Who's more productive? The developer using
test-driven development and
continuous integration, who checks in code and integrates with others many times a day, and who collaborates with testers performing exploratory testing in parallel. Or the developer who codes for days (if not weeks) before checking in and integrating with others and then hands-off to testers for manual ad-hoc testing, bouncing back and forth as he fixes bugs until the code is working? I bet it's the first developer.
Give me an agile process in a lean environment any day.
Tags:
productivity,
process,
agile,
waterfall
Links to this post
Wake up and smell the complacency
Via
Ed Gibbs.
A recent Gartner reports says:
Wake up IT managers, you're mediocre at best. A sweeping generalisation? Probably. But I've definitely worked in places where mediocrity is accepted as the norm. Typically, these have been large companies with deep hierarchies, bureaucratic culture,
command-and-control management and groups of people silo'ed by role. These companies are
pickled.
Gartner claims:
This industry is in danger of becoming one of failure. We've come to accept mediocrity as the norm. It's not a lack of technology or skills. The problem comes down to a lack of vision. And I would add, ignorance - many companies simply don't see their mediocrity - while those that do are not able to change.
Sadly, the order of the day seems to be: Maintain the status quo to keep your existing systems up and running at all costs. Bolt new functionality onto legacy systems, and increase the already unmanageable complexity and disproportionate maintenance burden. Complicate things for everyone by building what will quickly become even more legacy systems. Don't think about gradually replacing creaking systems with new, more innovative solutions that are extensible and easy to maintain, and are feature-rich, simpler and more compelling to users. That would be too painful. Give your money away to big vendors whose business models are inflexible and consequently struggle to compete with the open-source revolution where platforms and tools are free of charge and are borne out of innovation. Lock yourself in and survive from patch to upgrade as you pay even more money for an exorbitant maintenance contract. Let their technologies and solutions constrain your innovation.
Many companies have stagnated. They are caught up in their
organisational constipation and are struggling to remain competitive. They rely on captive users for revenue. Users that were caught many moons ago when the companies used to be innovative. But their numbers are declining as increasingly savvy users are jumping ship to find better products and better services for less money elsewhere. To survive in today's markets, companies need to innovate more and learn to
compete on the basis of speed.
Again I believe the impediment here is culture.
Tags:
culture,
innovation
Story test-driven development
Rick Mugridge talks about story test-driven development
using FIT and
doubling the value of automated tests. Story tests, written in FIT, capture the details of user stories as concrete executable examples and help you to know when you're done.
These video presentations are not technical tutorials on how to use
FIT/
FITLibrary/
FitNesse.
Tags:
fit,
story test-driven development,
tdd,
user story
You, organisational hierarchies, avast there!
Via
Knowledge Jolt with Jack.
Sigurd Rinde says that
organisational hierarchies in practice gets in the way of service. They breed inefficiency; you're left with the idea that the company (read brand) is stupid; fear of the boss fear is more important than pleasing a customer.
Jack Vinson comments:
Isn't it funny that the people in the hierarchy believe they are enforcing efficiency (in their sphere of influence) and they end up creating less efficiency for the organization as a whole -- particularly at the customer-facing end that this story addresses.They also degrade peoples' ability to be effective.
Tags:
culture,
organisation,
hierarchy
Links to this post
Agile estimation techniques
Mike Cohn talks about agile estimation techniques:
Part 1 and
Part 2.
Tags:
agile estimation
Links to this post
Fixed-price contracts don't work
When you buy something, you want to know exactly what you'll get and how much it will cost. It makes sense. But this doesn't work when you're buying software development. If only it did. Writing software is a creative process and developing software systems is a complex undertaking. If you think it's possible to identify a single date, somewhere off in the future, upon which you'll receive everything you've requested and for a fixed price, then you're setting yourself up for failure and disappointment.
To say how much something will cost, you need to know in great detail exactly what needs to be built so that your estimates for the work can be accurate. But you can't define everything you want, in detail and up front, and get it exactly right so there will be no changes in the future. And no estimate is ever accurate (it wouldn't be an estimate if it was).
Let's be honest here. You're unlikely to know exactly what you want because visualisation only goes so far. You'll probably only know what you want when you actually get to play with it. It's only when you experience using a fully functional user interface, with working code beneath it, will you appreciate its usability and decide if it works for you and meets your needs.
Now, maybe you can spend an inordinate amount of time eliciting requirements, analysing them and producing a specification, and possibly get close enough to what you really want. But you're still not going to eliminate uncertainty as the project progresses because when people read your specification they'll take away their own interpretation of what you want. If it were my money I'd want to spend it on working software that realises my needs incrementally and helps maintain my competitiveness and not on documentation.
A change management process is a good way to ensure your product is built to specification. And your vendor will support this because, since you've beaten him down on price and then fixed it, he'll want to make money on the change requests. This motivates you to cram even more requirements into the specification (even if you don't really need them) just to cover all the options and hopefully minimise any changes down the road and avoid further expense. It rarely works out that way though. Change is still inevitable. A change management process just makes it more difficult to make changes, and consequently you're even less likely to get what you really want. Ironically, the cost of change requests is often responsible for forcing a project over budget. This defeats the purpose of fixing the price in the first place.
You can fix dates (although it's not always necessary to do so). And there's always a budget. But when you fix scope too quality inevitably gets compromised. That's bad. Why would you compromise the quality of a corporate asset? You should never compromise on quality. If you acknowledge that you don't know exactly what you want, wouldn't it make more sense to vary the scope?
Don't base the contract with your vendor on conformance to a detailed requirements specification. If you do, you're saying all your good ideas happen at the start of a project and you're effectively betting all your money on a hole-in-one. Insist your vendor use an iterative approach to software development so that changes can be accommodated at any time during the project. And have the contract focus on the relationship with the vendor, not on the desired results of the relationship. By that I mean base the contract on incremental delivery of functionality and specify functional goals, not specific functionality. This allows you to evolve the details of the required functionality as the project progresses. Prioritise the functionality by business value and have the vendor work on it in that order. Work continuously with your vendor. Frequently inspect what's been built, provide feedback that steers their effort towards what you really want and and pay per iteration.
The
Agile Manifesto says:
Value customer collaboration over contract negotiation. Enter into and nurture a collaborative partnership with your vendor, which is built around common goals, and shares the risks and rewards.
Reference:
The consequences of fixed-price IT projects by Scott Ambler.
Tags:
fixed-price contracts,
agile
Links to this post
Testing in agile projects
In a video presentation (via
InfoQ), Scott Ambler talks to a testing user group (TASSQ in Toronto, Jan 2006). He explains agile methods, in particular Extreme Programming, and talks about the
the role of testing and QA in agile projects.
He recommends that testers and QA people become generalising specialists because, in an agile team, they're not going to spend all their time testing. They need to collaborate intensely with everyone in the team and need to be flexible and communicative. They can specialise in testing but they also need to be able to do some programming, some data modelling, get involved with build and deployment activities, understand the domain and work closely with the
Product Owner to identify and evolve
user stories (capturing their details in acceptance tests), and pick up other skills as they're needed.
Elisabeth Hendrickson is a tester who has become a generalising specialist through her experiences working in agile teams. Watch her video about
agile testing delivered at Google.
Tags:
agile,
testing
Links to this post
Competing on the basis of speed
At Google, Mary Poppendieck talks about
Competing On The Basis Of Speed.
Tags:
lean
Links to this post
Talking about agility
When people talk about Agile (with a capital A) organisations think "methodology for software development teams". This thinking gains credence when Agile finds its way into organisations through developers, as a grass-roots initiative, which is often the case. Taken alone, this adoption route is likely to fail, or at best, be severely hamstrung because the business and other organisational entities are not operating with the same values and principles.
In supposedly agile projects, the values and principles break down in the wider business. Some organisations are unaware of this. And most aren't capable of addressing it because of habit, superstition and fear, inertia, and a lack of top-down support. Alarmingly, compromising the values and principles seems to be culturally accepted (and, in my opinion, endemic in the industry today). If the whole organisation cannot operate with shared values and principles, the technical investment becomes increasingly overshadowed by compromises made in the business domain. And it's these compromises that eventually cause projects to fail.
These days I try not to say Agile (with a capital A). When I talk with companies I talk about "agility" and "achieving agility". For me, "agility" is the ability to deliver value to the business frequently, with quality software, and in a repeatable manner by leveraging the capability of empowered, disciplined, self-organising and cross-functional teams that are employing techniques based on the values and principles. While "achieving agility" is a continuous process of change which, to be successful, must involve the whole organisation.
This post is based on one of many thought-provoking and enlightening conversations I have with
Gus.
Tags:
agile values,
agile principles
Links to this post
