Today we have a guest post from Anthony Mersino. Anthony and I have worked together numerous times.  I respect his vision, wisdom and dry humor.

Many organizations create an organization to help with their agile transformation. Various names have been given to these groups. Two that I really don’t like are the Agile Center of Excellence and the Agile PMO. The name is not inconsequential. Here is why I think that establishing a Center of Excellence for Agile is a really bad idea.

The intent of a group like the Agile Center of Excellence is often described as ‘to promote agility in the organization’. That sounds like a good thing, right? What often happens is that the way they go about it actually inhibits agility. What frequently happens is that the Agile Center of Excellence (CoE) focuses almost entirely on standardizing processes and tools, and leveraging scale and efficiencies. What could go wrong? (more…)

Alternatives!

Three possible alternatives:

IFPUG function points. If you have to have a standards-based approach to sizing and comparison. IFPUG function points are the gold standard. IFPUG function points are an ISO standard and can be applied to all software types (technology agnostic). The drawbacks for using function points include the perceptions that there is a high level of overhead, counting requires too much information too early in the processes and that only highly skilled wizards can count (or approximate) function points correctly. None of these perceptions are really true, however, in some circles, the tar and feathering has stuck. (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.

Change Behavior To Change Value

Many teams find that story points only a partially useful tool to facilitate the flow of work within a team. As noted, story points are not all unicorns and kittens.  Can story points be fixed, or better yet can story points still be useful? On the whole, story points are inherently fine if they are used with discretion and structure to meet a team’s needs.  The words discretion and structure are code for “change”. Reforming the use of story points to make them safe again doesn’t require changing how teams assess or determine story points, but rather how people in the value chain behave once they have a number (or two).  An upfront agreement for using story points makes story points “safe.” Four attributes are useful to guide any upfront agreement on the usage of story points. The RATS criteria are:

Range – Express story points and story point metrics as ranges.  Story points are often used to express the perception of the size or value of work. Using a range to communicate both inside and outside the team mitigates the risk of falling into precision bias.

Approximate – Agree that story points represent a team’s best guess using the knowledge available at a specific time.  Knowledge will evolve as the team develops specific experience, does research and/the environment changes. Story points are not precise.

Team – Gather a team.  Story points are a reflection of a collaboration between multiple points of view. As a collaboration of a group, they can not be used to assess or measure an individual.

Separate – Separate the use of story points from answering client and management questions related to when a function will be delivered and how much that functionality will cost from facilitating the flow of work with the team.

Regardless of what a team uses story points to assess or to approximate the output of the process is a synthesis of thinking from a group of people.  Story points represent the thought process of the team that created them, influenced by the environment they operate within. Every individual on the team needs to understand the central thread of logic followed to generate story points; however, even on a mature team, individuals will have differences which further emphasize the need to establish a RATS-”based agreement on how story points will be used to ensure healthy behavior.

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

SPaMCAST 521 features our essay on user stories and legacy code.  A common question is how user stories can be developed for legacy code or for problems that crop up in production.  The implication is that creating user stories is too hard when dealing with legacy code changes or too slow when dealing with production problems.  User stories are a core tenet for most agile approaches.

This week we also have a visit from the Software Sensei, Kim Pries!  Kim talks about training in a column titled, “Software Catechism.”

Can you help keep the podcast growing? Here are some ideas:

  1. Tell a friend about the cast.
  2. Tweet or post about the cast.  Every mention helps.
  3. Review the podcast wherever you get the cast.
  4. Pitch a column to me. You are cool enough to be listening; you deserve to be heard.
  5. Sponsor an episode (text or call me to talk about the idea).
  6. Listen.

Whether you do one or all six, being here is a big deal to everyone that helps get the podcast and blog together. Thank you!


Re-Read Saturday News
The Software Process and Measurement Cast and Blog crew is on the road this weekend so we are going to take a day off from our 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!)   Today we re-visit an entry from 2013, In 2013 we ran a series titled “Motivational Sunday”. In this entry, we talked about the relationship between commitment and habits. I have tweaked the works a little but the sentiments are no different.

Habit and Commitmenthttps://bit.ly/2KbKq13 (more…)

Rewards Needed?

The Software Process and Measurement Cast and Blog crew is on the road this weekend so we are going to take a day off from our 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!)   Today we re-visit a blog entry from 2013,  In 2013 we ran a series titled “Motivational Sunday”.  In this entry, we talked about the relationship between commitment and habits. I have tweaked the works a little but the sentiments are no different. Commitment and habits can be positively interrelated. Commitment is being dedicated to a cause or activity.  Habits reflect a more or less fixed routine. The combination of commitment and habit is beneficial if the commitment is to a positive goal and habit does not become an obsession. Once it is established, the combination can go into autopilot. In my world, running reflects a positive combination of commitment and habit. (more…)

How did we get to this point!

Story points were originally developed as a metaphor to give a rough answer to the question of how much functionality could be delivered in a specific period of time.  The problem is that all good metaphors are eventually abused or, worse, people forget that the metaphor is a simplification and approximation of real life. Metaphors become reality.   Three basic behaviors of leaders and stakeholders in software development (broad definition) have lead the metaphor of story points to evolve into story points as measures — something they FAIL miserably at. (more…)