Paul Holway's presentation to TDWI St. Louis at the 2014-06-13 "Agile" meeting. For more information, see @paulholway on Twitter on LinkedIn (https://www.linkedin.com/pub/paul-holway/3/985/443)
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
NOTICE: Proprietary and Confidential
This material is proprietary to Centric Consulting, LLC. It contains trade secrets and information which is solely the property of Centric Consulting, LLC.
This material is solely for the Client’s internal use. This material shall not be used, reproduced, copied, disclosed, transmitted, in whole or in part, without
Business involvement throughout the project Business participation on a daily basis helps ensure that business value is achieved by regularly prioritizing work based on business value,
by providing rapid ongoing feedback to the team on features as they are built, and by verifying that features provide the expected
functionality.
Empiricism and experimentation During the last 50 years of software development a lot of time has been spent upfront trying to figure out and lock down requirements,
design and test plans for an entire set of features. In agile development teams will become familiar with the agile concept that it’s better not
to think too deeply about each feature until it’s time to build them. In agile empiricism asserts that knowledge comes from experience and
making decisions based on what is known. In practice, this means that, as we build software, we also build experience so that we can
replace detailed up front planning and processes with just in time inspect and adapt cycles.
Build working software frequently within a short, fixed timeframe (i.e. timebox) Building working software means software that has been verified to work as it should in production. Teams will become familiar with the
agile concept of completing working software that doesn’t have all of the features envisioned but only those that can be completed during
the current timebox knowing that additional features will be developed during subsequent cycles.
Small team size As a general rule, smaller teams will tend to be more efficient and productive because communication overhead is reduced, there is less
unproductive waiting time and fewer handoffs. Within small teams, each team members skill-set will increase and broaden so that each
member can begin to be involved in more than one part of the software development process.
Transparency Open sharing of the state of the work will serve to encourage participation and to expose decisions, challenges and successes to the much
broader team. It means that decisions are made out in the open—subject to broader scrutiny, which in turn leads to better decisions and
more of a sense of ownership from team members. In addition, the transparency found in Agile practices will impart better visibility and a
greater sense of ownership to all stakeholders, encourage Close coordination and build mutual trust amongst stakeholders, and bring all
stakeholders on the ‘same page’ in terms of project progress and expectations
5/27/2014 www.centricconsulting.com 7
Agile is not only a development approach but also a mindset based on the principles of the agile
manifesto. To be successful with agile, there needs to be cultural a shift, not an imposed afterthought.
Below are just some of the paradigm shifts that take place when transitioning to agile.
5/27/2014 www.centricconsulting.com 8
Introduction: Agile vs. Traditional approaches
Agile Approach Traditional Approach
Leverage continual feedback to deliver business value as early and often as possible.
Invest in a detailed plan, and then execute on it.
Adapts to changing priorities through a continual feedback loop and iterative work planning.
Upfront analysis, requirements and design that “lock in” key designs early
Short, iterative design, development, testing, and deployment efforts.
Long delivery phases to develop and test software; working software is delivered at the end of a phase.
Project status is measured by the working software that is delivered.
Project status is measured against a detailed project plan.
Avoids painful change request situations by embracing new requirements as they emerge
Changes in requirements result in contentious change requests.
Established upfront cadence determines delivery date(s) and are based on consistent iteration and release schedules.
Upfront contract based on many unknown items specifies delivery date and project cost.
Architects the right solution – “end-to-end” development continually validates that a design supports the product’s features.
Long delivery cycles limit ability to introduce new functionality quickly as well as make architectural improvements.
Agile is not about IT or for the benefit of IT. Agile is about increasing competitive advantage for the business. Agile serves to address the needs of the customer impacted by ever-changing business climate, economic conditions and external regulations.
5/27/2014 www.centricconsulting.com 9
Components Of a Successful Agile Execution
Today, few technology managers or developers will admit to not understanding agile. The Agile Manifesto* serves as an excellent foundation, but we know there’s more to delivering on budget, on schedule, and with real people. In our experience, you need 4 things:
Many Agile transformations focus solely on the Agile process. But the technologies used to execute successful Agile delivery are equally important. Early Sprints need to define the technologies and the extent to which they will be used. Do not attempt to do this on the fly!
Organizational
Interfaces
Change
Management
Processes Technology
Practices
Components of a Successful Agile Execution
5/29/2014 www.centricconsulting.com 21
Beyond Process
A new process alone will not yield a truly agile organization. Depending on your organization and culture, several items about the way your technical team works will need to change.
- A focus away from component perfection into business unit value
- Embrace refactoring
- Move toward evolutionary design patterns
- Build Quality In
- Automate everything
5/27/2014 www.centricconsulting.com 22
Agile does not mean faster or with less quality. In fact, quality takes a larger role in agile.
-Quality is a first class citizen in the conversation. -Testing is included in the iteration
-Is this testable? How?
How will we perform regression as time goes by? The push for automation. Lack of automation is a major source of agile failure.
During an Agile transformation it is critical that Agile Teams provide information and feedback outside of their team in order to support other organization needs. Our approach recognizes these needs, and provides thinking and tools to support.
Components of a Successful Agile Execution
5/28/2014 www.centricconsulting.com 26
Components Of Successful Agile Execution – Organizational Interfaces
During an Agile transformation it is critical that Agile Teams provide information and feedback outside of their team in order to support other organization needs. Recognize these needs, and provide the thinking and tools to support.
5/29/2014 www.centricconsulting.com 27
What to do next?
Do not:
• Focus on Process only
• Let the simplicity of the philosophy be misintepreted
• Say, “we do that”
Do:
• Get an experienced coach
• Pick a pilot team/project and learn what works for your org