Escolar Documentos
Profissional Documentos
Cultura Documentos
com brought together many Agile practitioners and thought leaders for the first Agile
Scout – The State of Agile Blog Series.
We thank all the contributors and look forward to seeing how Agile continues to grow and change in the years to come!
Best,
www.agilescout.com
@agilescout
Tuesday 10/26 – Tobias Mayer
Wednesday 10/27 – Derek Huether
A Beautiful Stepping Stone
I was asked by Agile Scout to write an article for the State of Agile series. This is my response.
At the end of September I attended the Scrum Beyond Software event in Phoenix, at the wonderful Gangplank facility. This was both the last
event I organized while working for theScrum Alliance, and (to my knowledge) the first full Open Space event set up to explore this topic.
The event was interesting for many reasons, one being that the attendees came from many different backgrounds and identified with
different Agile communities, including Scrum, Kanban, XP, Lean or just simply non-denominational Agile. What emerged from this mix of
minds and ideas, free from the software development constraint was the truth of similarities over differences. We shared a common vision.
For me, it was a realization that too often the buzzwords become prisons — a way to establish a territory, or carve out a market niche, a way
to stand still. And I am as guilty as many of building barriers to collaboration across the different splinter movements.
As I reflected on that learning moment over the following weeks, ideas that had been kicking around in my mind for some time became
clear. I once thought I knew what Scrum was, but over the past year or two –especially the recent six months– it has become clear to me
that the Scrum Alliance and scrum.org understanding of Scrum is greatly different to mine. Given that these organizations between them
effectively own Scrum, it is sensible for me to admit that what I do, what I teach isn’t Scrum. It is something else.
I have always found the term “Agile” a little ambiguous. To me it is little more than amanifesto and an annual USA conference. There is a set
of principles which offer guidance on software development, but describes no concrete application. XP, Scrum, Kanban etc. offer actual
practices. Almost every software company now claims to be “Agile.” The term has grown like a cancer into massive overuse, and thus into
meaningless jargon. And of course, by the nature of the manifesto language, Agile itself is rooted in software development. I am interested
in exploring and transforming whole organizations, even those that don’t build software at all. Agile is a vaguely useful term, covering a
multitude of ideas and practices.
Kanban, the process I always saw as “watered down Scrum” is emerging as a useful way of working when addressing problems in certain
areas of an organization, in fact I’ve recently been applying some Kanban concepts in non-project focused work to great effect, e.g. the
practice of continuous flow over upfront commitment, and the decoupling of review and retrospective, allowing each to find its own cadence
within the given context. The core Kanban practices of visual management and minimized WIP are essential techniques in any context to
help create the mindset we are seeking.
Some of the ideas from the Lean movement are useful, but it’s application in the software world seems to mostly be on process
improvement and streamlining, with little focus on relationships and collaboration. XP and Software Craftsmanship offer an excellent
mindset for building software, but again they are rooted in one small part of the knowledge industry. Highly recommended, but not really
transferable to other domains. Many of the Agile methods being used are useful in particular contexts. None is appropriate everywhere.
The important thing to remember is that there is so much more to draw on than the Agile family of methods. There is Improv, Artful
Making, CAS, Games Theory, Integral and Coactive Coaching, NLP, Dan Pink’s Motivation 3.0, the work of Ricardo Semler, Seth Godin,
<add your favorite writer>, the inspirational ideas from so many TED Talks, and much more. The Agile community, the Agile-rooted ideas
are a very small part of a whole movement taking place in the world of knowledge work. We are marching, or perhaps more accurately
slipping and sliding towards a new paradigm. Agile is part of a ripple that when combined with other ideas and practices will collectively
become a tidal wave of change. I want to get out of the shallows, the safety, and (let’s be honest) the growing stagnation of the Agile
community, and ride that wave of change.
One or two of us at the Phoenix event committed to trying to get by without using the terms Agile, Scrum, Kanban, etc. in our writings.
Perhaps this article will be the last time I dwell on those terms (they may crop up in passing). For one, it would be lovely to describe what I
do in terms that doesn’t cause people to look at me in confusion and say “what does that mean?” I’d like to explore, not explain. I have a
desire to seek simplicity of language, as I believe it will lead to simplicity of solution. Lean is an example of a term that sounds like what it
does. Software Craftsmanship is another.
My journey forward is one of discovering, embracing, collecting, sifting, sharing, shaping, crafting, and exchanging gifts with fellow
travelers.
So how do I see Agile? I see it as one stepping stone (a particularly beautiful one) on a great journey towards a business world that is more
caring, loving, respectful and altogether more joyous. Agile will meld into the ideas of many other movements, and we’ll all move forward
towards the greater goal, seeking similarities and finding ways to collaborate, innovate and reconceive the way we work.
—-
Tobias Mayer is an organizational change agent, coach and trainer based in Palo Alto, CA with frequent trips to his home town of
London for work and pleasure. Every few years he likes to reinvent himself.
-
My goal, at the beginning, was to comply with all defined policies, processes, and procedures, while ensuring the project stayed within
schedule, budget, and scope. After a few years, I left this position and I started my own consulting company. This radically changed my
perspective of what was important. Though most of my consulting was in hardware, my focus shifted toward satisfying the customer. Upon
returning to application development, I began managing software development projects for corporate and government agencies. At first, I
resorted back to my old ways, trying to manage everything through process and controls. I sought out and obtained my Project
Management Professional (PMP) credential.
I surprisingly discovered that customers really didn’t care how I managed the project, as long as they got what they
wanted, when they wanted it, at the price they agreed to.
I started to go as lean as possible on documentation and processes, working with small co-located cross-functional teams. The result was
delivery of more value more often. It was interesting to watch other project managers not have as much success, focusing more of their
attention on the process than on their customers and products. That’s about the time a colleague recommended I read Ken Schwaber’s
book, Agile Project Management with Scrum . As I read page after page, I realized I had been using basic agile practices and hadn’t even
known it. After signing the Agile Manifesto and embracing “formal” Scrum practices, I went on to become the Manager of Software
Engineering at an online university. Since then, I’ve gone on to be an advisor to a U.S. Government Agency Program Management Office
(PMO). Of those working in the PMO, I am one of many PMPs but I am the only Certified ScrumMaster.
I’m a guy, passionate about getting his customers what they want in the most cost-efficient, time-efficient, and effort-efficient ways
possible. I do what makes sense to me. Additionally, I have spent the last two years coaching up-and-coming project managers (and
leaders) looking to obtain a certification or credential while dispelling myths about Agile principles and practices.
“Serve practitioners and organizations with standards that describe good practices, globally recognized credentials that
certify project management expertise, and resources for professional development, networking and community.“
Unfortunately, hiring managers have leached onto the PMP credential, which should be understood as someone with an entry-level
understanding of project management. Instead, hiring managers and others have elevated the PMP to a level of perceived expert. PMI does
not support this but they don’t condone it either. Many people get the PMP because their final objective is a credential, not to master the art
of project management and leadership. And this, I believe, is directly impacting how the Agile community works in its future.
Though I see organizations like the PMI and Scrum Alliance (SA) having members who actually want to master skills and deliver real value,
certifications seem to be what motivates some people in the short term. Which is more important? Having a large membership base,
having a large certification base, or having people who have mastered skills that deliver value? Well, if you don’t get a large membership
and certification base, how are you going to be that instrument of change?
Where is Agile Going
Soon, there will be a lot of movement in the Agile certification space. The Scrum Alliance has their certifications, the International
Consortium for Agile (ICAgile) will soon be offering memberships and certifications, and you may see further movement by PMI into the
Agile space. So, are future Agile certification objectives going to performance-based orlearning-based? Though you can not change
the motivations of the people pursuing the certifications or credentials, those who are providing them have it within their power to steer
applicants toward a road of mastery versus a dead end certification.
Scrum Alliance
From the October release of the Scrum News, I read the Scrum Alliance has selected Donna Farmer as the new Managing
Director. Farmer will lead the non-profit organization, working with the staff and Board of Directors to realize the organization’s vision and
mission. Lately, there seems to be some turbulence in the Scrum world, after Tobias Mayerresigned from his SA staff role as creative
director and renounced his SA certifications of CSM, CSP, and CST. He then wrote a scathing blog post on the whole series of events. I
empathize with Tobias and what he went through. I empathize with the Scrum community, as it evolves and tries to navigate through
constant change. So, Donna Farmer has admitted that she is new to Scrum. Though she is, should it matter? I’m not saying Farmer is
going to be a savior for the Scrum Alliance but I want to give her the benefit of the doubt. There is a opportunity available to steer the
Scrum certifications toward learning-based objectives, ensuring applicants are provided tools to help them in mastering their skills.
ICAgile
A recent addition to the Agile community is the International Consortium for Agile (ICAgile). ICAgile is being spearheaded by none other
than Dr. Alistair Cockburn, the man instrumental in creating and steering the field of Agile software development since its inception. He co-
authored the original Manifesto for Agile Software Development and among other things, served on the board of the Agile Alliance, and
designed the Crystal family of Agile methodologies. Dr. Cockburn has consistently demonstrated leadership toward learning over mere
certifications. Let’s take a look at ICAgile’s published goal.
“To foster thinking and learning around Agile methods, skills and tools. We understand the difficulty of balancing
education and certification, so as an alternative to other certification programs, ICAgile certification is skills based and
requires people to demonstrate they have learned both why (the value) and how (the mechanics) for a core set of skills.”
As a key goal, ICAgile will be focused toward learning-based objectives, ensuring applicants are provided tools to help them in mastering
their skills.
Project Management Institute
Though PMI does not currently have an Agile certification, there was a huge Agile presence at the PMI North American Congress just a few
weeks ago. There was strong representation by the Agile Community of Practice and a lot of curiosity, and might I add ignorance, by the
average Congress attendee. I don’t find it surprising, considering there is a complete omission of the word “Agile” in PMI’s Project
Management Body of Knowledge (PMBOK®) version 4.0. But, the PMBOK version 5 is in the works. A new PMP credential exam is being
release in August 2011. What will happen to the Agile community if Agile is actually added to the PMBOK? Will PMI modify the current
PMP credential to include Agile or will it launch its own Agile credential?
Summary
I will conclude in saying, in order for the Agile community to continue to grow and keep true to the principles of the Agile Manifesto,
certification programs should truly add value and assess the skill set as well as knowledge of the individual. As stated on the ICAgile
website:
“Is Certification important? Well that is a debatable topic that can take days and months to conclude. The fact is that for
some people, in some cultures, and for some organizations certifications are important and have value; that is a fact.”
I see the Scrum Alliance, ICAgile, and PMI all working to advance Agile understanding, as it moves toward further adoption in the
mainstream. But, let us not forget the Agile Manifesto and 12 principles. Let us not forget to deliver value.
-
Agile software development is a path to return our profession to its roots – working closely and collaboratively with our customers to build
target-on high-value products just-in-time.
Where is Agile going?
Our world has become very crowded, complex and interdependent. The technologies and insights we have are often beyond our abilities to
act on them. Just as Toyota and lean overcame the more simplistic General Motors, the organizations that can adapt to complexity and
create ways and products that allow us to be agile will succeed and the others will wither. I work with the organizations and people who vote
for agility, and who want to work in the midst of complexity.
o The positive points are the proximity between the project manager and team being able to make decisions quickly and transparently.
o The negative points I have found are the inability to build a backlog, having no presence of the product owner, and the difficulty to
implement the user stories.
What Agile software development is in my mind: a toolkit for managers to better communicate, give feedback to the real teams share
around problems. For individuals like myself who have been introduced to Agile through different ways, it is easy to see the value of
what Agile development methodologies can bring to a team. I see Agile getting very popular in the future and my hopes are that it continues
to be picked up by self-organizing individuals who are tired of doing development the old way.
Where is Agile going?
In the future, Agile can become a repository closed and suddenly does not continue to give all his wealth to various types of projects and
thus build a feedback field more pragmatic and backgrounds. A method must not become a repository to be applied to the letter with an
application domain specific, and Agile should not go in that direction. Agile should continue to be an inclusive approach, which is built of
good practices of each business to bring real added value. This point must not be forgotten by the experts Agile.
-
Back in 2000, my programmer teammates and I were figuring out how to do testing in an XP environment, and how testers add value on
XP teams. The Agile community was welcoming, and our employer gave us time and training to learn practices such as TDD and
refactoring. There were few lightweight automated tool choices, but managed to automate a good percentage of our regression testing. We
produced production-ready code every iteration. My team helped start a local XP user group with folks from the few other startup
companies in Denver who were doing XP.
I was one of a handful of testers to attend XP Universe 2001, the first Agile conference (as far as I know) in North America. My experience
report at a large testing conference that same year was the only one on the subject of XP (we didn’t have the term “Agile” yet).
The XP literature of the time talked about customers and programmers, and pretty much nothing else. Testers, QA managers, business
analysts, project managers, and people in other roles worried what would happen to them when their organization transitioned to Agile.
Fear and loathing ensued, fueled by organizations that dumped documentation, encouraged chaos and called themselves “Agile.”
Today, I’ve worked as a tester on five different Agile (ok, one was not so Agile) teams. I’ve worked on my current team for almost all of the
past seven years. New and improved test automation frameworks and drivers come to our attention continually. 100% of my team’s
regression tests are automated. We are experts in our company’s domain and drive development with business-facing acceptance tests. We
have a stable, releasable, production-ready build every day.
Our local Agile user group, now 10 years old, has several hundred members, many from some of the largest employers in the Denver area.
The meetings at other local software groups, including the QA group, often revolve around presentations on agile development. Agile 2010
had a robust testing “stage,” with many testers attending the conference. Every testing conference I attend has many participants from Agile
teams. Social networks such as LinkedIn and Twitter allow practitioners from around the globe to share experiences and spread ideas.
Agile software development is really about continually improving how we do our job of delivering software to help the business. Practices
such as continuous integration, test-driven development, and refactoring, which were popularized by agile processes, have become adopted
by teams that don’t apply the “Agile” label to themselves – it’s just about producing a good product.
What Agile Has Done For Us
Agile development has clearly “crossed the chasm.” For Agile practitioners, that means that there are plenty of places we enjoy working! For
companies, it means that software enhances the business, instead of holding it back – it may even mean, as it did with my current employer,
the difference between success and failure.
The Agile movement has brought sweeping changes to the world of testers. Back in the day, “QA” professionals were the quality police. My
last job title on a waterfall team was actually “Quality Boss!” With Agile, the whole development team is committed to delivering the highest
quality code possible – and a large part of that quality is defined by our customers. When a diverse group of people with a varied skill set
and wide-ranging experience takes on testing problems, innovative solutions result. More importantly, testing is no longer a separate
phase. Coding and testing are two inseparable parts of software development.
Early Agile teams were frustrated with the heavyweight vendor test tools, mostly GUI-based, of the time. So they built their own tools that
were lightweight enough for an Agile environment, where we deliver business value frequently while maintaining a sustainable pace. Even
better, they involved the larger open source community to help develop these tools, making them available to teams everywhere. Even
commercial test tool vendors have finally woken up to the needs of Agile teams. Today, Agile teams enjoy an incredible variety of tools to
meet a huge variety of testing needs. Many of these tools reinforce the essential collaboration between testers and programmers, and
between development teams and business experts. Continuous integration tools let us have fast feedback all day long. If anyone checks in a
change that “breaks” any part of the system, our regression tests will tell us right away.
Agile software development has blurred the lines between roles on the teams. Everyone on an Agile team does testing. Testers often do
analysis work, act as toolsmiths, maintain continuous integration processes and even write production code. I’ve been known to fix bugs in
SQL code. My own team writes high-level acceptance tests together. No matter what our official role, we all collaborate, with a common goal
in mind: Deliver the best possible solution to the business.
Ten years ago, the common wisdom said that XP was for small, co-located teams. These days, technology enables huge software
organizations spread around the globe to have effective Agile teams, coordinating vast code bases.
For that to happen, the good people need time to learn, and autonomy to find the best ways to deliver good software. Programs that
promote a learning culture, such as Google’s 20% rule and Atlassian’s FedEx Days, help companies attract and keep the best practitioners.
Unfortunately, not all companies are committed to providing a high quality software product. They aren’t going to bother to hire the right
people, provide training and time to learn, and make the kind of investment needed for success over the long term. The bright side of this is
there will still be jobs for people who don’t care about software craftsmanship.
We might hear the term “Agile” less in the future, but see continuous integration adopted as just as essential as source code control (who
doesn’t do source code control nowadays? But 15 years ago many teams found it optional). TDD and ATDD may be next in the list of
practices that are accepted as the right way to ensure that the right product is produced. More frequent delivery and even continuous
delivery to production, with all the practices needed to support that, will become the norm. We’ll have better and better tools to use,
providing constant visual feedback that keeps our projects on track.
In this rosy future, there might not be a place in successful organizations for “testers” who do nothing but execute manual test scripts and
never learn anything new. There might not be a place with a desirable employer for anyone who isn’t passionate about delivering the best
possible software product. Agile development raises the bar for everyone on the development team. The software craftsmanship movement
includes testing. There are so many ways to hone our craft, from traditional conferences to testing dojos and Weekend Testers. Enjoyment
is the most important Agile value. If you discover the joys of learning, growing, collaborating, and getting outside of your comfort
zone, the future of Agile will be very good to you!
-
When I first started to introduce Agile my team mates were ok with the technical practices and over the next few years we made real
improvements in code quality that can be attributed to: Continuous Integration, Unit Testing, Peer Code Reviews (Pair Programming) and
Discipline.
However on the rest Agile/Scrum cannon: Daily Standups, Retrospectives, Iterations went over like a lead balloon.
Outside of my team people would say Scrum is that weird stuff or it won’t work here it only works web based companies, startups, or
whatever we’re not.
Nearly 10 yrs later I have the opposite problem people have now figured out that Agile/Scrum/xxx work. They flock to training and ask for
coaching they understand the transition will be hard and take time. They embrace the mechanics (i.e. meetings, user stories, story point
estimation, …). Now we have two problems: the engineering practices don’t get adopted and people often miss the spirit of Scrum. With
new teams we can usually get the mechanics of Scrum down pat in only a sprint or two, once people’s minds are open its a remarkable
simple process.
The problem is when start introducing Unit Testing (or worse TDD) and people will say: “Wow that’s tough, we really don’t have time for
that”. So frustrated was I with this experience that I’ve written an article Technical Debt a Perspective for Managers just to explain the holes
they’re digging for themselves. Managers see the amazing results otherAgile development projects have achieved and want them now,
Developers see the pressure to create working software and just retreat to the technical skills they know. As a community we need to do a
better job of educating all parties as to the importance of the technical practices and give them realistic time lines to become proficient.
Expecting developers to learn TDD in a few weeks with no support just isn’t realistic.
The other problem happens with people who learn the mechanics without understanding the principles behind Agile/Scrum. For example:
some manager’s hold a daily scrum that is just a form of having the team report to them daily and runs 30 minutes instead of the <15 min.
Other examples abound, but the point is that these people have learned the mechanics without understanding what it means to be self-
organizing, transparent or truthful. Mechanically agile processes seem to be the source of many “Agile ruined my life” blog posts recently.
Unfortunately this problem is inevitable as Agile grows up and becomes mainstream their will always be adoptions go wrong.
The future?
I’ve given up predicting it, see Dan Gardner “Future Babble : Why Expert Predictions Fail – and Why We Believe Them Anyway.”
-
My second company hired me to lead a project for travel and leisure industry. That was a time when I wrote my first real requirements
specification with lots of use cases etc. Of course I learned quickly that nobody except me understood what it was about. This is where I
learned how to work better with clients. I didn’t know at that time that some solutions that we stared to use have a name (like user stories).
In my third company I fell in love with unit testing and started to learn everything I could about agile. Soon after I started my own company
(Agilers) because I wanted to create a tool that would help us work with the clients the way we wanted and we wanted it to be transparent
and light.
I think now we’ve made a full circle. Scrum has become mainstream. Kanban joined along the way, but I don’t perceive it as a successor of
Scrum, but rather a way to address project contexts that are in natural way flow-oriented and cannot be closed in time boxes. So Kanban is
not that next big thing for me.
During the last few years of hype everybody wanted to be agile. Agile stopped being introduced bottom-up and started to be pushed from
the top (by high management). It seemed to be a quick transformation. Scrum seemed to be a simple framework with a few simple rules,
some meetings that we’ve always loved and roles that we just needed to map within our organization.
At the beginning most Agile evangelists mentioned Scrum + XP almost as one method. They were a perfect fit. However the more
management started to push agile (and Scrum as it became almost a synonym of Agile) into organizations the more they were forgetting
about the actual software development that hides behind the Scrum meetings.
But about around 2009 another movement appeared. It was Software Craftsmanship. This is where we made a full circle, as we now try to
stop the shallow agile transformation and restore also the ideas of XP, clean code and high quality engineering that are indispensable for
successful agile adoption.
We know better how to build a high quality software, we know how to empower our teams through a better communication and more
effective distribution of responsibility. And now we get the signals that it’s time to finally focus on doing the right software and pay more
attention to customer needs.
We’ve learned the rules of the game. Now it’s time to play for real. First role belongs to customer now. This is where we still have lots to
learn and discover.
Today fans of Lean pour scorn on Scrum, as do XP and DSDM practitioners, whilst theScrum Alliance seems to face a never ending series of
internal struggles. As one of very few agilists who truly has a stake in all of the main approaches, I would dearly love to see some more
‘unity’ in the ‘community.’
Where is Agile going (in the future)?
Agile is in the process of becoming mainstream. In the last few years we have started to see job advertisements for ‘Product Owners’ appear.
Large companies such as BT and Nokia have formally adopted Agile as their standard approach with top-down, management-driven
initiatives. Today when I run Agile training classes I rarely come across anyone with anti-Agile opinions. Ten years ago it was quite the
opposite. As any new technology crosses the chasm from early adopter to early majority and then late majority usage, it inevitably becomes
commoditised, adapted-in-practice and ultimately assimilated into general use.This is where Agile is heading. Worldwide the number of
Certified Scrum Trainers and Certified Scrum Masters continues to rise and the Scrum Alliance builds bridges to the PMI. In the UK the
DSDM consortium has struck a deal with the APMG (the accreditation organisation for PRINCE2) to launch a new Agile Project
Management certification. I believe that these developments will see the old battle-lines become meaningless and a mass of PMI and
PRINCE2 practitioners will embrace Agile. This can only be a good thing, but it is certain that as this happens the majority of organisations
will struggle to realise the full promise of agile. As with anything complicated, it will be those who are most capable, adaptable and
dedicated who will reap the most benefits. This goes for us as well as our customers!
-
In the 1990’s I was a major proponent of the Rational (now IBM) Unified Process even beta testing new releases of the toolkit. RUP was a
hybrid of waterfall and iterative approaches. While RUP had many good qualities, it suffered from being too complex and difficult to master.
Agile has gone in the opposite direction. The basic concepts are easy to grasp but suffer from a lack of controls demanded by big companies.
Regrettably, this prompts many large firms to blend waterfall and agile techniques. Good luck with that!
Let’s cut to the chase. Software development is risky. Time, money and quality are on the line. Any approach to
developing software must attempt to control the risks.
While waterfall works for some, it has an inherent problem of pushing risk out to the end of the project. By the time serious problems are
discovered, it is too late to address them and stay on schedule.
Agile techniques have evolved around the goal of spreading risk more evenly across the development lifecycle. The idea is to have
development teams admit that they do not have all the answers and will strive to unearth problems, inconsistencies and conflicts as early as
possible. But how?
Agile techniques can help mitigate risk but they are not simple solutions and could make things worse if not implemented properly. One
hurdle to being agile is defining what agile means. There is no standard definition and there are many approaches. The most common
methodologies include Scrum, Kanban, eXtreme Programming, Test-Driven Development, Feature-Driven Development, and the Open
Unified Process.
Let’s not forget “Scrum-but,” “like Kanban” and “similar to …” You get the idea. Agile development has decomposed into many variations.
Too many. When someone tells you agile did not work for their project it is likely because they were “mostly Agile.”
There are a few things that any approach claiming to be Agile must do.
Early delivery to the business users is critical. By frequently delivering software to the user community, you identify key issues and risks
much earlier in the process while there is still time to adjust. You also isolate requirements that may have been misinterpreted or missed
entirely.
For any Agile approach to work, the user community must be actively engaged in the effort. Demos and PowerPoint presentations are not
enough. They must use the software and provide regular feedback to mitigate risk. The users are not a substitute for QA. They do not have
the training and discipline to conduct detailed quality assurance, but their feedback is invaluable.
The need for active business community participation is a huge hurdle to agile adoption. In big firms, the business folks have grown
accustomed to telling IT what they want and receiving it several months (or years) later. Software that is often buggy and incomplete is
expected. It will get fixed over time, right?
Making Agile work demands constant software validation. The software cannot be tested at the end of the development effort. Testing must
be an integral part of the development process. If the software is fragile, it is better to know as early as possible.
Without constant QA testing, buggy software will be delivered to the end users. As the software crashes and hangs, they will quickly become
frustrated and uncooperative.
For Agile development to move beyond being a niche solution, major corporations must adopt it and use it successfully. This will not be
easy. Additional controls are going to be needed along with more statistics and reports.
Some argue that Agile teams do not need project managers. They will now! Instead of a single master project plan, teams will need a high-
level plan supported by a set of more detailed, iteration plans that will change along the way. This will place a larger burden on the project
manager and the team.
Agile teams recognize that they cannot get every detail right the first time and will need to refactor some parts of the code along the way.
This concept is difficult for many to grasp but important to the success of agile teams. It is up to the project manager to ensure that refactor
does not become a euphemism for seeking perfection or adding features. The goal is software that is good enough not perfect.
Management often expects the same type of documentation from an agile project as a waterfall one; process diagrams, requirements docs,
functional specs, design specs, test specs, etc. If you were to try to produce such documents for every iteration, there would no time to write
the software. Ultimately, what really matters is working software not the supporting artifacts – another new concept for management to
embrace.
Any new approach to developing software takes time to get right as the development team adjusts and the business community becomes
engaged in the effort. Agile will succeed in big companies- it just won’t be easy.