Featured Whitepapers
- Apples, Oranges, and Acorns - All Agile Development Tools Are Not the Same
- One's Enough for Agile Application Development Management
- Requirements Management 101 – 4 Basics Everyone Should Know
- Tips on Requirements Traceability – Learn How to Control Change and Improve Quality
- Scaling Continuous Integration to Large and Distributed Teams
|
A misnomer is labeling a practice a “best” practice"; a practice is only best in the specific context in which it exists. My working definition of “practice” is: A practice is a common and adaptive approach for doing something with a specific purpose in mind. When “being” agile and applying a practice we are focused on value-added not the means. Figure 1.0 depicts candidate practices applicable to “being” agile.
Figure 1.0 - Candidate Practices When a team is “being” agile, one of the things they will do is self-organize & self-direct around practices; selecting one or more practice to apply to an iteration/sprint. The benefits of which are:
So, let’s take a closer look at two of these practices. Practice - Mastering the IterationFigure 2.0, Figure 3.0 and Figure 4.0 depict an iterative and incremental cycle.
Figure 2.0 – William Deming’s Plan, Do, Check/Study, Act – Quality Improvement Cycle
Figure 4.0 – Scrum Framework In all actuality William Deming’s quality improvement cycle of Plan, Do, Check/Study, Act is embodied in Scrum. When “being” agile, we work in sprints/iterations developing and delivering commercial or operational value incrementally. Iterative and incremental is time-specific/activity-based and product-specific/value-based. The term iteration is time-specific and activity-based while the term increment is product-specific and value-based. Being agile and applying iterative and incremental development puts the Product Owner (the business or customer representative) in the driver’s seat; communicating and collaborating with the team “what” is to be developed, delivered and deployed, with the Product Backlog serving as their steering wheel. This approach also puts the Development Team in the driver’s seat. While the Product Owner is responsible for “what” is to be developed the development team is self-directing and self-organizing around “how” to develop the system-software product; with the Iteration/Sprint Backlog serving as their steering wheel. Applying an iterative and incremental cycle is all about increasing the feedback loop, reducing waste, effectively and efficiently responding to change and delivering often, commercial or operational value.
The bottom line: delivering commercial or operational value early and often, giving ourselves the best opportunity to beat the competition to market, realize revenue and discover insights that we can use to help us improve. Practice - Three level planning
About the Author Russell Pannone is a systems-software development and delivery practitioner, facilitator, and coach specializing in collaborative and adaptive product (systems-software) development and delivery. Russell’s passion is to help people succeed. Russell has worked in the systems-software development and delivery industry for over 25 years in a variety of roles including developer, team leader, object modeler, data modeler, project manager, scrum master, process engineer, and instructor. He has led agile/lean product development and delivery projects and worked with clients in a variety of industries including state and local government, aerospace, mobile banking, insurance, energy, and telecommunications. Russell’s mantra is: “Do more listening and less talking while you plan a little, do a little, check/study value-added and adapt” Russell can be reached at rpannone@WeBeAgile.com
Set as favorite
Bookmark
Email this
Hits: 3729 Trackback(0)Comments (0)
|
| Last Updated on Monday, 22 February 2010 18:01 |
Agile Marketplace - Announcements and Special Offers
The Business Case for ALM Transformation
Are legacy systems holding your company back? Breakthrough these technical constraints with an open and scalable environment that meets your unique business need to transform. There is no reason to be locked into an obsolete platform. The output of a number of recent transitions from legacy systems, this is practical white paper shares lessons learned and illustrates how guidance and enablement can pave the way for change.
Download this Whitepaper


Vince Lombardi, one of, if not the greatest coach in football history, once said, “Practice does not make perfect. Only perfect practice makes perfect”.










