Skip to main content

Home/ Agilesparks/ Group items tagged why-agile

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
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.
  • 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
  • The Agile Decision Filter
  • . 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
  • 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

Why agile transitions initiatives might fail : Jeffrey Palermo (.com) - 1 views

jeffreypalermo.com/...sitions-initiatives-might-fail

agile transformation embedded-agile-list

shared by Yuval Yeret on 08 Jul 14 - Cached
  • The executive makes a “vendor” or external “coach” responsible for the transition If you have handled the first risk and have defined success and success metrics, you likely will not find a vendor who will base his payment on your metrics.  After all, the metrics likely call for less project failure rate, faster response times, etc.  You probably can’t measure these things in less than a year if you really want objective metrics and not one optimized for short-term results at the expense of the longer term.  A vendor might want: # of people trained % of teams using an “agile” project management tool # of teams with an embedded “agile champion” # of successful iterations It is really easy to accomplish the above metrics and still not make any material change in the organization.  I have worked with a client that did something similar to the above.  Most of the teams starting using some new Scrummy project management web application for project tracking.  They declared that monthly status meetings were now iterations.  They declared a member of the team to be the Scrummaster (and sent that person to training).  Overall, the same organizational problems persisted.  Vendors cannot produce real change in an organization unless the organizations executive leadership alters the culture in a meaningful way.
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

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.
sagism

Lean Startup: Why it rocks far more than agile development - Joshua Kerievsky - YouTube - 0 views

www.youtube.com/watch

video leanstartup

shared by sagism on 09 May 15 - No Cached
  • sagism on 09 May 15
     
    Good intro to Lean Startup for agile practitioners
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.
sagism

http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoi... - 0 views

www2.computer.org/...rW_SO_Viewpoints.pdf

agile why-agile

shared by sagism on 19 Jul 09 - No Cached
  • sagism on 08 Jul 15
     
    Software Engineering - An Idea whose time has come and gone? Tom DeMarco
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." "
sagism

Kate Heddleston - The Null Process - 0 views

kateheddleston.com/...the-null-process

the-case-for-agile

shared by sagism on 15 May 15 - No Cached
  • sagism on 15 May 15
     
    An explanation of why having a process is a better alternative to "no process"
1 - 14 of 14
Showing 20▼ items per page