collaboration

Agile Rituals Improved – Participation

Let’s face it; many Agile teams are disappointed by how much time they spend in rituals. But, it doesn’t have to be that way. In fact, it shouldn’t be that way. A team can take many actions to shrink the amount of time it spends in rituals while simultaneously increasing their effectiveness and fostering better engagement. Those actions tend to fall in one of two categories: participation and preparation. In this first of a two articles series, I am sharing a few examples of participation-related practices that have worked for me. A subsequent article will look more closely at preparation.

Note: despite some Scrum references, the tips can be applied to rituals from any Agile method. This article, therefore, assumes a certain level of Agile literacy. It does not describe the basics of the various rituals discussed.

Before changing anything, the first step is to ask the participants if they are satisfied with the current state of affairs. If there is no dissatisfaction, there will be no willingness to experiment with solutions. For the purpose of this article, let’s assume that someone has secured buy-in.

The first of the two principal causes of long, boring, ineffective rituals is the dearth of active participants. Here are some tips in no particular order:

Tip #1 – During grooming, don’t let the Product Owner do all the talking. A few days before the ritual, look for team members willing to learn a few stories/epics and take the first crack at answering questions about those during the ritual. A variety of presenters make for more energizing meetings. And you should walk away with at least one person who has a deep understanding of the topic because this technique is an embodiment of: “If you want to master something, teach it.”

Tip #2 – One of the surest ways to lose meeting participants is to have them wait on someone taking notes. This frequently happens in Scrum grooming and planning because the PO is trying to facilitate the meeting, describe the user stories, take notes, and update the backlog in real-time. To cure this, delegate tasks to the Scrum Master and any chickens present in the meeting.

Tip #3 – Story sizing debates derail many a Scrum planning rituals; is this story 3 points or 5 points? There are endless opinions. What participants frequently forget is that sizing is an exercise in estimation and that all estimates are wrong to some degree. Therefore, only the order of magnitude truly matters. For example, teams using the Fibonacci series don’t have to agonize over whether a story is one size up or one size down. The key is to limit the debate to arguments that are likely to sway the estimate by a lot.

Tip #4 – In every group meeting some conversations devolve into back and forth between two or three participants while everyone else waits. To snuff this, devise a mechanism where the crowd signals its desire for the conversation to stop. For example, people can raise a hand, and when two or more hands are up, the debate has to pause while a check for relevancy is performed. In short, don’t let the audience be victimized; empower it to self-regulate.

As a leader, bad meetings are just too expensive; there is the immediate cost of wasted time and the longer cost of reduced employee engagement. Moreover, group meetings are a golden opportunity to influence the organization’s culture. Servant leaders have a responsibility to work toward ameliorating the environment (see the article on the role of the manager). Some of the tips above may be useful in that pursuit. What other tips do you have?

Works cited

“Citizenship”, by Alberto Miranda, The Noun Project, Web. 30 Mar. 2016.  Modified.

Maximizing the Contribution of Contractors and Consultants

When an organization lacks a required skill set, contractors or consultants are often hired temporarily. This temporary staff augmentation is generally difficult to pull off successfully due to the imperfect context sharing, potentially divergent incentives, the uneven power distribution of the client-supplier relationship, and cultural impedance mismatch among others factors. Nowhere is the effect of these factors more evident than when the hiring organization operates with the Agile mindset. Under those circumstances, I’ve had most success when I remembered to do three things: heed legal advice, use higher-level contracts, and treat them like employees.

Don’t Go It Alone

First, a disclaimer: I am not a lawyer; implement the opinions below at your own risk. Whether a worker is legally deemed an employee as opposed to a contractor can have important consequences on an organization. A worker’s status may impose constraints on the management style – I use “management” in the broadest possible sense – you can use with the person. Based on the evolving legal landscape, the distinction is evidently not easy to make. So on this front, please get legal advice and heed it.

Bound By Contract

Second, I have observed that how the contract is written will influence the type of collaboration I can expect. Contracts that are higher-level or about the work method (i.e. meta contracts) seem to enable a level of flexibility critical to Agile collaboration.

If a contract is very detailed about the problem to be solved, the artifacts to deliver, and the timeline and milestones to achieve, then the other party legally bound to do exactly that. This can be problematic in the face of dynamic business conditions. For example, if new validated learning dictates that the whole project should pivot, the choice is then to let the contractor plow in the now invalidated direction or renegotiate the contract. Both are unappealing choices. This is why I prefer to write Statement of Work (SoW) that are less specific about the work, but more explicit about the method. A high-level description of the problem area the people will work on feels sufficient. I prefer to put my energy on getting an agreement how the work will be attacked. This can be a flavor of Lean, Agile, etc. Ideally, this agreement is reached with both the decision makers and the people that will actually get the work done. Yes, this removes a layer of legal protection. And yes, it relies a lot more on trust. But that’s a bet with odds that I, as a leader, can influence.

Execution

Third, with the paperwork out of the way, it’s time to turn to the doers. Whenever possible, I try to forget which organization the people working on my project come from. People are people. If the established motivating principles of self-organization, face-to-face collaboration, and empowerment are important to employee-type humans, then they also apply to contractor-type humans. Unless there are legal or operational constraints this not only means full integration with employee teams and squads, required access to strategic and tactical information, and participation in appropriate meetings and social gatherings, but also colocation, feedback, conversations and personal interaction with managers.

So by limiting the objectification of workers, trust is often increased and the organization can be a more productive and enjoyable place to work for everyone. Consequently, companies the organization contracts with finds the business collaborative and easy to work with. This motivates them to send their best people.

Collaboration And Results Over CYA

The best statements of work are often flexible and adaptable to changing needs, even with the legal implications or limitations this often imposes. Traditional contracts far too frequently create inefficiency and unproductivity. A supplier who insists on traditional, hyper-detailed work output contracts that limits collaboration may be one to avoid. I will certainly continue to be discriminating. I encourage you to be too.

What Are The Benefits Of Agile?

. . . or Lean, or whatever one may wish to call the discovery mindset? My thoughts on the benefits an organization stands to gain by going through an Agile transformation have evolved over time. I’ve come to believe there are benefits on multiple levels. Awareness of them helps me focus on the prize and become a more effective participant, coach, and leader. Here are some of the benefits I have witnessed first-hand.

Effectiveness

When I first experienced Agile, I was a participant in a Scrum team. My initial reaction was that we were going to be a lot more effective at our job. With better communication, a focus on a common goal, and more frequent validation of our wares, there would be less wasted time and fewer self-inflicted reworks. And so it was.

Money

Over time, the organization got better and faster at cranking out products and services through a more flexible, more collaborative workforce, and I concluded that the transformation was about more money for the corporation. We were operating with a higher level of quality, so better financial results were indeed part of the equation.

Customer Intimacy

After better internalizing the “customer collaboration” aspect of the manifesto, we developed outstanding relationships with customers. We had a stretch of more than a year when we did an end-of-sprint demonstration to one or more customers without exception (See this post for tips on making demonstrations happen). At one such demonstration, a customer asked if she could purchase the product right then, about three months prior to our expected release date, because it met her needs! It then dawned on me: this new mindset is really about delivering customer value. Better financial results are just a trailing consequence.

Fun

Later still, as the rest of the leadership team and I evolved our main management paradigm, I started to piece together a different picture. There was a lot more energy in the office. Employees had taken control of their physical space, work tools, and organization. People from far-flung divisions wanted to join us just for the sheer fun of it. It felt like a much happier place, driven by intrinsic motivation. And since plenty of research suggests that happier employees lead to more successful organizations, I began to think that a perfectly valid reason to pursue such transformation is the pursuit of happiness.

Effectiveness, financial rewards, customer value, and happiness all seem like valid reasons to start down the path of a transformation. In fact, I think they all co-exist to some degree. Have you found something else? What is driving your transformation?