Picon

Yet Another New Product Development Game?



Hi, folks!


I’ve been trying for over a year to equate Agile and Lean Thinking with other ideas and knowledge areas of product development. From my point of view agile and lean are essentially about product development but it’s been really hard to argue this to people from other areas, specially UX Design and some Product Managers.


Designers (at least the ones I work with) seem to focus much more on the differences between Agile and Design Thinking than on their similarities (which I think are numerous). The aspects that I’m having more trouble with designers relate to: a) being on the same team as developers; b) sharing responsibility for the whole product/process; and c) specialty vs multidisciplinarity


In The New New Product Development Game (1986), Takeuchi and Nonaka talk about how product development was like at big successful multinational companies. It is a great inspiration to me but I haven’t found any recent examples that play the game like they said. I took a few paragraphs from the article to illustrate my points. I would love to know if there is a Yet Another New Product Development Game that I’m unaware of.


a) Begin on the same team as developers


‘Under the rugby approach, the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish.’ (Takeuchi & Nonaka, 1986)


I’ve heard time and again from designers and non-designers that ‘designers want to work with designers’. At my company we have two design ‘teams’: Web/Graphic Designers and UX Designers. Everyone in both of these ‘teams’ prefer working in a waterfall fashion where their specialized group produces artifacts which are then consumed by a real multidisciplinary Scrum development team responsible for everything from then on (get the features to production).


So my questions to you guys are: have you ever worked with a real multidisciplinary team including every specialty needed to deliver a product on the same team (designers)? How did that work for you? What works and what doesn’t? Is it something worth fighting for? How designers feel about it? How can I get designers to believe in this model?

 

I won’t address aspects b) and c) for now so we can focus on aspect a)

 

Any help is very welcome!



__._,_.___
Posted by: Gercel Silva <gercel <at> gmail.com>


To Post a message, send it to:   SCRUMDEVELOPMENT <at> eGroups.com
To Unsubscribe, send a blank message to: SCRUMDEVELOPMENT-unsubscribe <at> eGroups.com




__,_._,___
Picon

Re: Hours Estimation?



I work in a traditional culture working for an incredibly traditional customer in a notoriously traditional regulatory environment (defense contracting).  I have constant pressure to provide traditional style metrics for progress.  The most success I have had is working with these stakeholders to find out what they need from the statistics and do my best to generate the metrics they are used to from the agile metrics I have (i.e. computing EVM's SPI and CPI from story burn down and projected story count to implement required functionality.  I try to minimize how much silly metrics drive the development process.  When people complain that the metrics don't always show consistent progress, I try to get them to realize that their old metrics weren't really any more accurate (in fact, the agile metrics are probably more accurate than the old metrics), they just hid the real situation well.

In short, if you can give program managers, business administrators, or executives the warm fuzzies that they used to get from their old metrics, they will be less inclined to micro-manage the details.  And if you can show positive results, they will start to trust you even if they don't really understand what you're doing.

On Tue, Jan 6, 2015 at 11:07 AM, Bob Paige bobpaige <at> gmail.com [SCRUMDEVELOPMENT] <SCRUMDEVELOPMENT <at> yahoogroups.com> wrote:
 

I'm in a similar situation, where management's concern is "will we get everything done by the specified date."


I monitor these discussions with envy as we move further and further away from Agile.

"Alas Agile, we hardly knew ye."

On Tue Jan 06 2015 at 9:11:34 AM Ron Jeffries ronjeffries <at> acm.org [SCRUMDEVELOPMENT] <SCRUMDEVELOPMENT <at> yahoogroups.com> wrote:
 

Hennadii,


On Jan 4, 2015, at 11:48 AM, hennadii.omelchenko <at> gmail.com [SCRUMDEVELOPMENT] <SCRUMDEVELOPMENT <at> yahoogroups.com> wrote:

Monitoring Sprint Progress
At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress. (c) Scrum Guide (July, 2013)


without estimating tasks in hours. Any ideas? 


Yes, but first I’d like to challenge you to come up with two or three ways of knowing how much remains to be done without hours estimation.

Ron Jeffries
www.XProgramming.com
It's true hard work never killed anybody, but I figure, why take the chance?
-- Ronald Reagan






__._,_.___
Posted by: Cass Dalton <cassdalton73 <at> gmail.com>


To Post a message, send it to:   SCRUMDEVELOPMENT <at> eGroups.com
To Unsubscribe, send a blank message to: SCRUMDEVELOPMENT-unsubscribe <at> eGroups.com




__,_._,___
Picon

Re: Hours Estimation?



At least management left the third side of the triangle open, plenty of room for agility there.

On 06.01.2015 17:18:31, Bob Paige bobpaige <at> gmail.com [SCRUMDEVELOPMENT] <scrumdevelopment <at> yahoogroups.com> wrote:

 

I'm in a similar situation, where management's concern is "will we get everything done by the specified date."


I monitor these discussions with envy as we move further and further away from Agile.

"Alas Agile, we hardly knew ye."


__._,_.___
Posted by: =?utf-8?B?S3VydCBIw6R1c2xlcg==?= <kurt.haeusler <at> gmail.com>


To Post a message, send it to:   SCRUMDEVELOPMENT <at> eGroups.com
To Unsubscribe, send a blank message to: SCRUMDEVELOPMENT-unsubscribe <at> eGroups.com




__,_._,___
Picon

I just finished building my course "The Ultimate Guide to Building Your Backlog". Want a free chapter?



Happy New Year everyone.

I just finished my course, The Ultimate Guide to Building Your Backlog.

Check it out and sign up for the free chapter.

--
Tirrell Payton
619.663.4582
<at> tirrellpayton (twitter)
http://www.linkedin.com/in/tirrellpayton


__._,_.___
Posted by: Tirrell Payton <tpayton <at> payton-consulting.com>


To Post a message, send it to:   SCRUMDEVELOPMENT <at> eGroups.com
To Unsubscribe, send a blank message to: SCRUMDEVELOPMENT-unsubscribe <at> eGroups.com




__,_._,___
Picon

Posting delay [not a Scrum thing]



Apologies for the earlier double-post. I sent the message from the web UI but didn't see it appear. I waited 30 minutes. Then I re-sent from my email. A few minutes later the original post appeared.


Has anyone else experienced such delays from the web UI? I work at Yahoo! so have sent a query about this. Be good to know if it's a common problem, or just Yahoo! employees being given special treatment :)


Thanks for your help.

Tobias


PS Sending this post from web UI also. I shall time how long it takes to appear.



__._,_.___
Posted by: tobiasgmayer <at> gmail.com


To Post a message, send it to:   SCRUMDEVELOPMENT <at> eGroups.com
To Unsubscribe, send a blank message to: SCRUMDEVELOPMENT-unsubscribe <at> eGroups.com




__,_._,___
Picon

To: iipmpmpcert 0








http://bekadenetim.com/ggmk/haeckyxswsrikzfgrykgnglsjcmdvopjrovltz.kerqmfqoeyfmgjgtuebdxuqpgfipcmsdggvhb



































gunasundaram <at> yahoo.com

__._,_.___
Posted by: "gunasundaram" <gunasundaram <at> yahoo.com>


To Post a message, send it to:   SCRUMDEVELOPMENT <at> eGroups.com
To Unsubscribe, send a blank message to: SCRUMDEVELOPMENT-unsubscribe <at> eGroups.com




__,_._,___
Picon

Re-estimating PBIs



Hi,

My current team has been asked to re-estimate PBIs: at the end of the sprint to make sure PBIs turned out to be of the size they had been estimated initially, and at the beginning of the sprint for those PBIs that has been carried over from previous sprints as not done.

Therefore, my question i: whether re-estimation of PBIs is considered to be a good practice or bad, what pros and cons are intrinsic to this approach.

__._,_.___
Posted by: hennadii.omelchenko <at> gmail.com


To Post a message, send it to:   SCRUMDEVELOPMENT <at> eGroups.com
To Unsubscribe, send a blank message to: SCRUMDEVELOPMENT-unsubscribe <at> eGroups.com




__,_._,___
Picon

A Survey on Investigating the Applicability of Agile Practices



Hello, 
I am Srikar Madhira and I am conducting a survey to identify the applicability of agile practices in software organizations. This survey is a part of a Master Thesis conducted at Blekinge Institute of Technology. The research intends to identify the requirements/changes that are needed for implementing/adopting agile practices, the challenges faced during their implementation/adoption and the solutions for those challenges.
Kindly help me in my research by participating in this survey. Please participate in this survey and share your knowledge on agile to the body of software practitioners, help them in understanding agile practices in a better way. I request you to kindly forward the questionnaire link to members of your software groups and encourage them to participate as well. The Link to the survey is provided below


http://goo.gl/forms/UXrBzMXYWI


The survey is anonymous and your responses are kept strictly confidential.  Thank you very much in advance for your participation and time.


Regards,
Phani Srikara Sastry Madhira




__._,_.___
Posted by: srikar_m62008 <at> yahoo.in


To Post a message, send it to:   SCRUMDEVELOPMENT <at> eGroups.com
To Unsubscribe, send a blank message to: SCRUMDEVELOPMENT-unsubscribe <at> eGroups.com




__,_._,___
Picon

A recent survey



There is this other survey with interesting questions about challenges and strategies for successful agile methods adoption:
Take the ‘agile in non-agile environment’ survey | Agile Research Network


It reminded me that I have seen, time and again, individuals and teams facing enormous struggles to understand themselves and then change values, principles and practices in their own culture in order to ship better software. In my little window of reality around, many cases look hopeless. But, sometimes, there are individuals eager to think and behave differently and who are actually looking for hints to learn new professional principles and values. For those cases, I usually give the following answers to questions like these:

Question 1: Have you encountered challenges to improve software engineering principles, values and practices?

Part of my answer: many challenges, but —this could surprise you— many come from IT people (architects and developers, and their managers) who are unwilling —or unable— to unlearn and relearn.

Question 2: Which strategies would you suggest to face the challenge of shameful levels of unprofessionalism in software development projects?

Part of my answer: We already know: there is no silver bullet. But, one sensible strategy is to start a long journey of un-learning and re-learning the own computer software career. Get back to human basics: un-learning and re-learning basic philosophical and critical thinking, deep study of philosophy of science and engineering, and other basic stuff in the Humanities; for instance, anthropological research as a preparation for doing cultural critical analysis.


Do you found those answers reasonable?






__._,_.___
Posted by: marcodorantes <at> hotmail.com


To Post a message, send it to:   SCRUMDEVELOPMENT <at> eGroups.com
To Unsubscribe, send a blank message to: SCRUMDEVELOPMENT-unsubscribe <at> eGroups.com




__,_._,___
Picon

Agile in non-agile environment





The Agile Research Network (ARN) works closely with organisations to
understand their problems, make suggestions for how to improve practice,
undertake research and make research findings accessible to practitioners.

We are running a survey to investigate challenges and mitigation
strategies of using agile in non-agile environment.

By doing this survey you will not only share your experience but also
learn about other people’s challenges of adopting agile and some
mitigation strategies used to tackle these challenges.

Please share your experience and take our agile in non-agile environment
challenges survey at

http://agileresearchnetwork.or g/take-the-agile-in-non-agile- environment-survey/

Best Regards,
Dina Salah




__._,_.___
Posted by: dina salah <dina_salah_eldin <at> yahoo.com>


To Post a message, send it to:   SCRUMDEVELOPMENT <at> eGroups.com
To Unsubscribe, send a blank message to: SCRUMDEVELOPMENT-unsubscribe <at> eGroups.com




__,_._,___
Picon

Re: Digest Number 5587





On Wed Nov 12 2014 at 07:19:39 <SCRUMDEVELOPMENT <at> yahoogroups.com> wrote:

2 Messages

Digest #5587
1a
LeSS site - less.works by craig.larman
1b
Re: LeSS site - less.works by "Michael James" michaeljamesseattle

Messages

Tue Nov 11, 2014 10:14 am (PST) . Posted by:

craig.larman

Hi,

We’ve received many requests for more information and training for Large-Scale Scrum (LeSS) and so​ decided​ to provide more support by​ ​sharing​ ​many resources online, and provide training.

Today, we’re ​delighted to announce the LeSS site at http://less.works and with it a training program​. Both will expand.

The site content is based on our previous books: Scaling Lean & Agile Development http://www.amazon.com/Scaling-Lean-Agile-Development-Organizational/dp/0321480961/ref=sr_1_1?ie=UTF8&qid=1415729593&sr=8-1&keywords=scaling+lean+larman and Practices for Scaling Lean and Agile Development http://www.amazon.com/Practices-Scaling-Lean-Agile-Development-ebook/dp/B0046EDOYU/ref=sr_1_2?ie=UTF8&qid=1415729593&sr=8-2&keywords=scaling+lean+larman and the upcoming book “Large-Scale Scrum (LeSS)”

We hope the content will be useful for you​. ​Please let us know any feedback, via the site contacts.

Regards, Craig Larman and Bas Vodde

Tue Nov 11, 2014 10:57 am (PST) . Posted by:

"Michael James" michaeljamesseattle

Craig, I’m relieved your guidance on this is finally available in a digestable manner at http://less.works . I enjoyed your Scaling Lean & Agile Development books, but they are thick and I’ve found clients resisted reading such large books.

—mj
(Michael)

> On Nov 11, 2014, at 1:14 PM, craig <at> craiglarman.com [SCRUMDEVELOPMENT] <SCRUMDEVELOPMENT <at> yahoogroups.com> wrote:
>
> Hi,
>
> We’ve received many requests for more information and training for Large-Scale Scrum (LeSS) and so​ decided​ to provide more support by​ ​sharing​ ​many resources online, and provide training.
>
> Today, we’re ​delighted to announce the LeSS site at http://less.works and with it a training program​. Both will expand.
>
> The site content is based on our previous books: Scaling Lean & Agile Development and Practices for Scaling Lean and Agile Development and the upcoming book “Large-Scale Scrum (LeSS)”
>
> We hope the content will be useful for you​. ​Please let us know any feedback, via the site contacts.
>
> Regards, Craig Larman and Bas Vodde
>
>
>
>
>

To Post a message, send it to:   SCRUMDEVELOPMENT <at> eGroups.com
To Unsubscribe, send a blank message to: SCRUMDEVELOPMENT-unsubscribe <at> eGroups.com


__._,_.___
Posted by: Julio Cesar Fausto <jcfausto <at> gmail.com>


To Post a message, send it to:   SCRUMDEVELOPMENT <at> eGroups.com
To Unsubscribe, send a blank message to: SCRUMDEVELOPMENT-unsubscribe <at> eGroups.com




__,_._,___

Gmane