Direct Playback

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

Listen on Spotify!

SPaMCAST 534 features our interview with Al Shalloway.   Al returns to the SPaMCAST after far too long. This week we discuss the trials and tribulations of scaling agile, and his passion about getting knowledge transfer right! I hope you have as good of a time listening to this interview as I had creating it.

Bio

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, 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 former SAFe Program Consultant Trainer. 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.

Website:  https://www.netobjectives.com/

Email:  alshall@netobjectives.com

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

Re-Read Saturday News
This week we continue our re-read of The Tipping Point by Malcolm Gladwell. Chapter Three of Malcolm Gladwell’s The Tipping Point is a reminder of why this book continues to be important and useful. The density of ideas in this chapter is amazing. Stop borrowing your best friends copy and buy a copy of the book for yourself!  

Current entry:

Week 4 – The Stickiness Factorhttps://bit.ly/2GuSJ96 (more…)

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.

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…)

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…)

Coordinate to achieve your shared goals.

Coordinate to achieve your shared goals.

Effectively scaling any methodology is a problem of establishing, coordinating and controlling the goals of each team that is working together to deliver a project or product. Clearly scaling any type of work is not straightforward.  At the very least, every new person and team increases the number of possible communication channels. The formula, n (n – 1) /2, is non-linear; a project with 2 teams has one channel while a project with 10 teams has 45.  Many Agile techniques were developed (or, at least, evolved) as team level, and don’t address goal coordination.  Scaling Agile requires taking a different tack than just adopting classic plan-driven methods and frameworks and putting them on top of team-level Agile.  (more…)

23019322592_fc9813ba56_k

Just because it is done, doesn’t mean it adds value.

In recent exchange after the 16th installment of the re-read Saturday of the Mythical Man-Month, Anteneh Berhane called me to ask one of the hardest questions I had ever been asked:

Why doesn’t the definition of done include value?

At its core, the question was asks how can we consider work “done”, if there is no business value delivered, even if the definition of done is satisfied including demonstrably meeting acceptance criteria. Is software are really done if the business need has changed so what was delivered is technically correct, but misses the mark based on the business environment today? This is a scenario I was all too familiar with during the 1980s and 1990s at the height of large waterfall projects but see less in today’s Agile development environment.  Anteneh Berhane’s question reminds us that the problem is still possible.  We discussed five potential problems that disrupt the linkage between done and value.  Here are the first two, and today we will discuss the second three. (more…)