Agile at Scale


Listen Now
Subscribe: Apple Podcast
Check out the podcast on Google Play Music

The Software Process and Measurement Cast 522 features the return of Jeff Anderson.  Jeff returns to discuss scaling agile and getting to a minimum viable product. Many teams and organizations struggle with the concepts of scaling and getting to an MVP, Jeff provides advice for not going crazy!

Jeff’s Bio

Jeff is the President of Agile by Design.  Over the last decade, Jeff has played a leadership role on a large number of enterprise-scale agile transformations, providing program management, operating model design and change-management services. Jeff frequently blogs about and presents on lean and agile adoption, and is the author of The Lean Change Method, which guides organizations through the application of lean startup techniques. His mission in life: to help knowledge workers be awesome at what they do.

LinkedIn:  https://www.linkedin.com/in/thomasjeffreyandersontwin/

Website:  http://agilebydesign.com/

Twitter: @thomasjeffrey


Re-Read Saturday News
The Software Process and Measurement Cast and Blog crew is still on the road this week.  We will publish our thoughts on Chapter 7 next week. Please jump into the re-read of Bad Blood, Secrets and Lies in a Silicon Valley Startup by John Carreyrou (published by Alfred A. Knopf, 2018 – Buy a copy and read along!).   

Previous Entries:
Week 1 – Approach and Introductionhttps://bit.ly/2J1pY2t   

Week 2 — A Purposeful Life and Gluebothttps://bit.ly/2RZANGh

Week 3 — Apple Envy, Goodbye East Paly and Childhood Neighborshttps://bit.ly/2zbOTeO

Week 4 — A Reflectionhttps://bit.ly/2RA6AfT

Week 5 — Sunnyhttps://bit.ly/2AZ5tRq

 

Next SPaMCAST
SPaMCAST 523 features our essay on Story Points.  Story points are a tool to help teams manage their flow of work.  Unfortunately, story points aren’t always used properly and can create more problems than they solve.

We will also hear from Jon Quigley who brings his Alpha and Omega of Product Development to the cast.

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

The Software Process and Measurement Cast 439 features Alex Yakyma.  Our discussion focused on the industry’s broken mindset that prevents it from being Lean and Agile.  A powerful and a possibly controversial interview.

Alex’s Bio

Alex Yakyma brings unique, extensive, and field-based experience to the topic of implementing Lean and Agile at scale. Throughout his career, he has served as an engineering and program manager in multi-cultural, highly-distributed environments. As a methodologist, trainer and consultant, he has led numerous rollouts of Lean and Agile at scale, involving teams in North America, Europe and Asia, and has trained over a thousand coaches and change agents whose key role is to help their organizations achieve higher productivity and quality through the adoption of scalable, agile methods.

Alex is a founder of Org Mindset (http://orgmindset.com), a company whose mission is to help enterprises grow Lean-Agile mentality and build organizational habits in support of exploration and fast delivery of customer value.

Re-Read Saturday News

Chapter 2 of Holacracy tackles why the consolidation of authority is harmful to the ability to nimble, agile (small a), and productive organizations and secondly, why the distribution of authority supports an organization’s ability to scale.  The argument in Chapter 2 is a central tenant of Holacracy.

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads. (more…)

10358869_10203282385195091_1761744082221812386_n

Different sort of pyramid syndrome

A Scrum of Scrums (SoS) is a mechanism to coordinate a group of teams so that they act as a team of teams. Powerful tools often have side effects that, if not countered, can do more harm than good. There are several “anti-patterns” that organizations adopt that negatively impact the value a SoS can deliver. In Scaling Agile: Scrum of Scrums: Anti-patterns Part 1 we explored The Soapbox, The Blame Game and Surrogate Project Manager, which three typical anti-patterns. Two other common anti-patterns are the Three Bears and Pyramid syndromes. (more…)

Remember that while barnacles perform important tasks, such as filtering the oceans water, on the hull of ship they cause drag and reduce efficiency.

Remember that while barnacles perform important tasks, such as filtering the oceans water, on the hull of ship they cause drag and reduce efficiency.

The idea of a Scrum of Scrums (SoS) is fairly simple. A bunch of people get together on periodic basis to coordinate the work their team is doing with other teams. The SoS helps everyone involved work together in order to deliver the maximum value. The SoS typically use the daily stand-up or scrum as a model. The simplicity of the logistics of the SoS and the overall utility often leads to tinkering with the format to address other organizational needs. Four very typical additions include: (more…)

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

The Software Process and Measurement Cast 403 features our essay on Agile practices at Scale. Scaling Agile is a contentious topic.  Frameworks and techniques for scaling are often lambasted as semi-Agile or perhaps even backdoor waterfall techniques. Occasionally you still hear that if a piece of work is too big for one team to complete in a reasonable period of time it should be broken down or just not done. Rather than throw the baby out with the bathwater, many organizations have taken a more pragmatic approach and adopted techniques to scale Agile. We discuss the issues and some of the steps that can be taken to address them!

We will also have a visit from the Software Sensei, Kim Pries. Kim discusses making real transformations using his experience learning Tai Chi.  Kim points out that change like deep learning is not instantaneous.

Gene Hughson anchors the cast with an entry from his Form Follows Function Blog. We discussed his article titled,  NPM, Tay, and the Need for Design.  Gene points out that being forewarned is forearmed. While it has always been true, in today’s dynamic environment, an architect needs to be forearmed.

Re-Read Saturday News

This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 8 and 9.  Chapter 8 changes gears and provides advice on how to get started with XP.  Beck suggests that there is no single place to start for everyone. Where you start depends on where you are beginning.  Chapter 9 provides a list of corollary practices that build on the primary practices discussed in Chapter 7.  

Use the link to XP Explained in the show notes when you buy your copy to read along to support both the blog and podcast. Visit the Software Process and Measurement Blog (www.tcagley.wordpress.com) to catch up on past installments of Re-Read Saturday.

Next SPaMCAST (more…)

13632144484_53709f3df4_b.jpg

When the goal is complicated architecture, everyone needs to coordinate.

Much of the work to coordinate and synchronize goals happens during planning.  As Mike Cohn described with the metaphor of the Agile planning onion, Agile planning is not a one-time event nor are planning activities confined to the beginning of an increment or a sprint. However, delivering work using Agile is not just a big ball of planning. Goal coordination and synchronization activities need to happen outside of planning activities.  Several non-planning Agile techniques are useful for ensuring coordination.  The degree of usefulness is a function of size, complexity and the Agile maturity of those involved. The techniques include:

Test First Development (TFD) in all of its forms (including Test Driven Development, Behavior Driven Development, and Acceptance Test Driven Development) begins by establishing how the developers will prove the work they are planning to deliver.  Expressing how the solution will be proved before writing the first line of code anchors the functionality being delivered to the effort’s goals. All of the test first development techniques can be applied to any size project; however, these techniques require teams that have access to the correct tools and have at least a moderate Agile maturity.   

Definition of Done provides a team or teams with a set of criteria that they can use to plan and bound their work based on an overarching definition of done. A definition of done that includes integration activities or a check against the increment’s goal is an effective means of keeping goals synchronized. The definition of done is applicable to all efforts regardless of size, albeit as complexity increases this technique becomes even more powerful.

Continuous Builds is a process in which every time code is checked back into the code repository the application or product is built (or compiled).  The build is immediately followed by some form of testing to make sure the “build” still works.  Continuously building the software ensures that any one team or developer does not go too far off track because the code and testing act as an arbiter that the product works. This technique is applicable to all efforts (Agile or not, big or small); however, I have noticed that the use of continuous builds requires some experience and maturity with Agile.

Scrum of Scrums (SOS) is a mechanism that brings all of the Scrum Masters involved in an effort together to coordinate a group of teams so that they act as a team of teams. The SOS provides a platform for coordinating and synchronizing goals by ensuring teams are aware of what other teams are doing and whether they have had to make adjustments to the goals.  An SOS is useful for coordinating efforts of all size; however, as efforts scale past two or three teams other coordination techniques are needed in addition to the SOS. 

Demonstrations, also known as demos, are Agile’s mechanism to share what the team has been accomplished.  Scaled Agile efforts often have demos at the team level at the end of every sprint, an integrated demo (all teams) and then a larger demo before a release.  Demonstrations provide the ultimate proof of what has been built allowing stakeholders to determine whether the effort’s goals have been met. Demos are useful for every Agile effort.  Larger efforts will do demos both at the team level and then as a consolidated demo for the overall product.

Dynamic Testing (execution of the code), by definition, generates results that are compared against some expected result (even exploratory testing).  Those expected results represent an instantiation of the goals and objectives of the overall effort.  Testing, while important, without the structure of test-first development is a very weak tool for coordinating and synchronizing goals. Do not use this technique alone regardless of the size of the effort. 

Techniques for synchronizing special types of goals and objectives such as process improvement or technical goals are: 

Retrospectives are a platform for teams and teams of teams to examine their performance and to make changes to improve their delivery of value.  When an effort or organization has productivity, quality, and/or efficiency goals, retrospectives (using techniques such as the 6 Thinking Hats) are highly effective.  The retrospective provides a platform to share the objectives and then to synchronize on the steps needed to meet those goals and objectives.

Common Architectures and Standards are typically an instantiation of the technical goals and objectives of the organization. Efforts of all size can use a set of standards or a published architecture to effectively coordinate activity.  Examples of using an emergent architecture to provide guidance can be seen in the SAFe concept of the architectural runway.  The runway is “built” just ahead of the need of the teams generating the functionality that will leverage that architecture.

The effectively coordinating and synchronizing goals is a requirement for any effort, if the effort is going to deliver value efficiently. Agile efforts often use many of these techniques in combination.  Each technique interlocks and overlaps with other techniques so that an environment is created that supports team’s ability to self-organize and self-manage.   The number techniques and how strenuously they need to be pursued is a function of how many teams are involved, Agile maturity and complexity.  Conceptually an effort with two collocated teams and simple business problem to solve will need less goal coordination than an effort with many teams that are spread across the globe. The one absolute when it comes to goals and teams is coordination is always required.

Where are we going?

Where are we going?

As we noted earlier in this theme, coordinating and synchronizing goals across multiple teams is not a new problem. Solving the problem at scale requires integrating specific steps into how work is being delivered.  Building coordination and synchronizing steps work best if they are part of activities that are naturally designed to consolidate and disseminate information, while also avoiding the construction-related steps. Identifying the steps to coordinate and synchronize goals is a first step in scaling Agile.  The size and complexity of the effort will contribute to the selection process.  For example, delivering functionality from two collocated teams will need less overt goal coordination than an effort with twenty teams spread across the globe.  Because adding coordination and synchronization steps into the workflow may feel like overhead to individual teams, care should be taken. However, well-executed coordination will provide a significant payback both for the team and to the overall effort. The Agile planning mechanisms that are excellent tools for coordinating and synchronizing goals include: (more…)

Next Page »