ATSC Podcasts: Pragmatic Agility
Full podcast transcript enclosed below:
Slide 1 - Ken Clyne Background
Hello, my name is Ken Clyne and I lead the Office of Technology at Advanced Technology Systems or simply ATSC. Over the years I’ve had the opportunity to work on and with a diversity of software development efforts. I’ve always had a passion for improving the efficiencies and wok life balance of software development teams whether it is through better technologies, better languages, better methodologies or better processes. Over the last 10 years I’ve being helping customers adopt incremental iterative processes previously with the Rational Unified Process, but now more often with agile process frameworks such Scrum and OpenUp.
Slide 2 - A Pragmatic Approach to Agile Adoption
Today I want to talk briefly about agile practices, trends I see emerging in the industry and the need to take a pragmatic rather than dogmatic approach to agile adoption.
Slide 3 - Agile Manifesto
First, I‘d like to introduce or perhaps re-introduce you to the Agile Manifesto. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
These value statements represent common sense, thing that we ought to practice every day, yet rarely do. What differentiates the community of agile practitioners is their stated commitment to following the spirit of the agile manifesto. Unfortunately what I have observed is:
A - Sometimes we see people become to dogmatic about a specific implementation of the manifesto. A specific agile practice for example and fail to stay true to the first following statement (circle in slide- Individuals and interactions over processes ad tools) that favors people over process and tools
B - Many diminish the value of items on the right to zero (circled in slide- Working Software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan)
Slide 4 - Agile Principles and Practices
The original authors of the manifesto derived a set of principles. I’m not going to talk to them all, but let’s just pause a second to cast an eye over them (bulleted principles are listed one by one in the slide).
The notion of welcoming requirements changes even late in development is a profound difference for many, but without one exception perhaps none of the above principles are that radical. Cynics might even dismiss the principles as a set of platitudes and that would be true if there was not some meat on the bones.
Slide 5 - Example Agile Practices
There are many agile practices that prescribe technical practices supporting agile principles we outlined on the previous slide. Some of the best known are:
- Scrum
- DSDM
- Crystal
- FTD
- Extreme Programming (or XP as it is also known)
The graphic on this slide depicts the XP practices and here we do see approaches that when first introduced seem revolutionary or evolutionary such as test driven development, paired programming, continuous integration and the planning game. These and other practices are all well worth investigating as potential means to build a better development capability.
Slide 6 - Agile, Does It Work?
And as we can see from the data on this slide which comes from a survey done by Dr. Dobbs journal in 2008. As we can see from this data, projects do improve productivity, reduce cost, increase stakeholder satisfaction, and achieve better quality. Other surveys and our own personal observations and anecdotal stories support these findings.
Slide 7 - Agile Project Success Rates (%)
Drilling down o the data a little, we see that co-located agile teams are more success then distributed teams. This is hardly surprising, and one would expect co-located waterfall teams to also be more successful than distributed waterfall teams. Clearly if we can we should like to have co-located teams, but there are other factors that play such as economics, resource availability, also the many benefits to the individual and the environment of allowing employees to work remotely.
Slide 8 - Returns for Agile Projects
Let’s take a look at some of the success factors of agile teams vs. traditional teams. Agile teams are more able to adapt to changing business needs. Agile teams can deliver a product to market much faster than traditional teams. Agile teams reduce waste by deferring detail until it’s absolutely necessary and preferring conversation over detailed documentation. Agile teams are also more productive due to many factors, but in no small part attributable to their better communication and the greater degree of trust afforded them by their management team. Agile teams can also better predict time to market, because they are following an empirical rather than a definitive process and lastly agile teams deliver better quality software as testing on an agile project is an intrinsic part of the development effort, not an afterthought.
Slide 9 - Agile Rhetoric vs. Reality
On the downside there is a lot of rhetoric and inflexibility amongst many in the agile community to accept the realities of today’s business environment. Here are some of the examples:
- Rhetoric - Teams must be co-located
- The Reality is it’s often not feasible to co-locate teams
- Rhetoric - Let architecture emerge through refactoring
- The Reality is large scale development needs a firm foundation
- Rhetoric - Working software doesn’t require documentation
- The Reality - is regulatory environments require documentation and for very good reasons.
- Rhetoric - Unit tests describe design
- The Reality - Modeling helps understand complexity and enhance communication across the team.
- Rhetoric - Oversight stifles innovation and productivity
- The Reality - A certain amount of governance can be healthy to a team and an organization.
- Rhetoric - Highest priority is early and continuous delivery of value
- The Reality - Pure focus on early delivery can lead to later rework and instability
Slide 10 – Lean Principles
Because of the dogma surrounding agile adoption, I prefer to look toward lean software development as a better compass to keep on the right track. The term “Lean Software Development” was first introduced by Mary and Tom Poppendieck in a book of the same name. Lean software development is a translation of traditional role lean principals to better suit software development. Lean manufacturing is in turn derived mainly from the Toyota production system. The seven lean software principles are:
- Eliminate Waste
- Create Knowledge
- Build Quality In
- Defer Commitment
- Deliver Fast
- Respect People
- Improve the System
For more information on lean software development a great place to start is at the Poppendieck’s website, a link to which I have placed at the bottom of the slide.
Slide 11 - A Pragmatic Approach to Agile Adoption
So to sum up:
- Distributed teams can be agile, but need online tools to be effective
- Large scale development needs a stable architecture
- Modeling helps reason about complexity and improves communication
- Sometimes documentation is necessary, it may even be useful
- Phases and milestones anchor the process and provide critical checkpoints during periods of rapid evolution
- Risk management can help arbitrate between feature development and architectural stability
- Lean software development might be a better compass for your agile organization than agile dogma
Slide 12 - Ken Clyne Background
That’s it for me. Thank you for your time today. For follow-up questions please feel free to contact me. Best of luck and have fun out there. Bye bye.