Re: [scrumdevelopment] Re: Scrum Exception Cases Summary for feedback
- Excellent point/post, Mark, ++1!-------
Charles Bradley, CSM, PSM I
Experienced Scrum Coach
My blog: http://scrumcrazy.wordpress.com/
From: woynam <woyna@...>
Sent: Wednesday, October 26, 2011 7:56 AM
Subject: [scrumdevelopment] Re: Scrum Exception Cases Summary for feedback
I think we need to be clear. An 'Iteration' is a measure of time. An 'increment' is a measure of delivered product.
It is very easy to have an iterative process that produces no usable product until the very end. We've probably all seen cases of this (Iteration 1: planning, Iteration 2: analysis, Iteration: 3 design, Iteration 4: coding, Iteration 5: Testing, Iteration 6: whoops. Return to planning).
Agile processes are both iterative and incremental. We use a period of time to produces a demonstrable subset (increment) of the product.
While one could argue that a requirements or design document could be used to get feedback, our community is well aware that only the actual working product provides the necessary means to get good feedback.
--- In email@example.com, "avinap77" <avi_a@...> wrote:
> Hi Nicolas.
> I've been silently on-and-off following this thread,
> some thoughts:
> First of all take note that Agile is a set of values and principles, an attitude to software development.
> Scrum on the other hand is one implementation of Agile, as is XP.
> In your notes Agile and Scrum seem to be regarded as synonymous, You might want to make the distinction between the two and focus on one of them - say on agile, using scrum as one possible (but not the only) example.
> > • Agile methods being iterative process, possible issues can be
> > found fast enough so that it is possible to reassess if the method
> > truly is appropriate. As a result the cost to try is much more
> > limited compared to other techniques.
> I'm not sure that being an iterative process has anything to do with determining if it's appropriate or not.
> Being an iterative process means you get feedback on the product from customers and improve your further plan accordingly.
> It also means you get feedback from the team on their work (as in retrospectives) so they can improve their own working process.
> Being iterative will not necessarily tell you anything about organizational issues - that's something you'll get from visibility and holding strong constraints on each member's responsibility (for instance in Scrum the PO is the sole person responsible for prioritizing the backlog. If other stakeholders "butt-in" and prevent the PO from doing his/her work - that's an organizational issue which would question the appropriability of scrum for the org).
> Either way I think it would be wrong to ask for an answer to the question "is agile truly appropriate".
> There is no right or wrong answer - since agile is a set of principles, it's like asking "is Justice truly appropriate?"
> The question should be "is the org willing and capable to adopt these values?".
> usually when I present the benefits of agile I find everyone *wants* the benefits, however not everyone is willing too pay the price.
> It's a question of making a decision, alongside with the risk involved in it. There are no analytic right or wrong answers to it IMO.
> > • Scrum is best suited for software development. That doesn't mean
> > that it cannot be use elsewhere but you'll need to be extra cautious
> > that you have something you can demo and ship on which you can work
> > incrementally (so that you can get customer feedback). WikiSpeed and
> > the car they develop is a stunning example of Agile development
> > outside of the software industry
> You might be interested in implementations of scrum at home and with kids:
> The idea is to embrace the scrum principles - quite interesting and effective.
> Hard to say if it's more effective in software or less - that would be comparing apples and oranges.
> BTW from my own experience - it's //much// easier to introduce Scrum principles and practices to children than to elders - they'r more open to new ideas, They see the fun in it and don't judge it as being "not serious". They immediately attract to the idea of taking on responsibility and participation - for them it's an opportunity to be active players, whereas many elders would keep a "safe distance" before participating in Scrum.
> > • Maintenance projects are not the best suitable for classic Scrum
> > with issues such as lack of focus and moving priorities. Kanban-
> > Scrum offer good alternatives for these situations since it allows
> > for more flexibility regarding scope and release dates (both things
> > useful in maintenance cases).
> Like others have mentioned - I too don't find the distinction between maintenance and non-maintenance to be useful anymore. it's like making the distinction between driving to the end of the world and falling off of it. Once you realize the world is round, the distinction is void. Once you work agile - all you have is continuous development. The distinction between "developing it" and "maintaining it" is no longer relevant, a remmant of the extinct paradigms of waterfall.
> Free you mind! :)
> and hope your thesis goes well. It sounds interesting.
> --- In firstname.lastname@example.org, "nicolaslochet" <lochetnicolas@> wrote:
> > Hi,
> > I'm coming back with a follow-up on the discussion I had here in a more digestible manner.
> > First of all, I'd like to offer my apologies since I cheated a bit. In fact I'm not entirely new to Agile practices.
> > Actually I'm currently an Agile Coach at Sogeti but more importantly I am writing a thesis on Agile methodologies. As I did not wanted that to influence your answers I did not mention it in the first place.
> > In my thesis I want to go back to the roots of Agility so that people can really understand what they do when using Agile methodologies and so that they don't follow rules or worse adapt them without a good understanding. The ending goal is to define what are the limits of Agility or more positively its exception cases. I have seen and read a lot of things on Agility but there are very limited materials on things that can go wrong and why.
> > Of course I have a few ideas of my own regarding that but I wanted also to get direct feedback from you guys who have quite a lot of experience with Agility (and let's face it a lot more than me, I have not been a coach for that long!)
> > One more thing before I present you what I think is the summary of our discussions, my thesis is not a PhD thesis it is a thesis for my Specialized Master in Business Consulting (project management). Since Specialized Masters are French stuff, if you want to know, just consider that this similar to an MBA but when MBA are generalist this is (as the name suggests) specialized in one area (project management in my case). That is to say that it is not as deep as a traditional PhD thesis could be (though of course I'm doing my best here!).
> > So here is the summary:
> > It doesn't cost to try:
> > • Agile methods being iterative process, possible issues can be found fast enough so that it is possible to reassess if the method truly is appropriate. As a result the cost to try is much more limited compared to other techniques.
> > Communication, team mood and motivation:
> > • For maintenance it is important to keep high visibility on what is going on even if we don't use a classical scrum (to avoid expectations issues)
> > • Communication is not only essential within a Scrum team but also towards management and the organization. Lack to do so will most often result in trust issues towards the team and negative effects on team-mood.
> > • Motivation is an important pre-requisite to a good scrum that can be too easily ignored. Since building motivation is complex, building the team relationships should probably be an important task of the project
> > • Since Scrum requires highly motivated teams, able to act as one, outsourcing and geographical distribution are contexts that increase the amount of risk put upon the project. A traditional project management structure should probably be considered in this case and it shouldn't be recommended to teams having their first go with Scrum.
> > Efficient Customer feedback:
> > • Using customer proxy can be an issue as this involves assumptions about what the customer wants that are less an less accurate the farther apart from the true customer we are.
> > • Teams should be cautious that their end of sprint delivery is of actual worth for the customer and useful for feedback. We don't deliver because we can or because the date is due but because it is worth it.
> > • A key issue for any Scrum project is if the Product Owner is not able to prioritize backlog elements. We don't want to be faced with situations were we have only highest priorities and no distinctions in between those. Moreover we should prevent team members to pick-up their own but use the voice of the client to get the correct order (possibly through discussion with the team though). The risk in this case would be to revert to the classic project management structure where the development team works in a silo with no exterior contact till the end.
> > Scrum team structure:
> > • Scrum needs feature teams to work (by opposition to component teams), which means that it need a cross-functional team, and is not adapted to work in silos. We should be cautious not to divide the project in too many separated pieces or we risk a big-bang issue at integration. To some extent this means that teams should never be fully separated and that communication and integration are kept frequent in such situations.
> > Types of projects:
> > • Scrum is best suited for software development. That doesn't mean that it cannot be use elsewhere but you'll need to be extra cautious that you have something you can demo and ship on which you can work incrementally (so that you can get customer feedback). WikiSpeed and the car they develop is a stunning example of Agile development outside of the software industry
> > • Maintenance projects are not the best suitable for classic Scrum with issues such as lack of focus and moving priorities. Kanban-Scrum offer good alternatives for these situations since it allows for more flexibility regarding scope and release dates (both things useful in maintenance cases).
> > No Silver Bullet:
> > • Scrum needs flexibility on Scope (and the hidden Quality) and won't work if you are only trying to get the trio Scope/Schedule/Budget fixed. Traditionally Scrum adjusts Scope to be able to respect Schedule and Budget and Schedule is fixed.
> > Some other risks I've found that I won't detail here but that I give for your thinking:
> > • Contractual issues (fixed scope and budget) imply willingness to adapt the contract.
> > • The extensive list of soft skills needed, the ideal team probably doesn't exist.
> > • Distributed development stretching the limits of communication
> > • Customer lack of commitment
> > • The never-ending story: ideal value vs customer value. Knowing when to stop
> > • The risks of bottlenecks, preventing experts overload
> > • Estimating development budgets
> > • Rewarding individuals for collective work
> > • Pair programming consequences on human relationships
> > • Managing the technical debt
> > • The multi-project team
> > • Large scale projects
> > That's it!
> > Comments are welcome!
> > Nicolas
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
<*> To visit your group on the web, go to:
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to: