This action might not be possible to undo. Are you sure you want to continue?
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 -
Tuesday 10/26 – Tobias Mayer
Wednesday 10/27 – Derek Huether
Thursday 10/28 – Ken Schwaber
Friday 10/29 – Josh Nankivel (Video!) and Sara Broca
Monday 11/1 – Lisa Crispin
Tuesday 11/2 – Mark Levison
Wednesday 11/3 – Marcin Niebudek
Thursday 11/4 – Matthias Marschall and David Hicks
Friday 11/5 – Vincent D’Amico
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. You can find Tobias Mayer at @tobiasmayer and blogging on http://agileanarchy.wordpress.com/.
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 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. How Agile has changed in terms of Ideology It’s 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 of performance-based objectives versus learning-based objectives (ie. getting a passing score on a certification exam versus being a good manager or leader). Let’s recognize the 800 pound gorilla in the room. It’s called the Project Management Institute (PMI) and they have a credential called the PMP® (Project Management Professional). I’m not putting down the PMI. I am both a member, and as I mentioned earlier, a PMP credential holder. PMI’s 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 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 coauthored 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. You can find Derek Huether at @derekhuether and blogging on http://thecriticalpath.info.
I have been in software development for over thirty years. Prior to that, I was a deck officer in the merchant marine. Don’t 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. I’ve 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 was twenty-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?
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
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, I’m always looking for new methods, new ways of doing things to improve my daily life and the one of people I work with. How has Agile changed? 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 I’m 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.
The positive points are the proximity between the project manager and team being able to make decisions quickly and transparently. 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. You can find Sara Broca at @sara_broca and blogging on http://blog.quasutra.com
Josh submitted his State of Agile as a Youtube video! You can find Josh Nankivel at @pmStudent and blogging on http://pmStudent.com.
The State of Agile: A Tester’s 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, I’ve 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, I’ve 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 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. 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 wouldn’t want that? My hope is that all of these become good ways of developing software. We don’t 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 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! You can find Lisa Crispin at @lisacrispin and blogging on http://lisacrispin.com.
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, he’s 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. Mark’s 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. How has Agile changed?
It’s interesting the fundamentals haven’t 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 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 selforganizing, 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.” You can find Mark Levison at @mlevison and blogging on http://notesfromatooluser.com.
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 of Computer 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 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. How has Agile changed?
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.
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 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. What is the future? I haven’t 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 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. You can find Marcin Niebudek at @tinypm and blogging on http://tinypm.com/blog.
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 preagile iterative and RAD methods at both of these companies. In the mid 90’s 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 90’s the term ‘Agile’ hadn’t 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 Schwaber’s 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
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 and pragmatic 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.
I’ve 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. It’s critical to optimize the whole rather than just software development. How has Agile changed? 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 we’ll see more and more places where people apply e.g. Scrum for feature development projects, Kanban for maintenance or system
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/.
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. I’ve seen many solutions to the problems of building quality software on time. None have delivered on their promises. 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 highlevel 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. You can find Vincent D’Amico at @brainslink and blogging on http://damicon.com.