Skip to main content

Home/ Agilesparks/ Group items tagged basics

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
Yuval Yeret

From the Agile Transformation Trenches: Culture Change with Pigs, not Chickens - 0 views

borland.typepad.com/...ge-with-pigs-not-chickens.html

Agile transition agilesparksblog

shared by Yuval Yeret on 07 Jul 09 - Cached
  • Identify the technical leaders within projects; those that are “self-driven to produce quality results on time … combine technical ability with enough people skills …are trusted and respected by both their managers and fellow developers, are determined to make the team succeed, and usually live the work.” (Chief programmers, Chapter 2:  A Practical Guide to FDD).
  • Sell them the vision: if you cannot sell these people on the benefits to them, their colleagues and the organization of the new way of working then something is wrong
  • Provide in-depth training and on-going coaching. It is better to have a single lead person trained in-depth who can coach his teammates through the basics than to have the whole team trained on the basics with no-one on the team to turn to when the basics are not enough.
  • ...3 more annotations...
  • Providing initial training is simply not enough. When the pressure is on, the temptation to return to previous ways of doing things is often too strong to resist. If technical leads are to work for you, they need on-going support and coaching, and a means by which they can support each other.  Good external coaches (expert chickens?) can help here.
  • Let the technical leads continue working on their projects. Some fail at the final hurdle by doing 1-3 above and then assigning or scheduling the technical leads to coach other projects, effectively turning them from pigs into chickens.
  • To summarize, if you can produce a change in the behavior of the lead pigs, the other pigs will, by definition, follow. However, pigs will not follow chickens for long because chickens are simply not pigs.
  • Yuval Yeret on 07 Jul 09
     
    Last month David Anderson wrote a two-part article on why agile transformation initiatives fail. David's suggestion to concentrate on cultural change reminded me of one of my favorite bits on process initiatives. From Peter Coad's book, Java Modeling in Color...
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

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

Original Scrum-ban Article by Corey Ladas | Lean Software Engineering - 1 views

leansoftwareengineering.com/...scrum-ban

kanban SCrum agile ScrumBan

shared by Yuval Yeret on 19 May 09 - Cached
  • A problem with the basic index-card task board is that there is nothing to prevent you from accumulating a big pile of work in process. Time-boxing, by its nature, sets a bound on how much WIP that can be, but it can still allow much more than would be desirable.
  • then you need another mechanism to regulate the “money supply.” In our case, we simply write the quantity of kanban in circulation on the task board, and allocate new cards according to that limit.
  • You might have a simple principle like: prefer completing work to starting new work, or you might express that as a rule that says: try to work on only one item at a time, but if you are blocked, then you can work on a second item, but no more. In our example, that rule gives us an effective WIP limit of 6.
  • ...6 more annotations...
  • Just because anybody can have more than one item in process doesn’t mean that everybody should have more than one item in process. A problem with our multitasking rule is that it locally optimizes with no consideration of the whole. An implicit total WIP limit of 6 is still more WIP than we should probably tolerate for our three workers. A limit of 4 of 5 total items in process at one time still allows for some multitasking exceptions, but disallows the obviously dysfunctional behavior of everybody carrying two items
  • The ready queue contains items that are pending from the backlog, but have high priority
  • Here we’ve broken down in-process into two states: specify and execute. Specify is about defining whatever criteria are necessary to determine when the work item can be considered complete. Execute is about doing the work necessary to bring that work item into a state which satisfies those criteria. We have split our previous WIP limit of 5 across these two states. Specify is considered to take less time in this case, so it is given a limit of 2. Execute consumes the remaining limit of 3. We might change this ratio as time goes on and our performance changes.
  • Adding the specify-complete column communicates to the team that a work item which was previously in the specify state is now ready to be pulled by anyone who wants to move it to the execute state. Work that is still in the specify state is not eligible to be pulled yet. If the owner of a ticket in the specify state wants to hand it off, he can put it in the complete buffer. If he doesn’t want to hand it off, he can move it directly into the execute state as long as capacity is available.
  • e will also need some agreement about what results to expect at each handoff. We can do that by defining some simple work standards or standard procedures for each state. These do not have to be complicated or exhaustive. Here, they are simple bullets or checklists drawn directly on the task board.
  • The next event we might consider for scheduling planning activities is the concept of an order point. An order point is an inventory level that triggers a process to order new materials. As we pull items from the backlog into the process, the backlog will diminish until the number of items remaining drops below the order point. When this happens, a notice goes out to the responsible parties to organize the next planning meeting. If our current backlog is 10, our throughput is 1/day, and we set an order point at 5, then this planning will happen about once a week.
Yuval Yeret

The New Methodology - 0 views

martinfowler.com/...newMethodology.html

agile methodology basics article ah-kickoff-prep-list afms-reading-list

shared by Yuval Yeret on 21 Mar 14 - Cached
  • ringing a forceful dose of reality into any project
  • ong test phase after the system is "feature complete"
Yuval Yeret

Permanent Link to Feature Flow - Increasing velocity using Kanban - 1 views

blog.xebia.com/...feature-flow-1

lean kanban

shared by Yuval Yeret on 03 Jun 09 - Cached
  • team that had some problems getting their process right
  • their velocity was decreasing and spirits were low. Luckily we managed to change our process by changing some basic Scrum practices and replacing some of them with Lean practices, inspired by the new Kanban articles and presentations. Productivity is now higher than ever and we can now focus on what really matters: product quality and customer satisfaction.
  • one major issue: getting things done. The major symptom was the frustration of management and the team with the project. The first 3-week time box (sprint) ending with about 30% (!) of all features still in progress, when, of course, they should all have been done and ready for shipment.
  • ...9 more annotations...
  • existing solution to this problem was to lower the expected velocity each sprint, so the next sprint would be on-time. But at the end of next sprint, the same problem occurred, so the velocity was going down sprint after sprint.
  • pressure of the rest of the organisation for the team to keep up their tempo. This pressure from both sides was crushing morale.
  • The way this team reacted to pressure was to work harder. Most people would have 2 or 3 tasks in progress at the same time. When a developer would finish a task, the testers were too busy testing something else, so they could give the developer direct feedback. When the tester found an issue with a new feature, the developers were already working on something else, so the tester had to wait. Simply put, there was too much focus on working long and hard, not on cooperation and the stuff that actually matters: features.
  • most dysfunctional behaviour comes from the system people are in
  • biggest struggle of this team: pressure & predictability.
  • Most Scrum masters challenge the team to reach the same (or higher) velocity each sprint. This pressure should give a team focus to perform at its best. However, it can also go haywire if the team doesn't deliver. No focus, no pride, no happy customer
  • retrospectives were dismal and planning meetings were a huge burden. The teams' productivity dropped in the days after the sprint, finding new courage to start the next one. Because they had an ineffective work-process, the only outcome of each sprint was to lower the expected velocity, to make sure we would be predictable. Estimation and predictability are only a means to an end and since they were getting in the way of fixing the root cause (and were bringing down the team's spirit) I opted to cut out the planning sessions and sprint deadlines.
  • first change we made was to set a limit of 8 tasks on the 'in progress' column
  • We spent 3 weeks bringing the numbers of open tasks from 21 to 8, without picking up any new work. Of course the team struggled with this new limit. They were used to pick up new work whenever they were blocked somehow, this wasn't allowed any more
1 - 8 of 8
Showing 20▼ items per page