Company values, Yvan and Condacum

Last week we had a tem event. The first in 2 years, but it was a fruitful one. People learned to know each other, they were open and we enjoyed a lovely meal at Condacum.

Learning to know each other

We started with a small “learning to know each other”: the teams split up in groups of 2 and each colleague presented his  colleague in 1 minute after a 5 minutes preparation.

I had prepared more then 15 topics and the team chose the following agenda:

IMG_2671

Starting @Questio & Translucid

We embarked on how everybody started at Questio & Translucid. We shared the reason why we chose to start working here, what values made us to embark with our company and whether these values were still applicable. I had assumed 2 minute per person would be enough, but abandoned that idea quite early. Going with the flow was easier as I thought. The team was very open and we even learned from Raya, our entrepreneur why and how the 2 companies were founded.

Rewards and company values

Then I showed a small video on “Rewarding children”, a 6 minutes excerpt from the video A teal shade of Agile by Tobias Mayer. He thinks it is a myth that people are by nature keen on rewards. It is simply because we raised them like that (“Good girl” if you do something good). Since the parents raise (partially) their children, they can make children more independent and rely on their inner-self. From this video we talked about a new way of doing business, where the person is put central and not the organisation. By respecting your people and letting go of control, strange things happen in your company: happiness, pride, taking responsibility, personal growth, feeling involved, personal accountability and even better sales and profit.

But what about the client somebody raised, since we are all IT consultants, working 100% on a project with our client, some even working in scrum or kanban teams. Will they appreciate if you take each month 2 hours of to improve the communication within the team? Probably not, but if you explain sincerely and honestly why you do this, they might also be stung by the agile bee.

The conversation broadened, and we ended with this flip chart, containing company values that the team found important.

IMG_2672

Condacum and Yvan

The manager and self-made grower of old and special varieties of plants and herbs summarised our event smoothly, when he was showing his impressive vegetable garden at Condacum. He was very enthusiastic and inspiring when he told us about his crops, the passion, the life-work balance and how he adapted the strategy of his restaurant to the needs of what people really love in a authentic restaurant. His adagio is “Van Riek tot Vork” (from pitchfork to fork) and that was indeed what we tasted in the restaurant!

Geert

#Agile quote of the day

Strategy occurs organically, all the time, everywhere, when people play with ideas and test them out in the field. The organisation evolves, changes shape, expands and contracts in response to a collective intelligence. The reality is the great arbiter, not the CEO,  the board of directors or a committee. What works, gets momentum and energy inside the organisation. Other ideas do not take root and languish. “~ Fréderic Laloux

#Agile and #teal quotes of the day

“Annual planning, assuming that the plans work, trying to predict that plan, and trying to control it is the wrong way to run business.”  ~ Kreisler Ng

“Your competitors in your industry are disrupting the industry, so you are either on the disrupting wave or you will be shattered by the disruption wave.” ~ Mike Beedle

 “There isn’t any structural thing that needs to be in place; it is just a desire to work in a different way.” ~  Peter Green, about scaling scrum for the organisation

“If you have a leader who has the mindset that everything is predictable, and now [they] are just going to add some Scrum to that they are probably not going to be very successful using it because that is the wrong paradigm.”  ~ Peter Green and Richard Lawrence

“Applying agility to your organisation is not only applying the scrum framework but also working in cross-functional teams that deliver something valuable in the short-term. Cross-functional means that marketeers, r&d, purchasing, finance, it and all skills needed work transparently together to reach the short-term goal set.” ~ Geert Moreau

#Agile teams avoid all #documentation

One of the myths I have to bust frequently is that agile teams avoid all documentation. That’s just not true. Agile teams value written documentation, but believe that most projects benefit from writing less.

So, agile teams try to shift from documents to discussion. Even so, most teams find that some documentation remains helpful and necessary. So the question becomes, how do you tell which documents are helpful and which are not?

One way is to schedule a documentation-review meeting with the team. Prepare by printing out all the documentation from your current (or a recent but similar) project. For very lengthy documents, feel free to print just the first section or even just the title page. The point of this exercise is to show how much written documentation was produced and, to a lesser degree, to show the proportions in which it was created.

Next, sort the documents into stacks based on type: technical design documents in one pile, requirements documents in another, end user documentation in another, and so on. Then ask the team to sort each stack from the most frequently used on one end of the table to documents that were never used once they written at the other end.

Expect to encounter debate as the team works through this. One team member will insist a document was useful; another will say it wasn’t. Encourage the discussion, steering it whenever possible to help uncover things the team might not otherwise know. Note any documents that were intended for one purpose but used for something different and documents that you thought were essential but were not used at all.

Once the documents are in priority order, discuss which documents are helpful (and should continue to be produced) and which are not (and could be eliminated).

Then, see if you can take it one step further. For each type of document the team has agreed to continue producing, ask the team to brainstorm alternatives that involve talking more and writing less.

Again, I’m not suggesting you eliminate useful or required documentation. The goal is merely to help a team shift from documents to discussions. Taking the steps I’ve just described should help your team do that.

And that will help you succeed with agile,

Mike Cohn

If you want more of this, please subscribe to Mike Cohn’s email tips.

#Agile (long) quote of the day

As you probably know, the template I recommend for user stories includes a “so that” clause: “As a type of user, I want some goal so that some reason.”

Many of you have asked if this long form of a user story is really necessary—can’t we leave out the “so that?” The short answer is, of course you can. As a matter of fact, you don’t need to use the template at all if it isn’t helpful for you.

However, I do believe that understanding a user’s motivation is crucial to developing the right functionality for users. After all, users know what their problems are. They do not, however, necessarily know the solutions to those problems.

Let me give you a non-software example to illustrate. Years ago I was out of town working on a project. Because of some horrible pain on the left side of my stomach, I hadn’t been able to eat for three days. As soon as I finished the client engagement, instead of going to the airport to fly home, I went to the hospital.

I walked in grabbing my left side. By now the pain was intolerable. I told the nurse receptionist that I wanted to check into the hospital and have my appendix removed.

She told me she’d be happy to check me in, but she was pretty sure it wasn’t my appendix as the appendix is on the *opposite* side of my pain.

Essentially I’d shown up at the hospital with a story card saying, “I want my appendix out” or “remove appendix.” If a surgeon had delivered that feature request, I would have been no better for it and would have undergone unnecessary surgery.

I should have come into the hospital with a story of, “As a patient, I want my appendix removed so that the pain on my left side stops.” Saying why I wanted what I wanted helped the nurse and later the surgeon diagnose the real problem and deliver the appropriate solution.

Similarly, understanding a user’s reasons for wanting a particular feature can help a team deliver a more effective solution.

And that will help you succeed with agile,

Mike Cohn