You Are Here?

Assessments in agile come under a wide variety of names: appraisals, health checks, audit or even assessments. These terms are commonly conflated.  Assessments are a tool to prove a point. There are many approaches to assessing agile in a team or organization ranging from self-assessment questionnaires to formal observer-led appraisals. What gets assessed and the approach an organization chooses depends on the point of the assessment. All assessments create a baseline, a line in the sand from which to measure change.  At the same time, an assessment is a benchmark. Benchmarks are a comparison against a standard (real or implied). For example, an organization could use the principles in the Agile Manifesto or the framework in the Scrum guide as a standard to compare their behavior against to generate a benchmark. Put very succinctly, baseline defines where an organization (or team) is at a point in time, while a benchmark is a comparison to a standard. Assessments of any type, whether to generate a baseline, a benchmark or both, require time and effort which might be better spent creating a product, unless there is a good reason to do an assessment. There are three macro reasons why an organization might assess the agile journey that can generate value: (more…)

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

https://oembed.libsyn.com/embed?item_id=6969007

SPaMCAST 509 will feature our essay discussing if you can demonstrate incomplete work.  My knee-jerk reaction is no…or maybe heck no, but knee-jerk reactions are not always right.

Blog entries in the what happens to incomplete work theme:

Frequently Asked Questions: The Sprint Is Over, What Do I Do With Incomplete Stories? https://bit.ly/2P9mm09

Frequently Asked Questions: Can I Demo Work That Isn’t Donehttps://bit.ly/2wfJzXv

Frequently Asked Questions: Can I Resize A Story If It Is Harder Than We Thought?https://bit.ly/2MvkB0a

Frequently Asked Questions: When Can I Demo Work That Isn’t Done https://bit.ly/2PCs0Zz  

We will also hear from Gene Hughson (Form Follows Function). Gene talks Architects!  Gene and I discussed his essay, So what exactly does an Architect do? Contact Gene on LinkedIn – https://www.linkedin.com/in/genehughson/

Bringing the cast home this week is Jon M. Quigley.  Jon brings his marvelous Alpha and Omega of Product Development to the cast this week in order to discuss the root cause analysis. Process improvement is most effective when we diagnose the real problem rather than just a symptom.

Re-Read Saturday News

In week 5 of re-read of The Checklist Manifesto by Atul Gawande (use the link and buy a copy so you can read along) we tackle Chapter 4, The Idea. In Chapter 4 Gawande shows how checklists can help push decision-making outward, which empowers teams and makes them more responsive.

Current Installment:

Week 5 – The Ideahttps://bit.ly/2PCs0Zz (more…)

Exit Sign

Get Team Problems Out

Not every team issue can be solved with a standard pallet of techniques. However, nearly every consultant (internal or external) will have set of tools that they have ready just in case. The following is a set of techniques packaged as a model, or the very least in order of precedence. The techniques referenced in this article are often used as a group and are only deployed as a correctively after diagnosing the problem (root cause analysis). (more…)

No Mowing Sign

The Environment is Complex

Having been involved in the world of buying, building, maintaining, and testing software for many years, one of the longest running conversations between everyone involved with delivering value is the impact of complexity on cost, effort, quality and even on the ultimate solution to business problems.  The concept of complexity and the impact of complexity is unfortunately – complex.   The importance of developing an understanding of complexity is complicated by a lack of a crisp definition and a confusion of the topic with the concept of complicated.  The difference between complicated and complex is not a mere nuance; the distinction will affect the options we perceive are available to solve any specific problem.

(more…)

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

SPaMCAST 455 features our interview with Michael King.  We talked about Michael’s approach to Agile, process improvement and the CMMI at Halfaker and Associates.  Michael provides a glimpse into making a change in the real world.  Mr. King delivers more than just theory.  One word describes the interview – insightful.

Michael’s Bio:

Michael King serves as Chief Technology Officer at Halfaker and Associates (www.halfaker.com), leading customer solution architecture, internal IT operations, business process architecture, and quality management activities.  Michael has 14 years of systems engineering, project management, and process design experience within the Federal contracting industry.  He has previously served as Halfaker’s Chief Operating Officer.  Prior to Halfaker, Michael worked within Lockheed Martin’s Critical Infrastructure Protection group, providing system engineering support related to identity management, physical security, and cyber security.  Michael holds a Bachelors in Computer Engineering from the University of Virginia, a Masters in Information Systems and Technology from Johns Hopkins, and several professional certifications (PMP, PMI-ACP, SAFe SA).  Michael King writes about organization design, Agile, and process management at https://designinggreatorganizations.com.

Twitter: https://twitter.com/mikehking

LinkedIn: https://www.linkedin.com/in/mikehking/D

Re-Read Saturday News

This week Steven dives into Chapter 3 of Paul Gibbons’ book The Science of Successful Organizational Change.  This chapter has provided me several sleepless nights considering the difference between complicated and complex systems.  Understanding the difference is important making change happen, work, and stick!  Remember to use the link in the essay to buy a copy of the book to support the author, the podcast, and the blog!  

This week and previous installments: (more…)

3-29 2013 poop

Why do death march (gruelingly overworked and therefore high risk) projects still occur? While poor processes, poor estimation and out of control changes are all still factors, I am seeing more that reflect poor choices based on business pressure.  How often have you heard someone say that the end justifies the means?  It is easier to say yes to everything and avoid hard discussions about trade-off and just admonish the troops to work harder and smarter.

In Agile, we would expect backlogs and release plans to help enforce those sorts of discussions. Unless, of course, you stop doing them.  I recently talked to a group that had identified the need to do a better job of breaking accepted backlog items down into tasks during sprint planning (identified during a retrospective), only to fall prey to an admonition to spend less time planning and more time “working” leading to rework and disappointing sprint results.

As you discover messes, whether in the code you are working on or in the processes you are using to guide your work, you are obligated to clean up after yourself.  If you don’t, sooner or later no one will want to play in your park  . . . and  probably neither will you.

Sherbrooke Dam Wild Water

A few drips of water are fairly non-threatening. Rarely can a drip or two wash people or cars away or change the flow of a river. Constricting the flow of water harnesses a great deal of potential energy that when released can be used to generate power if it is run through a turbine or if released randomly the impact might be difficult to control.

Develop a backlog of potential changes and keep the list prioritized so that the effort you have to affect change can be channeled for greatest value. A backlog of process improvements is very much like the dam that collects the drips of water until it can drive the turbine of change. Like the dam if it is always collecting and never being relieved it burst and change will happen in a much less controlled manner.