Michele Sliger is passionate about helping individuals in traditional software development environments cross the bridge to agility. Here, she shares insightful and unique answers to our 5Qs on agile.
Q1: Why use Agile methods?
Because it is the ethical choice. This is not to say that non-agile methods are unethical, nor is it to say that all agile teams are working ethically. Instead, this ethical choice is about embracing a method that is value-driven—both in the promise of providing value to the customers and in the promise of the ways we choose to work together to provide that value.
The Merriam-Webster definition of ethics is “the discipline dealing with what is good and bad, and with moral duty and obligation.” If we examine our moral obligation as software developers, our #1 task is to provide value to our customers. That is why we were hired, that is what the customers are paying for. We have a responsibility to deliver. Agile approaches provide a framework that enables frequent delivery of precisely what the customer needs, with as little waste as possible.
While we are obligated as professionals to provide a valued product to our customers, it should not be at the expense of those doing the work (or those supporting the people doing the work). This is our second obligation: to treat the team humanely. If we do not create and maintain an environment that allows the team to do challenging and fulfilling work, at a sustainable pace, then we are failing to treat these knowledge workers with respect. This also affects duty #1, in that an overworked, demoralized team may not be able to give their best effort at creating a valued and quality product. The Agile Manifesto and its 12 principles ( www.agilemanifesto.org ) provide a set of values that drive behavior in a positive and sustainable fashion.
Adhering to a set of values that drive positive collaborative behaviors and result in frequent software delivery helps us to work in an ethical manner. This is what agile is all about! If implemented correctly, agile is the most obvious ethical choice for any business.
Q2: Biggest challenge of implementing Agile methods?
Fear. And there are so many things to be afraid of! Here are some of the real reasons I’ve heard or experienced, and why agile adoption falters:
I’m afraid of change
I’m afraid I will have nothing to do
I’m afraid I will lose my job
I’m afraid people will see how little I actually do
I’m afraid I will lose my revered status and individual reputation
I’m afraid I won’t be able to keep up with my peers
I’m afraid I won’t be able to learn the new software or procedures
I’m afraid this will mean hard work
I’m afraid I’ll be fired if the decisions we make don’t work out
I’m afraid I won’t get raises or bonuses or promotions anymore
I’m afraid of conflict and of having to reach a consensus
Dang, there go my two-hour lunches
Dang, that means I can’t mosey in at 10:30 anymore
Dang, that means I’ll have to actually think now
Dang, that means I’ll actually have to talk to people now
It’s just so much easier and safer when someone else tells me exactly what to do
It’s just so much easier and safer when I can tell them exactly what I want them to do
Of course, these are just the beginning. Once a team gets past their initial fears, then they have a whole slew of strategic and tactical challenges. Things like getting the customer to participate, getting management to truly support the effort, and upgrading facilities and systems are common themes. These are directly observable and therefore surmountable problems. It’s the human element—fear, ego, conflict, and even sabotage—that agile change agents must address in order to smooth the transition.
Q3: In what environment will Agile be the most successful?
In an environment where the corporate values match the values espoused by the Manifesto and its associated principles. If there is a values mismatch, then agile teams will be limited in the amount of success they can achieve. Even if it appears that these values match, what a company says it values and what workers observe it values may be different.
For example, a company may state that they value their staff as human assets. Does this mean that the company realizes that its employees are the true deliverers of value in the company and should be recognized and respected for their efforts? Or does it mean that the company sees its staff as assets to be fully utilized (long hours) and replaced as needed? Another example: a company may say it believes in honesty and integrity, but the workers don’t find out that the company is almost bankrupt until it is too late, and then lose their pension and retirement funds.
It’s not about whether or not agile is appropriate for mission-critical (it is) or government (it is) or large complex projects (it is) or simple projects where the requirements are well known (it is). It’s about the number and types of roadblocks the teams will have to face and overcome. If there is a values mismatch, these roadblocks can become too frequent and too demoralizing to allow for a successful adoption of agile.
Q4: What is the future of Agile?
Agile will be like waterfall, in that it will often be implemented incorrectly and yet still have great staying power.
Agile’s staying power is rooted in its strong advocate base, and in its proven success stories. Agile’s iterative and incremental development is not a new idea. It is built on the ideas first espoused by W. Edwards Deming and subsequently manifested in the Toyota Production System. Although momentum took a long time to build, the movement to Agile will now continue to grow and gain acceptance. There is even an IEEE standard being drafted to outline the expected supplier-vendor relationship in an agile project!
However, like Royce’s waterfall model, it is easy to implement incorrectly. If you read Royce’s original paper ( www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf ) you’ll see that for decades we’ve implemented his model as drawn on page 2 of the document—which is the model that Royce stated “…is risky and invites failure.” It was his model of the waterfall on the last page, one that considers at least two iterations of the process and the involvement of the customer, which we should have been using all these years. I’ve witnessed the implementation of agile being similarly sliced and diced. Missing key agile practices, these projects have failed—and agile is blamed for the failure instead of its improper implementation.
With its focus on value, leadership, technical excellence, collaboration, and self-emergent social and product behaviors, agile is the holistic approach to software development that we need. It will be here for many decades.
Q5: Can you recommend a book, blog, podcast, website, or other information source to our readers that you find interesting or intriguing right now?
Bob Schatz’s list of recommended reading was excellent. I’ll add only a few more:
Joy at Work by Dennis Bakke. Not an agile book per se, but it is a strong advocate of a value-driven environment–one where it’s okay to have fun!
The Power of a Positive No by William Ury. Again, not an agile, book, but one that helps readers develop the fine art of saying “no,” a skill that will benefit you in agile (and everything else).
Ron Jeffries does a GREAT job of illustrating the difference between waterfall and agile in an InfoQ video. You don’t have to watch the whole thing–just scroll down and click on this section of the video: “So you talk about Running Tested Features…. Can you draw us a picture?” It’s only a few minutes and it’s very nicely done: http://www.infoq.com/interviews/jeffries-running-tested-features
I’ve written a few things about agile in the waterfall enterprise and relating PMBOK practices to agile practices: http://www.sligerconsulting.com/agile-sofware-development-article-presentation.htm
Also, some draft chapters of a forthcoming book for PMI adherents making the transition to agile: http://www.sligerconsulting.com/book.htm
About the Author
Michele Sliger has extensive experience in agile software development, having worked in both XP and Scrum teams before becoming a consultant. As a self-described "bridge builder," her passion lies in helping those in traditional software development environments cross the bridge to agility. Along with co-author Stacia Broderick, their forthcoming book, The Software Project Manager’s Bridge to Agility, focuses on that topic, helping PMI-trained project managers make the transition. Michele is a Certified Scrum Trainer (CST) and a certified Project Management Professional (PMP). If you have a question, or would like help with your agile adoption, Michele can be reached at michele@sligerconsulting.com .