Has the team made changes that make a difference to them as a result of the
retrospective?
tips on reviving retrospectives from the retrospectives yahoo group - 0 views
-
-
Has the team explored a variety of different topics/areas, or do they stick to pretty much the same agenda around continuous improvement? What is the balance of change/improvement work vs. working on the product?
-
For example, try looking at technical practices, teamwork, or customer relationships... choose what ever seems most relevant to bound the discussion. That might help the team dig deeper and find issues that have more significance for them (now...I'm sure the other changes were significant at the time).
- ...14 more annotations...
Tailor your Message To Gain Support for your Agile Initiative | Enabling Agility - 0 views
-
Connect Agile’s Benefits to your Company’s Priorities
-
aying that Agile is “better, faster, cheaper” may not be enough to cause a company to be willing to go through the often-painful process of cultural and process change. You could implement Agile, but you could also try Six Sigma or Lean. Saying that Agile is a general get-better remedy puts it in line with many other get-better methods.
-
ur last two releases have looked like me-too updates, where we are just barely keeping up with our competitors
- ...21 more annotations...
Kanban development oversimplified: a simple explanation of how Kanban adds to the ever-... - 0 views
-
It’s a lot easier to estimate a story that’s small — which can lead to more accurate estimates, and better predictability.
-
It’s easier to plan with smaller stories. With big stories — stories that might take weeks for a developer to implement — it becomes difficult to plan a development time-box — particularly when the iterations are only a couple of weeks. It seems that only a couple stories fit — and there’s often room for half a story — but how do you build half a story? Splitting them into smaller stories makes it easier to plan those time-boxes.
-
Shrinking stories forces earlier elaboration and decision-making. Where product owners could write their stories fairly generally and consider many of the details later, now breaking them down into smaller stories forces more thinking earlier in a planning lifecycle.
- ...36 more annotations...
Is Design Dead? - 0 views
-
In its common usage, evolutionary design is a disaster. The design ends up being the aggregation of a bunch of ad-hoc tactical decisions, each of which makes the code harder to alter. In many ways you might argue this is no design, certainly it usually leads to a poor design. As Kent puts it, design is there to enable you to keep changing the software easily in the long term. As design deteriorates, so does your ability to make changes effectively. You have the state of software entropy, over time the design gets worse and worse. Not only does this make the software harder to change, it also makes bugs both easier to breed and harder to find and safely kill. This is the "code and fix" nightmare, where the bugs become exponentially more expensive to fix as the project goes on
-
the planned design approach has been around since the 70s, and lots of people have used it. It is better in many ways than code and fix evolutionary design. But it has some faults. The first fault is that it's impossible to think through all the issues that you need to deal with when you are programming. So it's inevitable that when programming you will find things that question the design. However if the designers are done, moved onto another project, what happens? The programmers start coding around the design and entropy sets in. Even if the designer isn't gone, it takes time to sort out the design issues, change the drawings, and then alter the code. There's usually a quicker fix and time pressure. Hence entropy (again).
-
One way to deal with changing requirements is to build flexibility into the design so that you can easily change it as the requirements change. However this requires insight into what kind of changes you expect. A design can be planned to deal with areas of volatility, but while that will help for foreseen requirements changes, it won't help (and can hurt) for unforeseen changes. So you have to understand the requirements well enough to separate the volatile areas, and my observation is that this is very hard. Now some of these requirements problems are due to not understanding requirements clearly enough. So a lot of people focus on requirements engineering processes to get better requirements in the hope that this will prevent the need to change the design later on. But even this direction is one that may not lead to a cure. Many unforeseen requirements changes occur due to changes in the business. Those can't be prevented, however careful your requirements engineering process.
- ...6 more annotations...
1 - 5 of 5
Showing 20▼ items per page