agile scout state of agile 2010 blog series

8/7/2019 Agile Scout State of Agile 2010 Blog Series

1/36

In October of 2010, AgileScout.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,

-

The Agile Scouts -

www.agilescout.com

@agilescout


2/36

Tuesday 10/26 Tobias Mayer


3/36

Wednesday 10/27 Derek Huether

Thursday 10/28 Ken Schwaber


4/36

Friday 10/29 Josh Nankivel (Video!) and Sara Broca


5/36

Monday 11/1 Lisa Crispin

Tuesday 11/2 Mark Levison


6/36

Wednesday 11/3 Marcin Niebudek

Thursday 11/4 Matthias Marschall and David Hicks


7/36

Friday 11/5 Vincent DAmico


8/36


9/36

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 isnt Scrum. It is something else.


10/36

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 dont 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 Ive 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 its 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 Pinks Motivation 3.0, the work of Ricardo Semler, Seth Godin,

, 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 (lets 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 doesnt cause people to look at me in confusion and say what does thatmean? Id like to explore, not explain. I have a


11/36

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

You can find Tobias Mayer at @tobiasmayer and blogging on http://agileanarchy.wordpress.com/.


12/36

Mastery-based Learning and the Paradox of the Certification

I started in Project Management some 15 years ago.

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 didnt care how I managed the project, as long as they got what theywanted, 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. Thats about the time a colleague recommended I read Ken Schwabers

book,Agile Project Management with Scrum . As I read page after page, I realized I had been using basic agile practices and hadnt even


13/36

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, Ive 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.

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

How Agile has changed in terms of Ideology

Its called mastery-based learning and the paradox of the certification. What is the goal? Are we trying to discover better ways to

deliver value to our customers or are we just trying to get a piece of paper and a few extra letters after our names? Some are pursuing the

mastery ofperformance-based objectives versus learning-based objectives (ie. getting a passing score on a certification exam

versus being a good manager or leader). Lets recognize the 800 pound gorilla in the room. Its called the Project Management Institute

(PMI) and they have a credential called the PMP (Project Management Professional). Im not putting down the PMI. I am both a

member, and as I mentioned earlier, a PMP credential holder.

PMIs goal:

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 dont 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 dont get a large membership

and certification base, how are you going to be that instrument of change?

Where is Agile Going


14/36

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 ofthe 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 organizations 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? Im 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. Lets take a look at ICAgiles published goal.

To foster thinking and learning around Agile methods, skills and tools. We understand the difficulty of balancingeducation 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


15/36

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 dont find it surprising, considering there is a complete omission of the word Agile in PMIs 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.

-

You can find Derek Huether at @derekhuether and blogging on http://thecriticalpath.info.


16/36

I have been in software development for over thirty years. Prior to that, I was a deck officer in the merchant marine. Dont ask. Many of my

early years in our industry were spent developing operating systems, both embedded, device oriented, and part of the IBM mainframe

operating system suite. Ive worked at the University of Chicago, Illinois Institute of Technology, Wang Laboratories, and for the last 20

years, my company, Advanced Development Methods and Scrum.org. My daughters are grown and launched, and I live in Lexington,

Massachusetts with my wife, Chris.

How has Agile changed?

Agile means many things, like flexibility and focus. First and foremost, it means getting rid of waterfall and waterfall, predictive mechanistic

thinking. I remember being at an IBM conference is the early 1980s. A speaker said, If this approach works for the automotive industry, it

should work for us! This led us to twenty-five years of thinking we could create certainty in the midst of complexity by wanting it badly

enough. It led us to think of creative people as resources that should be leveled and allocated across many concurrent activities. It wastwenty-five years of turning a great profession into one disliked by both its members and its customers.

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?


17/36

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.

-

You can find Ken Schwaber at @kschwaber and blogging on http://kenschwaber.wordpress.com


18/36

Background:

I am a project manager / quality junior in the rail industry for 3 years and now begin a carrier in aeronautic industry. Passionate about my

job, Im always looking for new methods, new ways of doing things to improve my daily life and the one of people I work with.


For now, I cannot not really apply Agile methods in my environment. I heard about Scrum for the first time by collaborators from a software

team. I liked the concept very quickly. So I did some research on the subject via the Web, I joined an association specialized in the field and

Im always looking for feedback from experiences on the subject. After some research, with one of my colleagues, we tried to introduce

people to the method, it did not work. People were resistant because they do not see how we could adapt to our world.

I tried to put in place daily scrum with a small team on a traditional project to improve communication with this team and try to introduce

them without too mention the name of the method. As always, there were positives and negatives.

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


19/36

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.

-

You can find Sara Broca at @sara_broca and blogging on http://blog.quasutra.com


20/36

http://www.youtube.com/watch?v=D-edq6wP76A

Josh submitted his State of Agile as a Youtube video!

-

You can find Josh Nankivel at @pmStudent and blogging on http://pmStudent.com.


21/36

The State of Agile: A Testers Viewpoint

I started my software career as a programmer/analyst working in an organization that knew nothing about waterfall we sat with our end

users and released when they were happy with our product. Through the years, Ive worked in tech support and QA for software companies,

as a tester and QA director for internet startups. One was a successful waterfall shop that automated all unit tests, a large percentage of

functional tests, and did continuous integration sound familiar? For the past 10 years, Ive worked as a tester on agile teams.

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


22/36

Today, Ive worked as a tester on five different Agile (ok, one was not so Agile) teams. Ive 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 teams

regression tests are automated. We are experts in our companys 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 dont apply the Agile label to themselves its 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


23/36

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 doanalysis work, act as toolsmiths, maintain continuous integration processes and even write production code. Ive 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.

Where Is Agile Taking Us?

Test-driven development helps us deliver solid architecture and code design. Acceptance test-driven development helps us deliver exactly

what our customers want. Continuous integration and refactoring help us work at a sustainable pace. Communication, collaboration,simplicity and feedback are like apple pie who wouldnt want that? My hope is that all of these become good ways of developing software.

We dont need a special name for it we need to do our best work.

Successful software development depends on having good people, who are allowed to do good work.

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 Googles 20% rule and Atlassians FedEx Days, help companies attract and keep the best practitioners.

Unfortunately, not all companies are committed to providing a high quality software product. They arent 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 dont 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

doesnt 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


24/36

delivery to production, with all the practices needed to support that, will become the norm. Well 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 andnever learn anything new. There might not be a place with a desirable employer for anyone who isnt 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!

-

You can find Lisa Crispin at @lisacrispin and blogging on http://lisacrispin.com.


25/36

Mark has been in software development for over 20 years and an Agile practitioner since 2001. Introducing Agile methods one practice at a

time inside a small team. From 2006 2009, as an employee of Cognos, hes introduced Scrum to the organization and coached a number

of teams. As part of that process he designed a Test Driven Development adoption strategy and introduced of a number of practices to

support it.

As an independant Agile/Scrum Trainer and Coach (Agile Pain Relief Consulting) he has introduced Scrum to a number of organizations.

Marks research interests including the application of neuroscience to Agile software development and training. Mark is an Agile Editor at

InfoQ and has written dozens of articles on Agile topics. He also publishes a blog Notes from a Tool User.


Its interesting the fundamentals havent changed, but the diversity and attitudes have changed completely.

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 wont work here it only works web based companies, startups, or

whatever were not.


26/36

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 dont 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 peoples minds are open its a remarkable

simple process.

The problem is when start introducing Unit Testing (or worse TDD) and people will say: Wow thats tough, we really dont have time for

that. So frustrated was I with this experience that Ive written an article Technical Debt a Perspective for Managers just to explain the holes

theyre 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 isnt realistic.

The other problem happens with people who learn the mechanics without understanding the principles behind Agile/Scrum. For example:

some managers hold a daily scrum that is just a form of having the team report to them daily and runs 30 minutes instead of the


27/36

I wanted to be programmer since 6th grade, just after leaving the idea of being an astronaut. But for real it began in 2001 when I got my

first job in a small software house. It was the end of the first Internet bubble and of course we were writing portals. I was at the 3rd year ofComputer Science at Technical University of Wroclaw, Poland. Agile did not exist for us. We were surrounded by heavyweight processes like

USDP (Unified Software Development Process). The team was great, but the process was none. We just tried to code what the specs said.

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


Well I first learned about agile when I learned about unit testing (JUnit to be specific) and XP and it was around 2003.

XP was defining agile at that time.


28/36

We all focused on code quality and engineering aspects of that method. It was very close to developers. Scrum came later, along with more

team and collaboration oriented vision.

I think now weve made a full circle. Scrum has become mainstream. Kanban joined along the way, but I dont perceive it as a successor ofScrum, 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 weve 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.

What is the future?

I havent seen any breakthrough in thinking about Agile or software development in general yet. As it comes to the Agile itself I think that

after 10 years we start to understand all the mechanics better. We made many experiments, many organizations tried the transformation on

their own and now we know how to lead the change inside the company and our teams.

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 its time to finally focus on doing the right software and pay more

attention to customer needs.


29/36

Weve learned the rules of the game. Now its time to play for real. First role belongs to customer now. This is where we still have lots to

learn and discover.

-

You can find Marcin Niebudekat @tinypm and blogging on http://tinypm.com/blog.


30/36

Background

I started my career in the early 90s with BIS and then LBMS the original company behind PRINCE and was responsible for the first pre-

agile iterative and RAD methods at both of these companies. In the mid 90s I became a consultant and Certified Trainer in DSDM, and was

engaged by British Airways where I spent nearly four years managing the implementation of DSDM across their entire 5,000-strong IT

department. In so doing I helped British Airways to become the first large company to adopt an Agile method for all of their IT projects,

founded RADTAC and began learning about enterprise Agile transformation. During this period I was also asked to do some consulting on

the Heathrow Terminal 5 project and it was here in 1998 that I first started using Scrum and started my journey to become a Certified

Scrum Trainer. Since then I have helped RADTAC clients large and small become more Agile by employing the full range of Agile software

developmentapproaches including Scrum, Lean, XP, DSDM and the Agile/Open Unified Method.

How Agile has Changed

In the mid 90s the term Agile hadnt even been coined. Many consulting companies had their own RAD methods but DSDM, owned and

developed by a large consortium of IT supplier and user organisations, was the only standard method of its type. At this time the DSDM

Consortium had over 100 members, but those challenging and trying to move away from waterfall were very much on the bleeding edge and

in the minority. There was a real sense of shared community and pioneering spirit. Things changed immediately with the advent of Scrum

in 1998. I clearly remember Ken Schwabers first presentation to the DSDM Consortium I gave him a lift from Heathrow to the meeting! A

few DSDM practitioners, such as RADTAC, embraced the approach, but most viewed the new kid on the block with suspicion. I signed


31/36

the Manifesto and became a founder member of the Agile Alliance in 2002, but sadly since then I have seen precious little evidence of the

spirit of cross-method community that it espoused.

Over the last ten years, the overriding characteristic of the Agile movement from my perspective has been division,

tribalism and religious wars between advocates of the different methods, and between advocates of purist andpragmatic Agile ideologies.

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!

-

You can find David Hicks at @DaveHicksRADTAC and at http://radtac.co.uk.


32/36

Ive been working as CTO and Tech Lead for a couple of web startups in Germany. In these jobs, I transitioned multiple organizations from

waterfall or chaos to Agile and lean processes. In order to create real value at all levels of the organization, companies must employ a

combination of Lean, Scrum, and Kanban methodologies or processes. Its critical to optimize the whole rather than just software

development.


Agile ideas have been around for quite some time. A lot of great people applied Agile practices and thought models to their daily work

without calling them Agile. The Agile manifesto helped focus these ideas and created a more concerted approach. Since its inception, more

and more people begin to think in this direction and a set of repeatable working practices have started to converge to well structured

processes. Nowadays, I see Scrum and Kanban as the most widely known variants of Agile processes.

What is the future of Agile looking like?

The biggest challenge for the Agile community I see is to stop propagating the only truth in one specific Agile process variant. I think we

have to leave the turf wars behind and accept that only a mix of Agile practices will really increase the creation of customer value. Only if we

apply agile to our organizations end-to-end we can be successful in avoiding sub-optimizations in one area. And applying Agile to various

parts of our organizations (not onlyAgile software development), we need to make sure that we choose the right tool for the job. I think well

see more and more places where people apply e.g. Scrum for feature development projects, Kanban for maintenance or system


33/36

administration, and Lean tools like value stream mapping on the upper management levels. This mix has a great chance to really strengthen

our organizations and optimize the value creation chain so that we deliver more value to our customers.

-

You can find Matthias Marschall at @mmarschall and blogging on http://www.agileweboperations.com/.


34/36

Enterprise Adoption of Agile Development Will Not Be Easy

Agile software development is going mainstream. It has arrived in major corporations across the globe along with high expectations. This

sets up the inevitable a fall from grace.

My time in the software business is measured in decades not years. Ive seen many solutions to the problems of building quality software on

time. None have delivered on their promises.

In the 1990s 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!

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


35/36

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.

Lets 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 risksmuch 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.


36/36

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

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 wont be easy.

-

You can findVincent DAmico at @brainslink and blogging on http://damicon.com.

agile scout state of agile 2010 blog series

Documents