Link: About Development Managers

My colleague and friend Mike Caspar has posted another insightful article on his blog: Do not create unnecessary fear and animosity with Development Managers.  From the article:

As teams grow, they build confidence and seem to become self-contained, and almost insular to some. This is normal and is not a sign of dysfunction. This simply indicates that the team is starting to have self identity. They are starting to act as a team. This is a good sign…. As the teams become more effective, the Development Manager feels more loss.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Practice Focus: Send Less Email & Close Slack

Very few people are paid to chat or write email: executive assistants and lawyers mostly.  Everybody else is paid to do other work like write code, build things, solve problems, or transact with customers.  Think about what you’re actually paid to do, then do that and only that.

If the Slack channel side-bar represents your definition of “collaboration”, stop! If you need to communicate with others while doing your work, do it face-to-face whenever possible or by phone & video. To be clear: Slack channels may be good for announcements but quickly digress as water-cooler drivel and those chatbots are sorry excuses for actual event logging. Perhaps it’s reassuring to be reminded that there’s nothing in Slack (or Yammer/HipChat/Asana/Jira/Trello) more important than the work you’re actually paid to perform.

If your “Sent Items” folder is a CYA repository, stop! If it’s necessary in your organization to CYA then document your activity in a personal journal and stop involving other people in your CYA habit.

If your Inbox is your to-do list, stop!  Use sticky-notes, a hipster PDA, or a calendar.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

If Multiple Lines of Business Have Competing Priorities, Then Portfolio Prioritization…Right Now!!

I was with a Scrum team two weeks ago who were complaining that multiple lines of business were each pushing priorities into their backlog. The results included:

  • team working lots of overtime;
  • team couldn’t make/keep commitments for any of their stakeholders;
  • team couldn’t focus;
  • team was embarrassed that their code quality had eroded.

The team had come to think they had “multiple Product Owners”. I explained that’s impossible and when I asked who in their organization has the authority to reorder or veto any items in their backlog they all were able to name one Vice President. That VP, I said, is their de facto Product Owner regardless that others may have that job title. The team came to understand that:

  • their so-called Product Owners do not have the authority required to order their backlog, yet;
  • and until they do the onus is on their VP to relinquish said authority and to have crucial conversations with all stakeholders in order to prioritize the portfolio and to set realistic expectations with regard to the team’s true capacity.

For more reading about managing multiple backlogs in an organization, check out this article: Backlogs in an Organization – Levels of Queues


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Do Great Work & Don’t Ship Defects

Teams are often pressured by business stakeholders to “go faster” and deliver new features quickly at the expense of quality. This pressure leads to technical debt unless the team stands strong. Engineers and developers, you have a responsibility to your teams, your profession, and to yourselves to uphold high standards. Yes, learn and incorporate techniques which enable you to deliver frequently but take care to also ensure that your code meets or exceeds your definition of done.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Pitfall of Scrum: Excessive Preparation/Planning

Regular big up-front planning is not necessary with Scrum. Instead, a team can just get started and use constant feedback in the Sprint Review to adjust it’s plans. Even the Product Backlog can be created after the first Sprint has started. All that is really necessary to get started is a Scrum Team, a product vision, and a decision on Sprint length. In this extreme case, the Scrum Team itself would decide what to build in its first Sprint and use the time of the Sprint to also prepare some initial Product Backlog Items. Then, the first Sprint Review would allow stakeholders to provide feedback and further develop the Product Backlog. The empirical nature of Scrum could even allow the Product Owner to emerge from the business stakeholders, rather than being assigned to the team right from the start.

Starting a Sprint without a Product Backlog is not easy, but it can be done. The team has to know at least a little about the business, and there should be some (possibly informal) project or product charter that they are aware of. The team uses this super basic information and decides on their own what to build in their first Sprint. Again, the focus should be on getting something that can be demoed (and potentially shippable). The team is likely to build some good stuff and some things that are completely wrong… but the point is to get the Inspect and Adapt cycle started as quickly as possible. Which means of course that they need to have stakeholders (customers, users) actually attend the demo at the end of the Sprint. The Product Owner may or may not even be involved in this first Sprint.

One important reason this is sometimes a good approach is the culture of “analysis paralysis” that exists in some organizations. In this situation, an organization is unable to do anything because they are so concerned about getting things right. Scrum is a framework for inspect and adapt and that can (and does) include the Product Backlog. Is it better for a team to sit idle while someone tries to do sufficient preparation? Or is it better to get started and inspect and adapt? This is actually a philosophical question (as well as a practical question). The mindset and philosophy of the Agile Manifesto and Scrum is that trying to produce valuable software is more important that documentation… that individuals and how they work together is more important than rigidly following a process or tool. I will agree that in many cases it is acceptable to do some up-front work, but it should be minimized, particularly when it is preventing people from starting to deliver value. The case of a team getting started without a product backlog is rare… but it can be a great way for a team to help an organization overcome analysis paralysis.

The Agile Manifesto is very clear: “The BEST architectures, requirements and designs emerge out of self-organizing teams.” [Emphasis added.]

Hugely memorable for me is the story that Ken Schwaber told in the CSM course that I took from him in 2003.  This is a paraphrase of that story:

I [Ken Schwaber] was talking to the CIO of a large IT organization.  The CIO told me that his projects last twelve to eighteen months and at the end, he doesn’t get what he needs.  I told him, “Scrum can give you what you don’t need in a month.”

I experienced this myself in a profound way just a couple years into my career as an Agile coach and trainer.  I was working with a department of a large technology organization.  They had over one hundred people who had been working on Agile pilot projects.  The department was responsible for a major product and executive management had approved a complete re-write.  The product managers and Product Owners had done a lot of work to prepare a product backlog (about 400 items!) that represented all the existing functionality of the product that needed to be re-written.  But, the big question, “what new technology platform do we use for the re-write?” had not yet been resolved.  The small team of architects were tasked with making this decision.  But they got stuck.  They got stuck for three months.  Finally, the director of the department, who had learned to trust my advice in other circumstances, asked me, “does Scrum have any techniques for making these kind of architectural decisions?”

I said, “yes, but you probably won’t like what Scrum recommends!”

She said, “actually, we’re pretty desperate.  I’ve got over a hundred people effectively sitting idle for the last three months.  What does Scrum recommend?”

“Just start.  Let the teams figure out the platform as they try to implement functionality.”

She thought for a few seconds.  Finally she said, “okay.  Come by this Monday and help me launch our first Sprint.”

The amazing thing was that the teams didn’t lynch me when on Monday she announced that “our Agile consultant says we don’t need to know our platform in order to get started.”

The first Sprint (two weeks long) was pretty chaotic.  But, with some coaching and active support of management, they actually delivered a working increment of their product.  And decided on the platform to use for the rest of the two-year project.

You must trust your team.

If your organization is spending more than a few days preparing for the start of a project, it is probably suffering from this pitfall.  This is the source of great waste and lost opportunity.  Use Scrum to rapidly converge on the correct solutions to your business problems instead of wasting person-years of time on analysis and planning.  We can help with training and coaching to give you the tools to start fast using Scrum and to fix your Scrum implementation.

This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Design Debt & UX Debt is Technical Debt

Hey! Let’s all work together, please.

Technical Debt is a term which captures sloppy code, unmaintainable architecture, clumsy user experience, cluttered visual layout, bloated feature-sets, etc.  My stance is that the term, Technical Debt, includes all the problems which occur when people defer professional discipline — regarding any/every technical practice such as product management, visual and UX design, or code.

I assert that the change we need to catalyze in the business community is larger than any one discipline and I am worried that I have seen an increase in blog articles in recent years about concepts like “Design Debt”, “UX Debt”, “Experience Debt” — these articles unfortunately are not helping and have served only to divide the community. They are divisive, not because we shouldn’t be discussing the discreet facets in which Technical Debt can manifest, but because authors often take a decidedly combative approach in their writing.  Take these phrases for example:

  • “Product Design Debt Versus Technical Debt” written by Andrew Chen
  • “User Experience Debt: Technical debt is only half the battle” written by Clinton Christian
  • “Design debt is more dangerous because…” written by James Engwall.

I agree with Andrew Chen that Product Design Debt is a problem — I just don’t like that he chose to impose a dichotomy where there is none.  Why must he argue one “versus” another?  Clinton Christian has implied that we’re in a “battle”.  James Engwall has compared the “danger” of Design Debt relative to Technical Debt.  These words are damaging, I argue, because they divert attention to symptoms and away from root causes.

The root cause of Technical Debt is that people forget this simple principle of the Agile Manifesto: “Continuous attention to technical excellence and good design enhances agility.”

The root solution to Technical Debt — all of its forms — is to help business leaders realize there is a difference between “incremental” development and “iterative” development so they may understand the ROI of refactoring.  No technical expert should ever have to justify the business case for feature-pruning, refreshing a user interface, refactoring code, prioritizing defects.  Every business leader should trust that their technical staff are disciplined and excellent.

Yes, please blog about UX Debt and Product Development Debt, etc.  But please do so in a way that encourages cohesion and unity within the Product Development community.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: BERTEIG partners with Version One and Scaled Agile Inc.

The past month has been busy!  BERTEIG has officially partnered with both Version One and Scaled Agile Inc.  As BERTEIG grows, our partnerships provide great new resources for our clients.

These partnerships are an outgrowth of our re-branding strategy which saw the launch of our new logo and website early last month.  In the near future we will be announcing more partnerships and relationships to further support our customers and clients.

About VersionOne

VersionOne is a recognized leader and visionary in agile lifecycle management software and services. Our mission is to help companies envision and deliver great software. Since 2002, companies such as Adobe, Capital One, and Oracle have turned to VersionOne. Today, more than 50,000 teams at 1,000 companies, including 37 of the Fortune 100, use our solutions to help them scale their agile initiatives faster, easier and smarter. Whether a small team just starting out with agile or a global enterprise scaling agile, VersionOne customers get the best solutions in the industry backed by the pioneers in agile lifecycle management.

About Scaled Agile Inc and SAFe

Scaled Agile, Inc.’s mission is to help enterprises achieve the capabilities, culture and business benefits that successful implementation of scaled Lean and Agile practices can provide. To achieve this, Scaled Agile provides consulting, training, certification and process tooling based on the Scaled Agile Framework, a proven, publicly-facing knowledge base of effective practices for Lean | Agile adoption at enterprise scale. Visit www.ScaledAgile.com for more details.

The Scaled Agile Framework is a proven, publicly-accessible knowledge base for implementing agile practices at enterprise scale, consisting of approximately 300 pages of guidance. Its primary interface is the “Big Picture” graphic which highlights the individual roles, teams, activities and artefacts necessary to scale agile from the team, to teams of teams, to the enterprise level. It has been successfully applied in programs ranging from only 50-100 people, to enterprises employing thousands of software developers. For more information on the Scaled Agile Framework, visit: www.scaledagileframework.com.

About BERTEIG

BERTEIG is the leading provider of Agile training, coaching and consulting services in the Toronto area.  Agile Advice, World Mindware, The Real Agility Program, The Scrum Team Assessment and OpenAgile are all BERTEIG initiatives and services.  BERTEIG has helped organizations achieve dramatic improvements in time-to-market, near-perfect quality, and 400% boost in overall productivity while at the same time helping people learn to love their work again.  BERTEIG is transforming people, process and culture through the power of Real Agility. (™)


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

When the team says, “we need detailed requirements before we can estimate”…

The next time the team says “we can’t estimate without better requirements” what they actually mean is, “this is crazy, but hey…if you think you can accurately predict all the exact requirements and you can guarantee that nobody in this company will change their minds about those requirements between this moment and forever, then we’ll give you an estimate to hang your hat/noose on.”

Every group responsible for the creation and delivery of software (or any complex/creative product for that matter) will experience dissonance between the need to plan and the need to obey the laws of nature which prevent us from travelling through time and future-telling.  Business leaders have to finance the development of product; creative and technical leaders have to solve complex problems amidst dynamic, unpredictable, circumstances.  These conditions manifest as a dichotomy which is difficult to mediate (at best) and/or downright toxic (at worst).

On one hand, a common sentiment among project managers is: “The problem I have with the release planning stage is that without clear requirements, the developers don’t like to give estimates, even with story points.”

On the other hand, a common sentiment among developers is: “Stakeholders don’t understand what they’re asking for, if they knew the complexity of our technology they wouldn’t be asking those questions.”

If developers don’t like to provide estimates, it is likely because others in the organization have used their estimates as though they are accurate predictions of future. Thus, when said estimates turn out to be inaccurate they are used as punitive metrics in conversations about “commitment” and “velocity” and “accountability”.

Point of order: NOBODY CAN PREDICT THE FUTURE.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Nexus Reifies

Nexus Scrum

I had the privilege of attending Scrum.org‘s 2-day seminar on Scaled Professional Scrum. The Nexusa connection or series of connections linking two or more things (direct translation from Latin a binding together), is the recommended scaling framework. The purpose of the Nexus is to manage dependencies between 3-9 Scrum Teams towards “reification”, to make an abstract idea real or concrete. This is ensured mostly through a single Product Owner, single Product Backlog, integrated (Nexus) Sprint Planning, Review and Retrospective and the addition of a Nexus Integration Team whose membership is made up mostly of Scrum team members internal to the Nexus, but often also includes other support personnel. The structure is very similar to LeSS, but perhaps even less prescriptive and is certainly much less prescriptive than SAFe. This is probably my favourite thing about the Nexus – the fact that it has just enough structure to be a model for scaling Scrum, but is light and flexible enough to accommodate all of the nuances that “just depend” on your situation. Like the other two above-mentioned scaling models, it places emphasis on the need for strong technical practices, continuous integration and the synchronization of events to facilitate integration. There is flexibility around synchronization, in that if the Nexus Sprint is 4 weeks in duration and teams within the Nexus want to do 2 or even 1 week Sprints, the model accommodates – as long as all of the teams’ work is combined into a fully integrated (reified) increment of potentially shippable product by the end of the Nexus Sprint.

 


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Are You Getting What You Need From Conferences?

Professional Development opportunities are everywhere and they are easy to find at any price-point on any topic at any location. The hard part is deciding how to spend your time.

It is important to think about why you attend conferences. Most importantly, why do you choose some conferences over others? Do you want to learn from peers in your field? Do you want exposure to the latest industry trends? Are you looking for a new job? Or do you just want to be blown away by great people?

I attended the Agile Coach Camp Canada last weekend in Cornwall, Ontario, and that incredible experience has caused me to reflect on the variety of conferences I have enjoyed in recent years…and why I choose some over others.

Like any great product, successful conferences have clear and focused goals which create specific opportunities for their participants. Conference organizers choose location, venue, date, duration, registration cost, format, theme, etc. The best conference organizers are courageous and willing to make difficult decisions in order to compose their events with utmost respect to the collective vision and goals of the attendees, sponsors, and founders. The organizers of Agile Coach Camp Canada, for example, are dedicated to creating an event in which the agile coaching community can “share in an energizing and supportive environment”. That’s it! A clear and compelling vision. This clarity of vision guides decisions like whether to host the event in a metropolis (which may result in larger numbers and more sponsorship opportunities) or away from large cities (think overnight “camp”) — this is one formative decision of many that make Agile Coach Camp Canada so intense and unique year after year.

Some background: This was the 6th annual Agile Coach Camp Canada and the 2nd time that I have attended; the event generally starts on Friday evening and includes supper followed by lightning talks, Saturday uses Open Space Technology to produce an agenda followed by supper and socializing (late into the night!), then Sunday morning wraps-up with retrospection then everybody leaves in early afternoon; the cost per person is between $300-$500 for the entire weekend including meals, travel, hotel room; the event is often held in small-ish towns like Guelph or Cornwall which are a few hours from a major airport. Having been there twice — both times just blown away by the community, their expertise, their emotional intelligence, their openness — I understand very clearly the responsibility of conference organizers and I have gained new respect for the difficult decisions they must make.

Upon reflection, I know that I attend the Agile Coach Camp Canada because (a) I learn a lot and (b) I have bonded deeply with my colleagues. Those are the two reasons that I will return next year and the next. I do not attend that event with an expectation to develop new business, or attract new leads, or stay on top of industry trends — instead, I will look to other conferences for those opportunities.

What/where/when is your next professional excursion? Do you know what you want to get out of it? Here’s a tip: choose one objective from the list below and find a conference that delivers exactly that!

  • Business development: Find new or reconnect with existing business contacts.
  • Professional development: Find or explore opportunities for career enhancement.
  • Learning: Listen/watch/share with others who practice in your areas of interest.
  • Community building: Connect and communicate with people with interests or qualities that you appreciate.
  • Market exposure: Evangelize a product or service for a captive audience.
  • Other?

Life is short…make it amazing!


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Request for Feedback on Agile Advice Book

Agile Advice Book - coverMy Agile Advice book has been out for a little more than 4 months.  I’m extremely happy about the fact that over 25 people have purchased it so far without me doing any active promotion.  If any of my blog readers have purchased it, I am looking for feedback – please leave comments below.  (And, of course, if you haven’t purchased the book it’s only $2 on lulu.com and iBookstore.)

I am preparing the next release of the book: version 1.1.  It will include many minor changes and some new content, but I have only received a bit of feedback so far and I would greatly appreciate more.  Again, the best forum for feedback is here – feel free to be critical – I really want to make this better!


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The Agile Manifesto – Essay 3: Working Software over Comprehensive Documentation

How much documentation does it take to run a project with ten people working for six months?  For some organizations it takes way too much:

Photo of heavy documentation for software project

This binder (about 3 or 4 inches thick) is all the documentation associated with such a project.  In looking carefully at the project, creating the documentation took far more time than the time spent on designing, writing and testing the software.  Yet, the documentation does not produce any value.  Only the software produces value.  The Agile Manifesto, asks us to focus on the outcome (working software) and to make tradeoffs to minimize the means (comprehensive documentation).

The Agile Manifesto asks us to challenge our assumptions about documentation.  In many work environments, documentation is an attempt to address some interesting and important needs:

  • Knowledge sharing among stakeholders and the people working on a project.
  • Knowledge sharing across time as people come in and out of a project.
  • Verification and traceability for contracts or other compliance needs.
  • Decision-making and analysis for business and technical problems.
  • Management oversight and control.
  • Various aspects of individual accountability.

Documentation is usually heavier (more comprehensive) the more the following circumstances exist in an organization:

  • Geographical distribution of people.
  • Lack of trust between people, departments or organizations.
  • Regulated work environments.
  • Depth of management hierarchy.
  • Number of people directly and indirectly involved.
  • Knowledge and skill sets highly segregated between people.
  • Culture of respect for written texts.

Working Software

What if the software itself could address the needs that often documentation is used to address?  Let’s look at them in turn:

  • Knowledge sharing among stakeholders and the people working on a project.
    If the software is functional at all stages, as supported by Agile methods such as Scrum and Extreme Programming, then the software becomes an effective representation of the knowledge of all the people who have participated in building it.
  • Knowledge sharing across time as people come in and out of a project.
    Software that is technically excellent is often easier to understand for people who are new to it.  For example, excellence in user experience and design means new users can get up to speed on software faster.  Use of good design patterns and automated testing allows new developers to understand existing software easily.
  • Verification and traceability for contracts or other compliance needs.
    Test-driven development (code) and specification by example (scripting and code) are forms of traceable, executable documentation that easily stay in-sync with the underlying software system.
  • Decision-making and analysis for business and technical problems.
    In particular, diagrams can help a great deal here.  However, electronic tools for creating such diagrams can be slow and awkward.  Consider the practice of Agile Modelling (basically using a whiteboard and taking photos) as a good alternative to precise technical diagramming if you are doing problem-solving.
  • Management oversight and control.
    Reports and metrics drive much of the traditional documentation in an organization.  Simplifying reports and metrics often leads to a clearer picture of what is going on, reduces the opportunities to “game” the system, and always results in lower levels of documentation.  As well, some reports and metrics can be generated 100% through automated means.  All that said, the fundamental premise in the Agile manifesto is that management should base decisions on what is actually built – the “Working software” by looking at it and using it.
  • Various aspects of individual accountability.
    If you really need this, a good version control system can give you the information for this.  Sign-offs and other types of accountability documentation are typically just waste that doesn’t actually help in process improvement.  Most people who are in high-compliance environments already have licenses and/or security clearances that provide this accountability.  If you software is working, however, then this isn’t even a concern as trust is built and bureaucracy can be reduced.

In my recent training programs as research for this article, I have surveyed over 100 people on one aspect of documentation – code documentation.  Every individual surveyed is either currently coding or has a coding background, and every single person had the same answer to a simple scenario question:

Imagine that you have just joined a new organization and you are about to start working as a software developer.  One of the existing team members comes up to you and introduces himself.  He has with him a piece of paper with a complicated-looking diagram and a full binder that looks to be holding about 250 pages.  He asks you, “you need to get up to speed quickly on our existing system – we’re starting you coding tomorrow – would you prefer to go over the architecture diagram with me or would you prefer to review the detailed specifications and design documents.” He indicates the one-page diagram and the binder respectively.  Which would you prefer?

(I’ve put up a Survey Monkey one-question survey: Code Documentation Preference to extend the reach of this question.  It should take you all of 60 seconds to do it.  I’ll post results when I write the next Agile Manifesto essay in a month or two.)

The fact that everyone answers the same way is interesting.  What is even more interesting to me is that if you think through this scenario, it is actually almost the worst-case scenario where you might want documentation for your developers.  That means that in “better” cases where documentation for developers may not be as urgent or necessary, then the approach of just going to talk with someone is a lot better.

Documentation and Maps

The problem with documentation is the same problem we have with maps: “the map is not the territory” (quote from the wisdom of my father, Garry Berteig).  We sometimes forget this simple idea.  When we look at, say, Google Maps, we always have in the back of our consciousness that the map is just a guide and it is not a guarantee.  We know that if we arrive at a place, we will see the richness of the real world, not the simplified lines and colours of a map.  We don’t consider maps as legally binding contracts (usually).  We use maps to orient ourselves… as we look around at our reality.  We can share directions using maps, but we don’t share purpose or problems with maps.  And finally, maps assume that physical reality is changing relatively slowly (even Google Maps).

Many times when we create documentation in organizations, however, we get confused about the map versus the territory.

Agility and Documentation

Of course, code is a funny thing: all code is documentation too.  The code is not the behaviour.  But in software, code (e.g. Java, ASM, Scheme, Prolog, Python, etc.) is as close as possible to the perfect map.  Software is (mostly) deterministic.  Software (mostly) doesn’t change itself.  Software (mostly) runs in a state absent from in-place human changes to that software.  Software (mostly) runs on a system (virtual or physical) that has stable characteristics.  The code we write is a map.  From this perspective, documentation becomes even less important if we have people that already understand the language(s)/platform(s) deeply.


This essay is a continuation of my series on the Agile Manifesto.  The previous two essays are “Value and Values” and “Individuals and Interactions over Processes and Tools“.

 


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Another Agile Article on Slashdot – Andy Hunt has Failed, not Agile

For reference, here is the link to the article on Slashdot called Is Agile Development a Failing Concept?

This article will generate lots of great discussion, but most of it will be ignorant.  My biggest problem with this is that one of the authors of the Agile Manifesto, Andy Hunt, has asserted that Agile just isn’t working out.  My opinion: Andy has failed to have the necessary patience for a decades-long cultural change.  This is a lot like a leader at Toyota saying that lean has failed because 50 years after they started doing it, not everyone is doing it properly yet.  One organization that I know of has been working on changing to Agile for over 10 years and they still aren’t “done”.  That’s actually okay.


Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail