SE News

Voert uw organisatie agile projecten uit, maar kunt u de voorgespiegelde voordelen niet realiseren? Streeft u een agile organisatie na en wilt u leren van experts? Wilt u het agile werken opschalen van losse ontwikkelprojecten naar een strategie om uw hele IT-organisatie agile te maken? Dit seminar, gehouden op 12 maart 2010 in Bilthoven, gaat in op de essentie van agile werken, zodat u de voordelen in uw eigen context kunt evalueren. Aan de hand van ervaringen uit de praktijk leert u hoe u uw afdeling succesvol kunt transformeren. Interessant? Zie voor meer informatie:

http://www.dnv.nl/nieuws_events/events/2010/seminardeagileitorganisatie.asp
Aanmelden op
http://www.cibit.nl/site.nsf/page/ict_seminars_2010_seminar_12_maart_2010_agile

Scrum and Kanban are two flavours of Agile software development - two deceptively simple but surprisingly powerful approaches to software development. So how do they relate to each other? The purpose of this book is to clear up the fog, so you can figure out how Kanban and Scrum might be useful in your environment.

Part I illustrates the similarities and differences between Kanban and Scrum, comparing for understanding, not for judgement. There is no such thing as a good or bad tool – just good or bad decisions about when and how to use which tool. Part II is a case study illustrating how a Scrum-based development organization implemented Kanban in their operations and support teams.

Consistent with the style of “Scrum and XP from the Trenches”, this book strikes a conversational tone and is bursting with practical examples and pictures.

Henrik Kniberg and Mattias Skarin

http://www.infoq.com/minibooks/kanban-scrum-minibook

At the end of the day, it’s not whether you’re following one process or another that matters, but whether your approach successfully delivers software that people like using—and a process you and your team likes.

Different processes describe different practices to adopt and use. Many tests for good process usually assess whether you’re following the process or not, which doesn’t necessarily mean you’re delivering software people like or that you prefer to work that way.

So, to perform a quick properties-based health check on your current approach, grab a group of your team members, sit down together in a room, and discuss these properties. For each property, ask the team to rate it on a scale of one to five—five meaning you’ve got lots of that property, one meaning that property doesn’t exist for your group at all. Sometimes I use grade levels A through F. Then when looking across properties, I come up with a handy report card.

Jeff Patton

http://www.stickyminds.com/s.asp?F=S15474_COL_2

In May 2009, Outdoor Magazine recognized Rally Software as one of the top ten companies to work for in America. That spawned a conversation between Ryan Martens, Rally’s founder, and me about how agile creates great companies. Rally holds six core values: Make and meet commitments, give back to the community, balance work and life, base decision making on theory, respect people, and create your own reality. As we grow and change, we continuously evaluate how faithful we are to these values. With these core values, we seek continually to strengthen our corporate culture. Based on our conversation about these core values, Ryan and my brainstorm led to these ten characteristics we think are essential to building a truly great agile organization.

Jean Tabaka

http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea

Proponents of Agile and lean software development methodologies say they are becoming more popular than traditional sequential methods in corporate app-dev groups, but implementation of a pure Agile method is still a rarity in the enterprise.

“The movement to Agile is fundamentally changing the way in which organizations build software,” said says Forrester Research analyst Dave West, in a keynote address during the recent HP Virtual Conference 2009. “In situations where the requirements and the technology are far from understood — where there’s a lack of clarity — processes become more and more complicated. So a traditional approach, which requires planning, can’t possibly work.”

John K. Waters

http://adtmag.com/articles/2009/10/13/more-enterprises-lean-toward-hybrid-agile-development.aspx

Much as the Old Town in a European city is the center of the city, but doesn’t itself have a center (all the little twisty streets are roughly equal in “centerness”), so agile looks like a single place from a distance, but isn’t a single place, and the closer you get to the center, the more you see there isn’t a single center. […]
So although agile gets billed most of time through Kent Beck’s “Embrace Change” moniker, I’m not happy encouraging people to just change stuff all the time – it’s more efficient to think for a while and try to make good decisions early – the world will supply enough change requests without us adding to the list by not thinking.

Alistair Cockburn

http://alistair.cockburn.us/Notes+on+the+writing+of+the+agile+manifesto+-+there+is+no+center

Changing anything often invokes fear in people; it is something new and, as such, we don’t know what is involved. We are naturally skeptical of the unknown and, of course, there is always a chance we might not be very good at it, or even worse, might look silly while trying. While a team can grab on to something as simple and effective as Scrum quite quickly, all the associated changes that spring up as a result can cause significant worries. There are some very common broad issues that I warn people to look out for when adopting Scrum in an organization as well as a whole host of nuances that will almost inevitably crop up at some time as well.

I share a few of them in this article so that you can be prepared for them or, perhaps, not feel too bad that you are experiencing them yourself – they are common.

Geoff Watts

http://www.infoq.com/articles/making-scrum-stick

The notion of the magical number of 7 (plus or minus 2) was devised by George Miller in 1956. (No, not that Mad-Max movie-producing-George Miller.) The Wikipedia page illuminates that the “7+/-2″ concept is simply a hypothesis–not something for which you can find extensive scientific research.

That’s ok–you won’t find extensive scientific research for agile either, or for that matter, much of anything to do with software process. But we have stories! We have anecdotes! We have seen agile work, and we’ve also seen it fail. We’ve also noted that it doesn’t “work” overnight: The whole point of agile is that you start somewhere, bite off a small chunk of work, and then continually reflect and adapt.

There are lots of elements in agile to learn and remember. Uncle Bob defines three laws for TDD. Kent Beck devised the four rules of simple design. The agile manifesto defines four values. And so on. We found at least a full deck’s worth of such lists, and have started capturing and using these lists to prod ourselves when our memories fail. The goal of our “Agile In a Flash” project is to produce a web resource, a book, and a replenishable index card deck, all to use as tools in your day-to-day application of agile.

And we will go George Miller two better! Most of the lists fall into the “5 plus or minus two” category.

So who are we? My name is Jeff Langr; you can find more about me here. I’ve known Tim Ottinger for only a little over a year, so I’ll let him speak for himself in his own blog entry. Tim and I are both Object Mentor alumni (and both of us contributed to Uncle Bob’s Clean Code). Tim and I also don’t see eye to eye on everything and we’re both pretty picky, which is what I think will help make the Agile In a Flash cards the best possible set. Stay tuned.

Jeff Langr

http://agileinaflash.blogspot.com/

Recently I’ve been seeing lots more about Kanban development in discussion groups, articles, and at conferences. The surprising thing for me is that many smart Agile people — people I know to be intelligent insightful people seem bugged by Kanban — seem to see it as threat to Agile thinking. Others see it as using new trendy words to describe best practices we already understand. Basically, I keep running into a lot of grumpy agilistas and a few Kanban fanatics. And, the reason I think this is weird, is that I’m seeing Agile people behave as strangely about Kanban as traditional process folks behaved about Agile. They seem threatened. They see Kanban as a fad.

For me I find great value in Lean and Kanban thinking. I do use Kanban ideas in all the Agile teams I coach. And, I do use strict Kanban, WIP limits and all, with a couple teams. No one’s been hurt by it yet. And if it was the rebranding of already known best practice, possibly I was too dense to get it before hearing it clearly described in the Kanban metaphor.

Jeff Patton

http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html

As a customer or supplier of software services at the beginning of a Software Development Project, you know that there is too much at stake to work with just a verbal agreement. A contract is really just a set of written playing rules. The right rules increase the chance of success for both parties. The wrong rules make cooperation difficult and hinder progress. What are the available playing rules and what is the best approach for a agile project?

Peter Stevens

http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

http://manifesto.softwarecraftsmanship.org/

Yes, I am deliberately trying to provocative. And yes, in a very specific way, I believe the latter half of the question to be true. This might be surprising since LeanAgile has seemingly become one word in the world of software development. […] what’s the problem?

In a nutshell: Lean and Agile are grounded in fundamentally different world-views and therefore will inevitably find themselves in opposition on critical points. In the following paragraphs I will try to show the opposing world-views, illustrate one point of conflict, and then suggest how the two viewpoints might be reconciled.

Dave West

http://www.infoq.com/articles/backlog-not-waste

Rocks Into Gold is a biztech parable, written by Clarke Ching, for software developers who want to Survive - and then Thrive – through the Credit Crunch. It tells the story of Bob Billington, an imaginary programmer, who is about to lose his job because his employer’s biggest customer has to cancel their fancy new project for economic reasons. Bob, like all red blooded developers would, starts asking questions, learns a few things that unfortunately few developers know, and then he makes a rather interesting discovery …

Clarke Ching

http://www.rocksintogold.com/

Agile Testing: A Practical Guide for Testers and Agile Teams is now available - authored by Lisa Crispin and myself.

This book is for testers who find themselves on an agile team, test and quality assurance managers in organizations transitioning to agile development, and agile teams learning how to approach testing.

It answers questions such as:
* As a tester, what is my role on an agile team?
* How do I transition from a traditional development cycle to agile?
* What tools do I need?
* Who does what testing on an agile team?
* How can testing “keep up” with short iterations?
* How do we know if we’re doing a good job of testing?
* How can we improve?

We use lots of stories from others, so in a sense, this book teaches by example. It presents many testing challenges faced by real agile teams, including the ours, and explains how those teams solved their problems. We use the agile testing quadrants that Brian Marick introduced to apply different types of agile testing to your unique situation in order to guide development, learn about the product and apply that learning to the development and testing process. The book leads the reader through the agile development life cycle from the perspective of the tester role.

Janet Gregory

http://my.safaribooksonline.com/9780321616944
http://www.amazon.com/Agile-Testing-Practical-Addison-Wesley-Signature/dp/0321534468/

Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and Janet Gregory will be available starting December 26. We are honored to be the first book in Mike Cohn’s Signature Series for Addison-Wesley.

You can pre-order now from Amazon, Barnes & Noble, Borders and other fine booksellers, or buy direct from informIt.com - the coupon code CRISPIN4460 will save you 35%.

This practical book is for testers who find themselves on an agile team, test and quality assurance managers in organizations transitioning to agile development, and agile teams learning how to approach testing. The book starts with an introduction to agile testing, how it’s different from testing on a traditional team, and what makes agile testers different. The book contains dozens of stories from real people on real agile teams about the various
testing-related issues they faced and how they resolved them. A section on organizational challenges covers cultural issues that agile testers face, team logistics, metrics, defect tracking and test planning. One central part of the book uses Brian Marick’s agile testing matrix to go through all the different types of testing needed on an agile project, who does it, how to approach each type, and what tools might help. The test automation portion of the book looks at barriers to successful test automation, ways to overcome them, and how to develop a sound test automation strategy. Another core section of the book takes the reader through an iteration, and more, in the life of an agile testing, from release planning to successful delivery.

In the book, we answer questions such as:

• As a tester, what is my role on an agile team?
• How do I transition from a traditional phased/gated development cycle to agile?
• How do we get testers engaged with the rest of the agile development team?
• What tools do I need?
• Who does what testing on an agile team?
• How can testing “keep up” with short iterations?
• How do we know if we’re doing a good job of testing? How can we improve?
• What do testers do the first few days of an iteration, before any stories are done?
• None of our testing is automated. Where do we start, and how do we find time to do automation?

This book teaches by example. It presents many testing challenges faced by real agile teams, including the authors’, and explains how those teams solved their problems. You’ll learn how apply different types of agile testing to your unique situation in order to guide development, learn about the product and apply that learning to the development and testing process.

Lisa Crispin

http://lisacrispin.blogspot.com