Enterprise Agile


Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 419 features our essay on eight quick hints on dealing with stand-up meetings on distributed teams. Distributed Agile teams require a different level of care and feeding than a co-located team in order to ensure that they are as effective as possible. Remember an update on the old adage: distributed teams, you can’t live with them and you can’t live without them.  

We also have a column from the Software Sensei, Kim Pries.  In this installment, Kim talks about the  Fullan Change Model. In the Fullan Change Model, all change stems from a moral purpose.  Reach out to Kim on LinkedIn.

Jon M Quigley brings the next installment of his Alpha and Omega of Product Development to the podcast.  In this installment, Jon begins a 3 part series on configuration management.  Configuration management might not be glamorous but it is hugely important to getting work done with quality.  One of the places you can find Jon is at Value Transformation LLC.

Anchoring the cast this week is Jeremy Berriault and his QA Corner.  Jeremy explored exploratory testing in this installment of the QA Corner.  Also, Jeremy has a new blog!  Check out the QA Corner! (more…)

Advertisements
Heads up!

Heads up!

A Scum of Scrums (SoS) is a mechanism to coordinate a group of teams so that they act as a team of teams.  SoS is a powerful tool. As with any powerful tool, if you use it wrong, problems will ensue. Six problematic implementations, called anti-patterns, are fairly common. We’ll discuss three in part 1 and finish the rest in part 2. (more…)

JMP

JMP

I use Microsoft Office, many of my clients use large ERP packages and last week I bought a highly functional math package to do data analysis. I would describe all of these as products that are refreshed over time by major and minor releases. As an outsider, the delineation of product and release is both easily recognizable and easily describable. However once you peel back the covers and dive into the inner workings of the typical corporate IT organization (broad definition that includes development, maintenance, support, security and more), how work is grouped and described can often be much more akin to a descent through Dante’s nine circles of hell.   Recently I sat in a conference room in front of a white board and challenged a group to identify how work was grouped and how the groupings related to each other. During the discussion we choose not to discuss the portfolio level within the organization and focus on the deliver functionality. The results followed a path that looked like a simple basic hierarchy running from programs, projects to sprints . . . except for the waterfall teams that don’t do sprints. This hierarchy  was crosscut by products and releases increasing the possible complexity of any particular scenario. As work is grouped together from sprints to program into larger and larger blocks additional layers of control are need to manage risk.

In Agile the smallest grouping of work is the sprint. In a perfect world, a team would accept work into a sprint where each story was independent and intrinsically motivating. Each piece of work would be its own big picture, however that scenario is at best rare. Most people are interested in knowing that they are helping build the Golden Gate Bridge, not just the left lane of a typical bridge on-ramp. We are more motivated when we believe we are doing something big. It is rare that a unit of work being delivered by a single sprint from a single team will require any scaling.

In most organizations, a project represents a grouping of work that most easily recognized. While the concept of a project is under-pressure in some circles (we will explore concepts such #NoProjects later) I haven’t sat next to anyone on plane that doesn’t describe their work as projects whether they are in marketing, sales, accounting, consulting or software. Projects and project accounting is firmly enforced in most organization’s finance and accounting departments. As noted in Projects in Agile, almost every organization has their own definition of a project. Interestingly, I was eating dinner with a group of developers and scrum masters recently when the conversation turned to the definition of project. A sizable group decided that any discrete task could be described as project. A task had a strart and an end and was goal oriented. From a grouping perspective, projects are typically an accumulation of sprints or releases in Agile. In more classic scenarios, a project can be described as one or more release into production. Any project that is more than a single team and a single team will require scaling to afford greater foresight and planning so that the pieces fit together in a coherent whole.

The definition of a release is widely variable. Releases can be subset of a project with functionality pushed to production, test  or into some other environment. Alternately a release could be a group of whole discrete projects that are moved into an environment together. The only common thread in the use of the term release is that it represents movement. Releases, other than in very uncomplicated environments, will always require coordination between development teams and operations, business and potentially customers. The larger and more complex the release, the more planning and coordination will be required.

Programs are groups of related and often inter-related projects or releases that are organized together to achieve a common goal. By definition programs are larger than projects and can be implemented through one or a large number of releases. Because they are larger and therefore more complex, programs typically require additional techniques to ensure foresight, planning and coordination so that all stakeholders understand what is happening and their role in achieving success.

A final grouping of work is around the concept of product. Building from the Software Engineering Institute’s definition of a software product line, a simple definition of a product could a set of related functions that are managed as a whole to satisfy a specific market need. Typically a product is developed through a project or program and is maintained through releases, projects and programs. Products should have a roadmap that provides internal and external customers guidance on the features that the organization intends to develop and deliver over time. Roadmaps are typically more granular in the near term and more speculative as the time horizon recedes.

As work is grouped from smallest to largest; from sprint to program or product added effort is required to organize and coordinate work. Increased levels of planning and coordination require additional tools and techniques in addition to the basics typically found in Scrum or Extreme Programing (XP). In the Agile vernacular, the need to for additional techniques to deal with size, coordination and planning is called scaling.

OLYMPUS DIGITAL CAMERA

The release planning event in the Scaled Agile Framework Enterprise (SAFe) is a two-day program-level planning event that focuses the efforts of a group of teams to pursue a common vision and mission. As we have noted, the event includes participation by everyone involved in the Agile release train (ART), participation is in-person (if humanly possible), occurs every 8 – 12 weeks and has a formal structured agenda.   The agenda has five major components:

  1. Synchronization.  This component seeks to get everyone involved in the ART on the same page in terms of:
    1. Business Context
    2. Product Vision
    3. Architectural Vision
    4. Technical Environment and Standards

Each of these subcomponents provide the team with an understanding of what they are being asked to do and the environment they are being asked to operate within. The flow begins by grounding the team the business context for the program increment (the 8 -12 weeks). Each step after the business context increased in technical detail.

  1. Draft Planning. Leveraging the context, vision, architecture and environmental standards, the teams develop a draft plan. We will explore the process in greater detail in a later essay, however this where the team breakdown the stories they will tackle during the program increment, breaks them down, exposes risks and identifies and minimizes dependencies.   Draft planning usually consumes the second half of the day. The Release Train Engineer will gather the scrum masters together periodically during the draft planning process to ensure teams are sharing dependencies and understand the direction each is heading.
  2. Management Review and Problem Solving. At the end of draft planning, any significant problems with the scope of the program increment, staffing or other resource constraints are generally apparent. After the majority of team has completed their work for the day the management team (including RTE and scrum masters) meets to share what was learned and make the decisions needed to adjust to the constraints. This is must be completed before the beginning of day two.
  3. Final Planning. The teams review the adjustments made during the during the management review the previous evening as a whole group and then break out into teams again to continue planning converting the draft plans into final(ish) plans. Plans are finalized when they are accepted by the business owners.
  4. Review, Re-planning and Acceptance. When the teams plans are finalized they are reviewed by the whole team, the risks are ROAMed, the whole team votes on acceptance (a form of peer review and acceptance), any rework is performed on the plan and finally a retrospective is performed and next steps identified.

The release planning meeting operationalizes a program increment. A program increment represents 8 – 12 week planning horizon within a larger Agile Release Train. The large scale planning event helps keep all of the teams involved in the ART synchronized. The release planning meeting might be SAFe’s special sauce.

Without a framework, the building falls.

Without a framework, the building falls.

Team-based frameworks, techniques and methods have dominated the discussion over short history of Agile as a named movement. Concepts like Scrum and Extreme Programing (just two of the more prominent frameworks) caught the interest of software developers and IT management for many reasons, including the promise of customer responsiveness, faster delivery rates, increased productivity and the implementation excesses of heavyweight frameworks, such as the CMMI. Excess of the later still resounds in the minds of many developers, process improvement specialist and IT leaders. The fear of excess overhead and administration has dampened the discussion and exploration of techniques to scale Agile to the address program level and enterprise issues.  In the past few years, three primary frameworks have emerged to vie for the heavyweight championship of Agile. They are:

  1. Dynamic Systems Development Method (DSDM). DSDM is a project delivery/system development method. Originally released in 1994, DSDM predates the Agile Manifesto and was one the frameworks that drove the evolution of lightweight incremental development. DSMD takes a broader view of projects and integrates other lifecycle steps into the framework on top of a developer lead Scrum team. The framework has been tailored to integrate the PRINCE2 (European Project Management Standard) as a project and program management tool. DSDM is open source. (http://www.dsdm.org/)
  2. Disciplined Agile Delivery (DAD). DAD is a framework that incorporates concepts from many of the standard techniques and frameworks (Scrum, lean, Agile modeling and Agile Unified Process to name a few) to develop an organizational model. Given that DAD was developed and introduced after the introduction of Agile-as-a-movement, DAD explicitly reflects the Agile principles espoused in the Agile Manifesto while reflecting organizational scaling concerns. DAD has been influenced and championed by Scott Amber (Disciplined Agile Delivery: A Practitioner’s Guide to Agile, 2012) and IBM. The model is proprietary (http://disciplinedagiledelivery.com/)
  3. Scaled Agile Framework Enterprise (SAFe). SAFe as a framework leverages Kanban as tool to introduce organizational portfolio management and then to evolve concepts to programs to project and finally to Scrum teams. SAFe explicitly addresses the necessity of architecture to develop in lockstep with functionality. As with DSDM and DAD, SAFe’s goal is provide a framework to scale Agile in a manner that addresses the concerns and needs to the overall business, IT and development organizations. SAFe is a proprietary framework that was originally developed by Dean Leffingwell and now is supported by the company Scaled Agile. (http://scaledagileframework.com/)

There is a huge amount of controversy in the Agile community about the need for frameworks for scaling Agile, as evidenced by shouting matches at conferences and the vitriol on message boards. However many large organizations in both commercial and governmental organizations are using DSDM, DAD and SAFe as mechanisms to scale Agile.  Shouting is not going to stop what many organizations view as a valuable mechanism to deliver functionality to their customers.

Listen HERE

Welcome to the Software Process and Measurement Cast 270.  The SPaMCAST 270 features my interview with Allan Shalloway. We talked lean, Kanban and SAFe (Scaled Agile Framework).  A great interview to end the old year and bring in the new year!

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Al is an industry thought leader in Lean, SAFe, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas. Al is a SAFe Program Consultant as well as a co-founder of the Lean Systems Society. Al has developed training and coaching methods for Lean-Agile that have helped Net Objectives’ clients achieve long-term, sustainable productivity gains. He is a popular speaker at prestigious conferences worldwide. He is the primary author of Design Patterns Explained: A New Perspective on Object-Oriented Design, Lean-Agile Pocket Guide for Scrum Teams, Lean-Agile Software Development: Achieving Enterprise Agility and Essential Skills for the Agile Developer. Al has worked in literally dozens of industries over his career. He is a co-founder and board member for the Lean Software and Systems Consortium. He has a Masters in Computer Science from M.I.T. as well as a Masters in Mathematics from Emory University.

For the next few weeks the Software Process and Measurement Cast will include a promo for the “Influential Agile Leader” events led by Johanna Rothman and Gil Broza.  Check out the full details at http://www.InfluentialAgileLeader.com

The Software Process and Measurement Cast has a sponsor . . .

ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars.  The Software Process and Measurement Cast receives a fee if you sign up using the URL in the show notes.  HERE

All revenue from our sponsors goes for bandwidth, hosting and new cool equipment to create more and better content for you!  Support the SPaMCAST and learn from the ITMPI!

The Software Process and Measurement Cast is a proud member of the Tech Podcast Network.  Check out the Software Process and Measurement and other great audio and video casts!  TPN:  www.techpodcast.com

Do you have a Facebook account?  If you do please visit and like the Software Process and Measurement Cast page on Facebook.  http://ow.ly/mWAgU

The Daily Process Thoughts is my project designed to deliver a quick daily idea, thought or simple smile to help you become a better change agent. Each day you will get piece of thought provoking text and a picture or hand drawn chart to illustrate the idea being presented. The goal is to deliver every day; rain or shine, in sickness or in health or for better or worse! Check it out at www.tcagley.wordpress.com.

The Daily Process Thoughts is my project designed to deliver a quick daily idea, thought or simple smile to help you become a better change agent. Each day you will get piece of thought provoking text and a picture or hand drawn chart to illustrate the idea being presented. The goal is to deliver every day; rain or shine, in sickness or in health or for better or worse! Check it out at www.tcagley.wordpress.com.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.”

NOW AVAILABLE IN CHINESE!

Have you bought your copy?

Contact information for the Software Process and Measurement Cast

Email:  spamcastinfo@gmail.com
Voicemail:  +1-206-888-6111
Website: http://www.spamcast.net
Twitter: http://www.twitter.com/tcagley
Facebook:  http://bit.ly/16fBWVContact information for the Software Process and Measurement Cast

One more thing!  Help support the SPaMCAST by reviewing and rating the Software Process and Measurement Cast on ITunes! It helps people find the cast.

Next:

The Software Process and Measurement Cast 271 features the essay from my re-read of the 7 Habits of Highly Effective People.  This book has made a huge impact on my life and the essay is a great way to start 2014!

Check out this episode