Skip to main content

Home/ Agilesparks/ Group items tagged delivery

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Yuval Yeret

Alistair.Cockburn.us | Are iterations hazardous to your project? - 0 views

alistair.cockburn.us/s+hazardous+to+your+project%3f

shared by Yuval Yeret on 20 Jun 09 - Cached
  • Simply using iterations, user stories and velocity doesn’t mean your project is agile – or on the way to success.
  • why “iterations” may be hazardous to your project: ‘’Danger grows when the results of the iteration are not directly linked to delivering the product to the end user.’’ Without that linkage, iteration results hang in the air
  • What gets in the way is that the project is set up as a pipeline, with programming put somewhere in the middle of the pipeline. In this project setup, there is really nothing the programmers can do to show how their work connects to deliveries, because there are work stations before and after theirs. All they can report is that “some new code is integrated into the code base.” They are doing incremental development but not agile development.
  • ...6 more annotations...
  • magine a project team of between fifteen and four hundred people. There are user representatives, analysts, programmers, database designers, and testers, arranged in a pipeline. The user analysts talk to the users, and then to the analysts, who write down user stories. The analysts write lots of notes on each user story, since it will be a full iteration or two before any programmer will pick up the user story. The notes are between one and ten pages long. Eventually, a programmer picks up a user story along with the supplemental details, code them up in an iteration, integrate them into the growing code base, and mark their velocity. In the same or a later iteration the database designers do the same. Eventually the integration test team comes along, runs tests on the whole thing, and feeds bug reports back into the programmers’ work queues. The users or project sponsors may see the outcome every few months if they are lucky.
  • The repair is simple: connect every activity to a release or delivery to real users (delivering to even one real user makes a difference). Evaluate the team’s work based on how often they deliver to real users and how long it takes a new requirement to reach the users. Replace the fuss around iterations with fuss around deliveries.
  • Break the pipeline, lengthen the iterations, lose the machismo, deliver the project.
  • here is no mechanism in the standard agile language that warns about this loss of touch. The currently standard language consists of ‘’iterations, user stories, ‘’and’’ velocity’’. By a perverse relationship between them, it is possible to equally shrink iteration length and story size, with velocity scaling accordingly. Thus, a team can feel as though it is become more agile, when in reality it is simply becoming more cut off from its user base and the feedback it needs to succeed.
  • Collocate the requirements gatherer, the database designer, the programmer, the tester. Lengthen the iteration period to one month. Give the requirements gatherer a week’s head start on the features coming up, but otherwise arrange that all of them are working on the same feature set in the same month.
  • As an afterthought, if your new iteration length is a month, you can still run one-week planning windows to make sure you don’t get off track during the month.
Yuval Yeret

10 Questions to Ask Your Customer for Written or Video Testimonials - 0 views

www.sensiblemarketing.com/...-written-or-video-testimonials

testimonials customer questions

shared by Yuval Yeret on 14 Mar 16 - No Cached
  • How did you get involved with our company? What was the reason that you chose us? 
  • Tell me what your experience has been with our products/services? (Ask for the customer's experience and wisdom.)
  • Can you think of a word or phrase that best describes your relationship with us? Why that particular word or phrase?
  • ...2 more annotations...
  • How has working with us changed the way your company does business?
  • Why would you recommend us to someone else? (This is the key part of the testimonial.) If someone called you and said "Why should I do business with XYZ company", what would you tell them?
  • Yuval Yeret on 14 Mar 16
     
    "Questions to Ask Your Customer for a Written or Video Testimonial Give me a one-minute history of your career (or your success, or your business). (Get them relaxed and comfortable. Everyone loves talking about themselves.) How did you get involved with our company? What was the reason that you chose us?  Was price more important that delivery, service, and quality? (This question gets to the value of the products/services you provide.) Tell me what your experience has been with our products/services? (Ask for the customer's experience and wisdom.) Can you think of a word or phrase that best describes your relationship with us? Why that particular word or phrase? How has working with us changed the way your company does business? Have you had our competitors knock on your door? If so, what did you tell them? Why would you recommend us to someone else? (This is the key part of the testimonial.) If someone called you and said "Why should I do business with XYZ company", what would you tell them?"
Yuval Yeret

DevOps Manifesto - 0 views

sites.google.com/...devops-manifesto

devops devopsdays

shared by Yuval Yeret on 15 Sep 14 - No Cached
  • About creating visibility between dev and ops
  • Cross-functional teams over organizational silos
  • Products not projects
  • ...5 more annotations...
  • Automation over documentation (and more automation... and more...)
  • creating self-service infrastructure for teams
  • Cross-functional teams over organizational silos
  • Creating products that are owned by the delivery team
  • Delivery teams run software products - not projects - that run from inception to retirement
Yuval Yeret

LSSC12: The Improvement Journey - Yuval Yeret on Vimeo - 0 views

vimeo.com/43222643

kanban conference talk vimeo improvement journey yuvalyeret video Continuous Improvement improvement-list agile-change-management-list

shared by Yuval Yeret on 22 Mar 14 - No Cached
  • Yuval Yeret on 22 Mar 14
     
    "This presentation was given at the Lean Software and Systems Conference 2012 (LSSC12). Lean/Agile is not just about delivering early and often, it is even more importantly about continuously adapting the way we work towards an improved capability of delivery. Yet how many of us have worked in a continuously improving organization? How many of us have seen one in real life? It's hard to keep management interested in Improvement for very long, making Continuous Improvement a holy grail of sorts. As Lean/Kanban practitioners we believe the only sustainable way to improve is via evolutionary emerging change. But if we the organization is not interested in pursuing it, we have a big problem. Through some challenging situations from real client work we will see a few patterns that fail and a few patterns that show more promise for energizing improvement. We will also look at improvement pace and how to apply kanban approaches to make the improvement more sustainable. We will also explore some local cultural aspects that might affect the drive (or lack of) towards improvement, and how to deal with them, with some interesting insights about the Israeli culture…"
Yuval Yeret

Do It Yourself Agile: Scrum and Kanban - Like Chocolate and Peanutbutter - 0 views

damonpoole.blogspot.com/...kanban-like-chocolate-and.html

agile kanban retrospective scrum

shared by Yuval Yeret on 18 Sep 09 - Cached
  • When doing Kanban, you still need to do the equivalent of planning, assignment, estimation, retrospectives, delivery, etc. In Kanban, all of these activities are decoupled from each other whereas in Scrum they are all coupled to the iteration boundary. How can this be applied to Scrum? Consider retrospectives. If you are just starting with Scrum, you probably have an iteration length of 1 month (or four weeks). From that it follows that you will have a retrospective once per month. If you eventually end up with an iteration length of 1 week, then it follows that you will have a retrospective every week. But this actually seems like the wrong way to set the cadence of retrospectives. Wouldn’t it be better to have the cadence of retrospectives meet the need for them? If it eventually makes sense to do a retrospective every week, doesn’t it make sense to get the benefit of them on a weekly basis when you are just starting Scrum?
Yuval Yeret

James Shore: Value Velocity: A Better Productivity Metric? - 0 views

jamesshore.com/...etter-Productivity-Metric.html

agile roi productivity

shared by Yuval Yeret on 24 Jun 09 - Cached
  • *Please note that I'm specifically talking about productivity. Velocity is a great tool for estimating and planning and I'm not trying to change that. It's just not a good measure of productivity.
  • rather than asking your business experts to measure business value after delivery (difficult!), have them estimate it beforehand. Every story (or feature--keep reading) gets an estimate before it's scheduled. At the end of each iteration, add up the value estimates for the stories you completed in that iteration. This is your "value velocity."
  • And rather than reflecting the hours programmers work, as cost velocity does, value velocity actually reflects productivity. Remember, productivity equals output/time. Value estimates are a much better indication of output than cost estimates are.
  • ...7 more annotations...
  • It's like traditional velocity, except it's based on your customers' estimates of value rather than your programmers' estimates of cost.
  • stories don't always have value on their own.
  • Although value velocity isn't perfect, a team with consistent value estimates would be able to graph their value velocity over time and see how their productivity changes. This would allow them to experiment with new techniques ("Let's switch pairs every 90 minutes! Now once a week!") and see how they affect productivity. If balanced with actual measures of value and some sort of defect counting, this could be a powerful tool.
  • just estimate and score features rather than stories.
  • Another option would be to pro-rate each feature's estimate across all of the stories required to deliver it.
  • some types of stories don't provide value in the traditional way. What's the value of fixing a nasty crash bug?
  • Third, value velocity is just as vulnerable to gaming as cost velocity is... perhaps more so. I'm not sure how to prevent this.
1 - 20 of 27 Next ›
Showing 20▼ items per page