Skip to main content

Home/ Agilesparks/ Group items tagged starts

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Yuval Yeret

Lean-Agile Software Development: The Kanban Kick-start Field Guide now available! - 0 views

leanagileprojects.blogspot.se/...ick-start-field-guide-now.html

101 kanban twitterfavs kanban-101-list

shared by Yuval Yeret on 23 Mar 14 - No Cached
  • Yuval Yeret on 23 Mar 14
     
    The Kanban Kick-start Field Guide is now available! Concentrating experience from kick-starting 50+ teams #kanban http://t.co/B4Pf3s96OZ
Yuval Yeret

Alistair.Cockburn.us | Agile contracts - 1 views

alistair.cockburn.us/Agile+contracts

Agile Contracts agile-contracts-list

shared by Yuval Yeret on 23 Mar 14 - Cached
  • Venture-capital financing model This can be used with any of the above contract forms. In this model, the sponsor gives a round of financing for a certain amount of work, and the contracted company must produce results in order to get more funding. The sponsor can cut their losses at any time if they are not getting the results they need. They can presumably alter the terms of the contract after each work period. The result of a work period need not be working software; it could be a paper study, or a requirements document, or anything the sponsor selects. The venture-capital finance model works well with agile providers, since the agile provider is used to delivering useful, working software early and regularly. I find it an odd irony that the venture capital financiers running start-ups that I have encountered don’t take advantage of their own model to the extent agile teams do. The venture financiers let the evaluation markers occur too far apart in time. If they attached funding to monthly releases, that would oblige the start-up team to think through what it really can accomplish each month. The monthly progress would give the financiers a better sense of the start-up company’s real progress.
  • Venture-capital financing model This can be used with any of the above contract forms. In this model, the sponsor gives a round of financing for a certain amount of work, and the contracted company must produce results in order to get more funding. The sponsor can cut their losses at any time if they are not getting the results they need. They can presumably alter the terms of the contract after each work period. The result of a work period need not be working software; it could be a paper study, or a requirements document, or anything the sponsor selects. The venture-capital finance model works well with agile providers, since the agile provider is used to delivering useful, working software early and regularly. I find it an odd irony that the venture capital financiers running start-ups that I have encountered don’t take advantage of their own model to the extent agile teams do. The venture financiers let the evaluation markers occur too far apart in time. If they attached funding to monthly releases, that would oblige the start-up team to think through what it really can accomplish each month. The monthly progress would give the financiers a better sense of the start-up company’s real progress.
  • Bob Martin’s idea Bob Martin of Object Mentor posted an interesting variant to get around this problem: a base fee per story point, plus a lower-than-usual (close-to or below cost) fee per hour. This biases the contracted company’s to deliver early, but gives them some protection in case work proceeds slower than expected. Bob Martin described it this way:”[A]gree to pay a certain amount for each point completed, plus a certain amount for each hour worked. For example, let’s say you’ve got a project of 1000 points. Let’s also say that a team of four has established an estimated velocity of 50 points per week. This looks like about an 80 man-week job. At $100/hour this would be a $320,000 job. So lets reduce the hourly rate to $30/hour, and ask the customer for $224 per point. This sets up a very interesting dynamic. If the job really does take 80 man-weeks, then it will cost the same. If it takes 100 man-weeks then it will cost $344,000. If it takes 70 man-weeks it will cost $308,000. Notice that this is a small difference for a significant amount of time. Notice also that you, as developer feel strong motivation to be done early, since that increases your true hourly rate.” I have not seen that model in action myself, but several people have written in recommending it.
  • ...2 more annotations...
  • Bob Martin’s idea Bob Martin of Object Mentor posted an interesting variant to get around this problem: a base fee per story point, plus a lower-than-usual (close-to or below cost) fee per hour. This biases the contracted company’s to deliver early, but gives them some protection in case work proceeds slower than expected. Bob Martin described it this way:”[A]gree to pay a certain amount for each point completed, plus a certain amount for each hour worked. For example, let’s say you’ve got a project of 1000 points. Let’s also say that a team of four has established an estimated velocity of 50 points per week. This looks like about an 80 man-week job. At $100/hour this would be a $320,000 job. So lets reduce the hourly rate to $30/hour, and ask the customer for $224 per point. This sets up a very interesting dynamic. If the job really does take 80 man-weeks, then it will cost the same. If it takes 100 man-weeks then it will cost $344,000. If it takes 70 man-weeks it will cost $308,000. Notice that this is a small difference for a significant amount of time. Notice also that you, as developer feel strong motivation to be done early, since that increases your true hourly rate.” I have not seen that model in action myself, but several people have written in recommending it.
  • Norwegian PS 2000 Standard contract http://dataforeningen.no/?module=Articles;action=ArticleFolder.publicOpenFolder;ID=1044 “The main feature of the contract for software development is that it provides mechanisms for establishing a common understanding between customer and the developer and a flexible iterative model for development suited for an environment of uncertainties and risks.” ...” Stage by stage, iterative development model securing ability to benefit from increasing understanding of the requirements and challenges Close co-operation between supplier and customer Incentives and sanctions in combination with target pricing Procedures for conflict resolution with an expert as a mediator ” You need to order it (it costs several thousand Norwegian kronor):
Yuval Yeret

Larman's Laws of Organizational Behavior - Craig Larman - 0 views

www.craiglarman.com/...index.php

agile-change-management-list

shared by Yuval Yeret on 08 Jul 14 - No Cached
  • Yuval Yeret on 08 Jul 14
     
    "Larman's Laws of Organizational Behavior After decades of observation and organizational consulting, here are Larman's Laws of Organizational Behavior. These are observations rather than laws to follow ;) 1. Organizations are implicitly optimized to avoid changing the status quo middle- and first-level manager and "specialist" positions & power structures. 2. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo. 3. As a corollary to (1), any change initiative will be derided as "purist", "theoretical", and "needing pragmatic customization for local concerns" -- which deflects from addressing weaknesses and manager/specialist status quo. 4. Culture follows structure. i.e., if you want to really change culture, you have to start with changing structure, because culture does not really change otherwise. and that's why deep systems of thought such as organizational learning are not very sticky or impactful by themselves, and why systems such as scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture. i discovered that john seddon also observed this: "Attempting to change an organization's culture is a folly, it always fails. Peoples' behavior (the culture) is a product of the system; when you change the system peoples' behavior changes." "
Yuval Yeret

Challenging Why (not if) Scrum Fails | NetObjectives - 0 views

www.netobjectives.com/...questioning-why-scrum-fails

shared by Yuval Yeret on 22 May 09 - Cached
  • I do believe for Scrum to work beyond the team you need more than Scrum
  • what to add to Scrum making it more effective when it won't readily work
  • lack of team agility is not always the major impediment to Enterprise Agility
  • ...12 more annotations...
  • While starting at the team level with Scrum is often good, you often need to start with the product management team - that is, where product enhancements to be worked on are selected
  • Even when Scrum works at the team level, organizations very often report little impact to the bottom line.  While this is better than nothing (if the teams are happier, that's good), it usually doesn't justify a huge investment
  • in many contexts in which Scrum does not work readily, Scrum has no power to improve the context in which it is in.  In other words, the impediments that one must fix are often outside of the scope of what Scrum helps you do.
  • These impediments are often not even seen or if they are, are often viewed as "just the way it is."
  • certain Scrum attitudes often makes things worse
  • Scrum does little to let management to know how the team works or what impact management decisions have on the team
  • There is almost a religious zeal that Scrum tells you little of what to do
  • While SoS works well for certain types of work, it does not work well when the different teams have different motivations. 
  • the high failure rate is due to the fact that Scrum works in certain contexts but has little ability to change the contexts in which it doesn't work wel
  • One needs to pay attention to where to start as well as see how to change the context.  Separating the team from management doesn't help.  Focusing on only the team part of the value stream - giving little guidance both up and downstream of the team also doesn't help.  Lean provides guidance here (meaning Scrum with the aid of Lean could provide insights),
  • look into using Lean as a context for any improvement in your software development organization
  • While Scrum may be an appropriate choice in many circumstances, other methods may be better (e.g., Kanban Software Development).  Scrum's rapid ascension probably has more to do with its success in the places it easily fits.  Now that it is past the early adopter phase, we may see it having even a harder time as people attempt to scale it.
Yuval Yeret

Creating an Agile Culture to Drive Organizational Change - 1 views

www.borland.com/...creating-an-agile-culture.html

agile enterprise adoption culture

shared by Yuval Yeret on 15 May 09 - Cached
  • It is critical that everyone has the same understanding of, and commitment to, the desired outcome: a business that is reliable through predictable technology processes that deliver business agility. To do this, there needs to be a management commitment to develop a focused, on-going practice around the pursuit of organizational maturity. As part of this, gaps in skills and capabilities should be identified and positive action – training, coaching, process improvement and tools deployment – taken in order to close the gap
  • the work force needs to understand the business drivers for Agility. They need to be challenged to improve their quality, improve their cycle times, to improve the frequency of releases and the value they deliver to the customer. They need to know how these things fit within the bigger picture and why improvement is their responsibility.
  • To change a culture it's important to recognize that every knowledge worker makes decisions and takes actions that affect the performance of the business. The culture in the organization is the reflection of those decisions and actions.
  • ...14 more annotations...
  • all the people understand and internalize the concepts and ideals behind the Agile movement
  • translated into concepts that can be widely applied to the many day-to-day decisions each of them will make
  • internalize and live three principles: making progress with imperfect information; existing in a high trust, high social capital culture; and shortening cycle times. These ideas need to be infused into the workforce at every opportunity.
  • it should spread virally. It can start with just one manager, who educates his immediate direct reports on the concepts and then takes the time to reflect and show how each decision is aligned the principles
  • work-in-progress as a liability rather than an asset.
  • . Every member of the team should be educated to understand it, and to be capable of demonstrating how their decisions and actions are concomitant with it. The Decision Filter is
  • The Agile Decision Filter
  • Delivering quickly can provide immediate value while delay can result in obviated functionality of little value or missing a more lucrative opportunity while completing existing work-in-progress
  • Are we making progress with imperfect information? Or are we trying to be perfect before we start? Does this decision add or maintain trust in our organization and with our partners? Or does it remove trust and breed fear? Are we treating work-in-progress as it if were a liability? Or are we treating it like an asset?
  • the team can start to modify their practices one decision at a time and drive towards a goal of business agility
  • The "transition" to Agile will happen slowly, and supporting the change will require training, coaching and tools – but change will be real and long-lasting.
  • By changing your culture using the simple principles captured in The Agile Decision Filter, teams will adopt Agile. Give it a little time and magic will happen. They will voluntarily change their behaviors and adopt Agile practices. They will behave in a fashion aligned with the principles and values behind The Agile Manifesto. They will not resist because they had a say in the changes, which are tailored specifically to their environment and their needs.
  • this approach may seem less prescriptive and straightforward than an "Agile Change Initiative" project plan. And yes, taking on a management-led Agile Transition Initiative looks faster and cheaper,
  • However, it is all wishful thinking, and the only way to get the payoff is to invest the time and show the courage to lead true Agile change. True Agile change requires you to change the culture. To change the culture, teach all your people how to use the Agile Decision Filter and hold them accountable for every decision they make.
Yuval Yeret

James Shore: The Art of Agile Development: Incremental Design and Architecture - 1 views

www.jamesshore.com/...incremental_design.html

eng-practices-list james shore evolutionary design agilearchitecture

shared by Yuval Yeret on 10 Dec 14 - No Cached
  • when you first create a design element—whether it's a new method, a new class, or a new architecture—be completely specific. Create a simple design that solves only the problem you face at the moment, no matter how easy it may seem to solve more general problems
  • Waiting to create abstractions will enable you to create designs that are simple and powerful.
  • The second time you work with a design element, modify the design to make it more general—but only general enough to solve the two problems it needs to solve. Next, review the design and make improvements. Simplify and clarify the code. The third time you work with a design element, generalize it further—but again, just enough to solve the three problems at hand. A small tweak to the design is usually enough. It will be pretty general at this point. Again, review the design, simplify, and clarify. Continue this pattern. By the fourth or fifth time you work with a design element—be it a method, a class, or something bigger—you'll typically find that its abstraction is perfect for your needs. Best of all, because you allowed practical needs to drive your design, it will be simple yet powerful.
  • ...12 more annotations...
  • This is difficult! Experienced programmers think in abstractions. In fact, the ability to think in abstractions is often a sign of a good programmer. Coding for one specific scenario will seem strange, even unprofessional.
  • Continuous Design Incremental design initially creates every design element—method, class, namespace, or even architecture—to solve a specific problem. Additional customer requests guide the incremental evolution of the design. This requires continuous attention to the design, albeit at different time-scales. Methods evolve in minutes; architectures evolve over months. No matter what level of design you're looking at, the design tends to improve in bursts. Typically, you'll implement code into the existing design for several cycles, making minor changes as you go. Then something will give you an idea for a new design approach, requiring a series of refactorings to support it. [Evans] calls this a breakthrough (see Figure). Breakthroughs happen at all levels of the design, from methods to architectures.
  • Don't let design discussions turn into long, drawn-out disagreements. Follow the ten-minute rule: if you disagree on a design direction for ten minutes, try one and see how it works in practice. If you have a particularly strong disagreement, split up and try both as spike solutions. Nothing clarifies a design issue like working code.
  • Risk-Driven Architecture Architecture may seem too essential not to design up front. Some problems do seem too expensive to solve incrementally, but I've found that nearly everything is easy to change if you eliminate duplication and embrace simplicity. Common thought is that distributed processing, persistence, internationalization, security, and transaction structure are so complex that you must consider them from the start of your project. I disagree; I've dealt with all of them incrementally [Shore 2004a]. Two issues that remain difficult to change are choice of programming language and platform. I wouldn't want to make those decisions incrementally!
    • Yuval Yeret
      Yuval Yeret on 12 Jan 15
       
      Possible exercise - Try to come up with various things that are risky to YAGNI. And then order them according to level of risk. Use the examples here to seed the list
  • Limit your efforts to improving your existing design
  • To apply risk-driven architecture, consider what it is about your design that concerns you and eliminate duplication around those concepts
  • Your power lies in your ability to chooose which refactorings to work on. Although it would be inappropriate to implement features your customers haven't asked for, you can direct your refactoring efforts towards reducing risk. Anything that improves the current design is okay—so choose improvements that also reduce future risk.
  • design is so important in XP that we do it all the time
  • Don't try to use incremental design without a commitment to continuous daily improvement (in XP terms, merciless refactoring.) This requires self-discipline and a strong desire for high-quality code from at least one team member. Because nobody can do that all the time, pair programming, collective code ownership, energized work, and slack are important support mechanisms.
  • Test-driven development is also important for incremental design. Its explicit refactoring step, repeated every few minutes, gives pairs continual opportunities to stop and make design improvements. Pair programming helps in this area, too, by making sure that half of the team's programmers—as navigators—always have an opportunity to consider design improvements.
  • Alternatives If you are uncomfortable with XP's approach to incremental design, you can hedge your bets by combining it with up-front design. Start with an up-front design stage and then commit completely to XP-style incremental design. Although it will delay the start of your first iteration (and may require some up-front requirements work, too), this approach has the advantage of providing a safety net without incurring too much risk.
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

Tailor your Message To Gain Support for your Agile Initiative | Enabling Agility - 0 views

www.enagility.com/r-your-message-to-gain-support

tailor agility agile adoption transformation

shared by Yuval Yeret on 21 May 09 - Cached
  • 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.
  • f they don’t see a meaningful update from us, at least once a quarter, we’re going to get kicked out of the game.  We’ve all acknowledged that as we’ve gotten bigger, our processes have become more cumbersome and now is the time to do something about it.  Agile will give us the ability to regain that rapid pace of delivering innovations to market that we were know for in our early days.”
  • ...21 more annotations...
  • ur last two releases have looked like me-too updates, where we are just barely keeping up with our competitors
  • We’ve been losing market share
  • If you can refer to a specific business issue and show the linkage, you are much more likely to get a receptive audience.  Here’s an example.
  • The CFO, developer and QA manager have different roles in the organization and their needs are different.  If you want to enlist their support, be sure you know who you are talking to and what they value.
  • Use Focused Messages for Key Individuals or Groups
  • certain volume of people who are enrolled in the idea of Agile before you’ll see adoption start to accelerate,
  • People have specific needs in their role and they want to understand how Agile will affect and benefit them directly.  
  • Developers, on the other hand, probably wants to know if they will have interesting work, the opportunity to learn new things and the ability to make an impact on the company’s products.
  • a QA manager is probably interested in hearing how Agile helps enrich the QA profession.
  • The focus isn’t on Agile, its on business, as it should be.
  • The easiest way to find out what interests someone is to ask them.  When you meet, leave plenty of time for talk.  Motoring through a well-rehearsed Agile presentation usually doesn’t work.  A lot of times I’ll have slides with me, but they are a backdrop for the conversation.  I’ll refer to slides when it helps move the conversation along, but otherwise don’t use them.  You might want to forget slides altogether and just draw things on a whiteboard as necessary.  This technique is particularly useful with an individual or a small group.  
  • Take it One Step Further: Collect Data to Gain Insight
  • you’ll be most effective tailoring your message if you invest some time conducting data through a series of structured interviews. 
  • First, you’ll need a small set of questions prepared for the interviews.  Here are some examples. What is working with our current methodology? What’s not working with our current methodology? How do you think Agile would help our organization? What concerns do you have about Agile?
  • Interview a wide range of people: developers, testers, business analysts, managers, product managers, senior management, project managers and someone from finance. 
  • When you conduct the interviews, it is good to have one interviewer who has the primary responsibility for talking and the other person who has the primary job of taking notes.  You can switch off roles each interview so no one person gets stuck in either role.  Here’s how I typically start off.  
  • stories that people tell about the organization and make sure you write them down
  • I put all of the information we’d gathered into a mind-mapping program (Mindjet) and grouped like things together.
  • Make sure you keep interesting stories intact.  Specifics will help you make your cases
  • When there’s numerical data, people engage with a presentation in an entirely different way than they do when there are stories.  I find stories more effective, but do what works for you.
  • As an Agile evangelist, you job is to get Agile deployed effectively.  Along the way there are many people will be willing to go out of their way to help if you effectively speak to their interests and concerns.
Yuval Yeret

Kanban development oversimplified: a simple explanation of how Kanban adds to the ever-... - 0 views

agileproductdesign.com/...kanban_over_simplified.html

lean kanban

shared by Yuval Yeret on 03 Jun 09 - Cached
  • 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...
  • Managing little stories forces us to keep better track of how they fit together. Product owners are often asked to break down stories to a level where a single story becomes meaningless. To keep track of what’s meaningful to them and other stakeholders, they often need to keep track of bigger items such as the features of the product and how many stories contribute to building up that feature.
  • The result of these herniated time-box activities is a cycle that’s actually 3-4 times longer than our time-box. To get work done, we’ll use a time-box to elaborate stories, one to develop them, another to more thoroughly test them, and if there are bugs, possibly another to fix them.
  • During an ideal Agile time-box we’ll have frequent discussions between developers, testers, and those on a product owner team — like business analysts, user experience people, and business people. We’ll do this to understand what we need to build and describe what we’ll do to validate the story was really done. When time-boxes are short, there’s less time for this conversation. It’s common to move many of the conversations to detail the story and describe acceptance to the time-box before so we can be ready to really get moving with development when the time-box starts.
  • It’s difficult to fit thorough validation of the story into a short time-box as well. So, often testing slips into the time-box after. Which leaves the nasty problem of what to do with bugs� which often get piped into a subsequent time-box.
  • Anyone who’s attended an Agile planning meeting knows they can often last about an hour longer than you can stand it
  • As time-boxes shrink those on the product owner team and testers find themselves in a constant mode of getting ready for a next time-box and evaluating past time-boxes
  • work long hours, attend lots of meetings, and seem to have less time to be available to help developers with the current time-box. Since their focus is on a future or past time-box, questions about this time-box seem like interruptions. Collaboration decreases and tensions increase. Their work load is heavy, bumpy, not smooth or even.
  • Kanban cards are used to limit the amount of inventory the factory builds. It doesn’t do the Toyota factory any good to build doors faster then they can assemble cars. It just wastes money on excess doors, and parts of doors. Excess work in progress is considered to be waste in Lean manufacturing. (It’s probably waste in non-Lean manufacturing too.) In the above completely made up example, you’ll never have more than 15 finished doors hanging around. (Mudha is Japanese for waste. Learn it to impress your Lean friends.)
  • “Kan” means visual, and “ban” means card or board.
  • Kanban thinking in software development attempts to do a similar thing. We want to limit unnecessary work in progress to be no higher than it needs to be to match the throughput of the team.
  • In Kanban development: time-boxed development is out stories are larger and fewer estimation is optional or out completely velocity is replaced by cycle time
  • Exactly what’s left of Agile if we get rid of time-boxes, change the meaning of stories, and stop measuring velocity. And, exactly what do car doors and Kanban cards have to do with software development? Don’t get hung up on process. Remember, agile development isn’t a process.
  • You might have a column where business analysts spend time tracking down technical details that developers need to understand to write code.
  • These columns aren’t set. You should discuss with your team the phases that stories go through to be completed. Some organization may use columns for writing documentation, or preparing customer service people to support the feature in production.
  • The top is used for stories currently in progress in that phase. The bottom is the buffer. When work for that phase of the story is completed, it moves from “in progress” to the “buffer” where it’ll wait to be pulled into the next phase.
  • When we set limits for work in progress, we’ll set a total number for the process step that includes both “in process” and the “finished buffer” for that process step.
  • Stories must be minimal marketable features
  • To be marketable the feature needs to be large enough to be useful — probably larger than the teeny stories that take a couple days to build and seem to be best practice in Agile development today. A MMF may take weeks to build. But the important thing isn’t how long it takes to build, but that it be understandable and valuable to those who’ll receive it. To identify a MMF some folks ask the question “Would I announce it in my company’s product blog?” If it’s too tiny to mention, then it’s not a MMF.
  • To be lean, we’ll limit the number of stories we allow onto the board. A common formula is to add up all the members of the team in all roles and divide by two. All roles includes developers, analysts, user interfaced designers, testers, deployment people — anyone immediately responsible for getting features to market. For example, if team members total 20, we might limit the number of MMF-style stories on the board to 10.
  • Today developers have finished a story, and s they walk to the Kanban board to move it out of development, they notice their single buffer slot is full — and the “testing in progress” column is filled to its limit. What now? The developers talk to the testers. “We’re really struggling to keep up here. It’ll be till tomorrow morning before we can get some of these stories moved out.” “Hmm�” says a developer “Can we help test?” “Of course you can!” says the tester. “With your help we can get these cleared out by the end of the day.“ The tester grins “I just don’t want you validating a story you implemented.”
  • For the limits of the story process steps, the limit is often half the number of people that can perform the work for that phase of development. For instance if you have 6 developers, you might limit the development in progress column to 3. Now, this will force developers to work together on stories. I do find in practice that this may not work out for all teams — so I often see limits that equal the number of developers (or those that can perform the process step) or often 1.5 * the number of people in a role. Of course if you do this, it’ll raise the overall work in progress — and as you might expect, items will take longer to finish.
  • When a column in a Kanban board is full, we know that group is at capacity. We also know that if this keeps happening that that process step is likely where a bottleneck is.
  • If you’ve ever waited in line for the Pirates of the Caribbean in Disneyland you might remember signs along the way that say “Your wait time from here is 30 minutes” — something like that. Now you can post your own wait times on your Kanban board. At the bottom of your story queue post the average cycle time with wait time. It’ll say something like “Your wait time for a story here is approximately 18 days.” At the top of the queue post the average working cycle time. It might say “your wait time from here is 14 days.”
  • When you place focus on how quickly you can get functionality done, and have the ability to measure just that, then the estimates don’t much matter. In fact, many using a Kanban approach have simply stopped estimating at all. Yes story sizes vary, but being able to give a wait time plus or minus a few days is sufficient for many organizations’ concerns.
  • But, since there’s no development time-box in Kanban development, we’ll measure story-by-story how long they took to complete — the “cycle time” of the story.
  • Some do still estimate stories. Then use those estimates in conjunction with cycle time. Using a spreadsheet we can calculate the average cycle time for stories with a given estimate. If you do this, consider placing a handy chart next to your Kanban board showing estimate in one column, and wait times in adjacent columns. With this you’re answering the real question stakeholders are asking for when they get estimates: “when am I going to see this functionality in the software?”
  • If your stakeholders are like mine, they don’t want to know when they’re going to get this functionality, the want to know when they’re going to get all this functionality. I find that if I place stories into a spreadsheet with start and end dates, and calculate cycle time, if I select an arbitrary time period — say a two or three week time period — I can see how many stories where completed during this time period. For instance I might see the team finished 22 stories in 3 weeks — that’s about 7.3 stories per week. Given a backlog of 100 stories I can reasonably infer that it’ll take between 13 and 14 weeks (100/7.3). That’s yesterday’s weather for Kanban — at least the way I calculate it.
  • If I know that during three week time period there where 15 working days and that 5 developers worked the entire time, that’s 75 developer days. Knowing that lets me calculate the average number of developer days per story: 3.4 (75/22) — Which is darn close to pi — which makes me believe it has to be right. ;-) This number, 3.4, is what XP practitioners referred to as load factor.
  • Evaluation cycles, not development time-boxes
  • The only difference is the cycles aren’t used to plan and commit to stories any longer.
  • The daily standup or daily scrum meeting occurs as normal, but now it occurs in front of the Kanban board. Instead of the regular meeting ritual of checking in with each person to find out what they worked on yesterday and will work on today, the discussion revolves around the Kanban board and what will likely move on and off the board today, where “traffic” seems the heaviest, and what we could do to clear bottlenecks.
  • Reflect every few weeks
  • Lean practices help teams increase throughput. They don’t make developers type faster, rather they draw attention to bottlenecks that slow things down, help you see them and respond to them quicker. Using a Kanban board lets you easily visualize work in progress across different roles and lets you see when someone is taking on too much work simultaneously.
  • Demonstrate every few weeks
  • A task board as it’s commonly used in an agile approach can give you the visualization too. But, widening the task board to separate testing from development from acceptance or other process steps helps me better visualize where things are clogging up — helps me better diagnose problems. And, setting hard limits for process steps and respecting them really makes me deal with the problem in a way that dropping a pile of stories into a sprint or iteration didn’t. But, maybe it’s just me who’s lazy and avoids dealing with tough problems. I’m sure you’d never run into a situation where you and your team let lots of finished development work pile up waiting to be tested.
  • There’s no one as zealous as the newly converted There’s a lot of folks pretty excited about Kanban out there. I am too. Sometimes that zeal takes the form of telling people practicing common agile time-boxed development that they’re wrong. But, I guess I’m crusty enough to know that there’s lots of right ways to succeed and anyone who believes they’ve found the best ways is likely wrong. Don’t let those voicing opinions strongly for, or against, Kanban approaches stop you for digging in deeper and understanding the ideas behind it.
  • Yuval Yeret on 03 Jun 09
     
    one of the best articles about Kanban and its relation to Agile I've encountered so far - focusing on Feature development (not maintenance)
Yuval Yeret

Lean und Kanban: Kanban and Understanding - 0 views

www.software-kanban.de/...kanban-and-understanding.html

twitterfavs

shared by Yuval Yeret on 23 Mar 14 - No Cached
  • Yuval Yeret on 23 Mar 14
     
    What a read to start the week - brilliant RT @arneroock: New Blog Post "Kanban and Understanding" http://t.co/mwjYnrFbwX / cc @asplake
Yuval Yeret

מועדים - 0 views

www.selayouniversity.co.il/...Dates.asp

development training embedded-agile-list

shared by Yuval Yeret on 08 Jul 14 - Cached
  • Design of Distrib. & Multi-Core Systems & SoftwareDuration: 2d; Start dates:21/02/2007; 04/
  • Embedded Linux BasicsDuration: 3d; Start dates:19/03/2007; 20/05/2007;
Yuval Yeret

How to make a LOT more money using agile - 0 views

www.agileforall.com/...e-a-lot-more-money-using-agile

agile roi agile-roi

shared by Yuval Yeret on 04 Jun 09 - Cached
  • How to make a LOT more money using agile
  • More frequent releases
  • expectations must be set for releases to be smaller but still have significant marketable value.  It also means managing scope for smaller releases so the value can actually be delivered to meet the expectations.  If we make the assumption these two pre-requisites can be handled, then we can also assume faster releases are possible.  Yes, I know, releasing software is expensive, requires other groups, etc.  For now, let’s assume all of those costs are negligible compared to the potential results and see where we end up.
  • ...14 more annotations...
  • team of 8 people work on a project for a year with an anticipated ROI of 100% after 2 years.
  • $1,000,000 (approximately) in 12 months to build the product
  • get $2,000,000 in revenue within the 12 months following release.
  • ROI is calculated as $profit/$invested which in this case is ($2,000,000-$1,000,000)/$1,000,000 or 100%
  • cash expended, which in this case exactly matches the investment since we did all of the investment prior to receiving any return.
  • Let’s assume that scope can be managed so the product can be delivered in two phases, each taking 6 months.
  • each piece of the product is worth about half of the revenue value of the complete product
  • 6 months at an investment of $500,000 to build the first piece
  • 6 more months at an additional cost of $500,000 to complete the second half
  • after 6 months revenue starts to be brought in for the first release
  • the amount of revenue during the first 6 months of release of the first half of the product would be $500,000 ($2,000,000 for full product for 12 months = $500,000 for half product for 6 months).
  • matches the cost for building the second half of the product, so the cash expended is actually only $500,000 for building the product vs. $1,000,000 for building the product in one step.
  • After phase 2 of the product is completed it too starts to bring in revenue.  We now have the complete product, so we can get full value of it during each time period.  In other words, during the next 12 months it will generate $2,000,000 in revenue.  This brings total revenue to $2,500,000 which means our ROI is now 300% (higher profit divided by smaller investment - $1,500,000 profit / $500,000 invested).
  • Month Expense Revenue Cash (Profit) Total Revenue 6 $500,000 $0 -$500,000 $0 12 $500,000 $500,000 -$500,000 $500,000 24 $0 $2,000,000 $1,500,000 $2,500,000
1 - 20 of 31 Next ›
Showing 20▼ items per page