Inspection and adaptation are two of the pillars of the Scrum framework but all agile methods recognize the wisdom of Deming's Plan-Do-Study-Act cycle.
While the Manifesto does not explicitly reference the scientific method, it is implied in the value statement "Responding to change over following a plan" and in its final principle "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
Agile teams embrace experimentation in many ways.
Some of these relate to the product. Minimum Viable Products and Minimum Business Increments can be designed and run to test hypotheses about what we feel is valuable to customers at a macro level. Split testing and similar short feedback techniques might validate whether specific features should be pursued or not.
Some relate to the team's delivery process.
Both the Rational Unified Process and Disciplined Agile Delivery highlight the importance of proving solution architecture early and one effective means of doing this is through the design, construction and execution of experiments focused on quality attributes such as performance or flexibility.
Working agreements such as Definitions of Ready or Definitions of Done can be thought of as experiments to validate whether teams are able to efficiently complete work items and whether teams understand what complete means.
Ceremonies such as retrospectives help a team to identify delivery improvement ideas. Rather than assuming these ideas will help and implementing them on a broad scale, teams will run experiments to see whether these ideas actually show promise. For example, improving product quality through pair programming might seem like a good idea so a team might elect to try pairing on a subset of their upcoming work items and comparing the outcomes to those completed using their previous methods.
Spikes are another form of agile experimentation. Rather than losing significant effort in comprehensive analysis of a specific uncertainty, a short time boxed deep dive focused on learning which options might be feasible is often a better alternative.
So how could adopting this commitment to experimentation help those teams using a predictive life cycle?
Assumptions which have not been validated are a common source of project risks. While a team could wait for an assumption to be passively proven, wouldn't it be more effective to frame a critical assumption as a hypothesis and then design and run an experiment to get data to make the team feel more confident about that assumption?
Incorporating ongoing experimentation into the risk management life cycle might provide a more effective method of de-risking all types of projects.
While I was delivering a course on agile fundamentals this week, one of the learners in the class asked me how the mindset and behaviors normally associated with agile teams might impact or be impacted by culture. He suggested context (low or high) as a cultural characteristic which would influence the starting point for a team and which could then change as the team matures, but the same can be said for other cultural dimensions. (So thanks, Tony, this article is for you!)
Geert Hofstede's research into national culture identifies multiple dimensions which can be used to describe differences between countries. Some of these could be considered in addition to context when observing how such teams develop.
Understanding culture across these dimensions can be helpful for leaders such as agile leads and functional managers to interpret the behaviors they observe so that they can better support the development of high-performing teams.
One of the reasons for having small work items at the top of a product backlog is so the team is able to complete them within a short amount of time. This benefit applies regardless of whether your team is using an iteration-based delivery approach or has adopted a lean continuous flow-based approach.
But what are some of the other benefits of having small work items?
But before slicing our work items too small, we need to remember that size is just one of the criteria provided by Bill Wake when he came up with the INVEST acronym for assessing how good a story is. A work item which is too small might not be sufficient independent or provide value to a stakeholder.
But keeping these caveats in mind, good things come in small packages.
While it is usually Wally who openly expresses those thoughts which we normally keep to ourselves, Dilbert is letting his inner voice do the talking in today's strip. Let's imagine for a moment that Dilbert's co-worker is part of a cross-functional team which Dilbert is part of. Dilbert's response might seem unnecessarily blunt, but this behavior is not uncommon in those companies which place an undue emphasis on individual recognition or which don't require managers to actively solicit feedback from outside of their own teams.
While most of us would consider ourselves to be helpful, without some measurement and organizational encouragement our willingness to help someone is likely to be reduced by our need to finish our own work as we know the latter is what is measured.
In many organizations, functional managers are under no obligation to solicit feedback from others about their staff's performance. While these managers might ask for input from within their own team, they might be reluctant to contact those co-workers who report to other functional managers. If they evaluate their team members' performance purely on achieving functional objectives or on how they interacted with others from within their own team, they might not consider whether someone works well within a cross-functional team. While this type of feedback is certainly available from project or other functional managers in a matrix structure, the functional manager might not always be open to soliciting or acting on the feedback. When objective feedback from co-workers outside of a manager's team is a required component of formal performance evaluations, it encourages both managers and team members to look beyond the walls of their own silos.
It is also quite common to find generous enterprise-level budgets for individual recognition but not as frequently for team recognition. With strategic or large projects, a project manager might have sufficient influence to secure budgetary approval for team-level rewards but this is usually not the case on smaller initiatives. Without equal weighting given to both individual and team recognition, it is no wonder that team members will prioritize individual success over that of the team they are on.
We want team members to feel confident that if they ask for help from a co-worker who happens to report to a different manager that there is a strong likelihood that they will get it. We would like to encourage team members to be willing to slow down their own activities if it helps their team get ahead. But when environmental factors such as performance evaluation systems and recognition programs discourage such behaviors it can be difficult to build high performing cross-functional teams.
As weather gets colder, it is common to see squirrels digging holes to bury nuts and other food items to feed themselves when resources becomes scarce during winter time. But given the volume of nuts which are required to sustain squirrels through the long winter months and the large areas covered by an average squirrel, they often end up forgetting where they have buried all of their treats. While observing the little fellow I captured in the photo above, I was reminded that we are not so different from our furry friends.
Whether we capture lessons over the life of a project or wait till the end of a phase or the project as a whole, we frequently end up forgetting most of the lessons we have foraged.
Squirrels will eat a few nuts while they are in the process of gathering them. In the same manner, there will be certain lessons which we can implement right away.
But what of the remainder?
If we just store them in a repository or, worse yet, in standalone documents or distributed Wiki pages, we are no better than squirrels who have forgotten where they have buried their nuts.
Thankfully, unlike squirrels who are unable to invent and use GPS-based nut finders, we do have a few options:
Putting the "learned" back in lessons learned begins with doing a better job of learning from the lessons we have previously identified.