Month: August 2017

I&A Series – “Being assigned features after planning before the PI is complete”

I am starting a new series of posts where I will answer some actual problems/ideas presented in an I&A problem solving workshop as part of open space facilitation. This is the first of a few dozen that I plan on covering. If you have any comments, please, let’s learn together.

 

Problem/Idea #1:

 

“being assigned features after planning before the Program Increment planning (PI/PIP) is complete”

 

A SAFe Answer

From a SAFe (and Scrum/Agile/Kanban) perspective, features (or stories) should never be assigned to a team. This is a common anti-pattern/fragile action that occurs during the early stages of cultural change where people are learning to let go of their theory X selves and dismantle the old belief system that people are dumb oxen that must be led by a bridle.

Continue reading “I&A Series – “Being assigned features after planning before the PI is complete””

Advertisements

The SAFe® System Team is an Anti-Pattern

In response to an interwebs blog… “The SAFe® System Team is an Anti-Pattern”

No, it isn’t actually. Let us explore why.

The blog post includes some analysis that clearly misses the point that Dean makes with regards to Systems Teams in the SAFe®.

We could consider the “ART” construct in SAFe® is a complex adaptive system (CAS) in of itself in some ways. But the intent is still to reduce complexity and improve business outcomes in a social construct with feedback loops. In this, the construct is quite effective. The goal should still be a simple adaptive system.

From Scaled Agile®:

The System Team is a specialized Agile Team that assists in building and using the Agile development environment, including Continuous Integration, test automation, and Continuous Deployment. The System Team supports the integration of assets from Agile teams, performs end-to-end Solution testing where necessary, and assists with deployment and release.

Read more at: http://www.scaledagileframework.com/system-team/
Copyright © 2010-2017 Scaled Agile, Inc.

In an ideal SAFe® implementation the “Systems Team(s)” are part of (baked-in) the team of teams (Agile Release Train [ART]) and self-organized around a DEVOPS mindset and mechanics (see the SAFe® CALMR approach). An ART should be cross-domain capable (aligned with the strategy of the product/organization) consisting of domain purposed teams that are themselves cross-functional. For many organizations, this is a giant leap in structure, HR, and policy & procedures. None-the-less, this DEVOPS concept is the best known best practice for many IT/IS/Software [enterprise scale] shops struggling to remove dependencies and destroy the massive inefficiency of silos (that also destroy morale).

If you can’t do true DEVOPS then at least allow the people who do the work to self-organize into domain purposed Systems Teams in the ART. Enterprises usually have enough of these type of resources to make it happen easily. Remember the anti-pattern of fractional assignment. Don’t move the people around fractionally. Always allow people to self-organize at 100% allocation to a team. In fact, it is a bad move to push people around to the work in general when there is complexity and uncertainty in your business. Let the work flow to, around, and from the teams of teams.

Don’t blame the guidance for poor implementation, poor coaching, or toxic players.

Other Thoughts

A scarcity of resources or strategy can result in systems teams being “on the spanning pallette” meaning they support the entire portfolio in a SAFe® implementation (but are not specified in an ART). I actually hope that in the next version of SAFe, the methodologists and fellows clear up the confusion about systems teams by moving them completely off of the spanning palette and onto the program level. The remaining scarce resources actually fit more logically into “Shared Services” in the SAFe construct.

Shared Services represents the specialty roles, people, and services that are necessary for the success of an Agile Release Train (ART) or Solution Train but that cannot be dedicated full-time.

Read more at: http://www.scaledagileframework.com/shared-services/
Copyright © 2010-2017 Scaled Agile, Inc.

It is interesting to get into discussions about tribes, chapters, guilds, and squads (spotify). The idea of formations from OrgMindset is even more interesting as a concept with SAFe as a more fluid and dynamic approach at enterprise scale.

Don’t let your biases and assumptions get the best of you

There will always be anti-patterns/fragile potential if the principles and value systems proposed are not in play in the social and cultural construct. Systems Thinking must apply too.

 

 

References

Leffingwell, Dean, and Donald G. Reinertsen. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2012.

Leffingwell, Dean. “Scaled Agile Framework – SAFe for Lean Enterprises.” Scaled Agile Framework, Scaled Agile, Inc., Jan. 2018, www.scaledagileframework.com/.

Kniberg, Henrik. “Spotify Engineering Culture (Part 1).” Labs, Spotify, 20 Sept. 2014, labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/.

errata: Tevanlinna, Antii. “The SAFe System Team Is an Anti-Pattern.” Anttitevanlinna’s Blog, 18 May 2017, anttitevanlinna.wordpress.com/2015/03/05/the-safe-system-team-is-an-anti-pattern/.

 

First vlog – ever – inspired by Jem + coaching tip

So, Jem D’jelal asked, “Would it be more entertaining to see sharing of 10 years worth of ScrumMaster journals as blogs or short vlogs? User feedback please!”

I was inspired by his question this afternoon on the drive home. I thought I’d have a little fun. Share my opinion in an entertaining way and also offer my first ever vlog and coaching tip of the day. Hopefully, I’ll learn something about vlogging.

I have 0.59 seconds into the video, five minutes of editing and uploading, and ten minutes writing this post. I can shrink the time box to ten total minutes I’m sure after a few more experiments.

Now, all I need are IDEAS. Please send the requests and I’ll do my best to give you answers.

Disclaimer: I do not enjoy watching or listening to myself on video. I’m terrified at how all of you will react. I had turned on video capability on my blog months ago. Honestly, I have a lot of fear about doing this. Today, I’m inspired. Thank you Jem.

Here it is… please give feedback. Nicely if possible.

Lego product development simulation game

Enhancing the understanding process by simulation of cadence and ceremonies. A very valuable teaching technique. Still experimenting with how to effectively integrate into various courses.

#SAFe #Scrum #Agile #Lean

Tushar Paunikar: You Always Have A Choice!!!

Reblogged with permission from Tushar Paunikar, the original author of
 this content, as a contributor to blogagility.com. Originally published 
on LinkedIn August 3, 2017.

 

You always have a choice! If you think about it, you always have a choice. No matter how hard it is to accept, but you always have a choice.

The alarm goes off at 5 AM! You have a choice.

Not feeling too upbeat to go to work? You have a choice.

Bored with the daily mundane tasks you are required to perform at work? You have a choice.

Disillusioned with the state of affairs of the current government? You had a choice. Rather you will again have a choice.

Continue reading “Tushar Paunikar: You Always Have A Choice!!!”

Tushar Paunikar: Agile and the KRA Conundrum

Reblogged with permission from , the original author of
 this content, as a contributor to blogagility.com. Originally published 
on LinkedIn, November 22, 2016.

 

Life can be pulled by goals just as surely as it can be pushed by drives. -Viktor E. Frankl

Metrics drive behavior. I bet all would agree. We have experienced this umpteen times in our professional life. Even our personal life is abundant with examples where metrics influence people’s behavior.

If my kid has the target to score an ‘A’ in Math and that target is linked to a new bike, he will try to find insincere ways to achieve his target, if he sees his attempts to study sincerely may not be fruitful.

If a developer has the target to maintain 80% code coverage and that target is linked to a quarterly Most Valuable Player award, (s)he will try to find nasty ways to increase code coverage, if (s)he sees that all attempts to write meaningful unit tests may not meet the project deadline.

Continue reading “Tushar Paunikar: Agile and the KRA Conundrum”

Srinivas Garapati: The Agile, Framework, and the challenges.

Reblogged with permission from Srinivas Garapati, the original author of this content, as a contributor to 
blogagility.com. Originally published on LinkedIn, June 28, 2017.

Introduction

Scrum and other agile frameworks may be easy to understand, yet prove extremely challenging to implement – especially in any large organizational environment. Why is that so? The following metaphor is an attempt to explain the difficulty. Every metaphor is imperfect, but we will try to give a gist of the challenges involved.

We apologize should anyone feel offended, and this is not to disparage the great work that everyone contributed to the agile movement. The knowledge and great learning that we have accumulated over the years would not have happened without this journey through the Agile manifesto.

What’s a framework?

Continue reading “Srinivas Garapati: The Agile, Framework, and the challenges.”