“Large IT Governance Committee” hack

Observation: 

In an effort to reduce tool license fees, the IT governance committee is not only hounding developers with endless surveys, the department is threatening developers that their tools will be removed if surveys are not promptly being responded to.

The tension:

The tone of the emails is one of coercion. A similar tone is used while dealing with 2 year olds: “If you do not play nicely you are a bad boy, and your toy will be removed.”

How Frank exposes the tension:

One guy (lets call him Frank) in a team took offense at the emails, responding with

“Dear IT Governance Team, 

I certainly hope you will not cut the access to my tool independent if I answer the survey or not. Please note when I read this I feel someone has coerced me.

Thank you,

Frank

How Frank exposes the crack:

One would think that the threatening emails would stop, however they continued, targeting Frank in particular (and yes, including the red font and underlined text.)

“Warning Frank!

If you DO NOT respond to this survey we will assume that you do not need access to a tool of this type.  A future automated  client software check will remove unregistered instances of these tools.

 

REMEMBER: If you DO NOT respond to the survey it will be assumed that you do not need any database tools.

 

R&D IT Governance Team”

The art:  

Our hero Frank responded with a “copy-all” email to the IT Governance team, the entire development staff (2,000+)  initiating a barrage of similar “code emails” back to the IT Governance Team eventually causing the surveys to stop:

From: Frank
Sent: Wednesday, April 10, 2013 10:05 AM
To: IT Governance committee
cc: All
Subject: RE: REMINDER: R&D IS Database Tool Survey

 

cat “
boolean hasbeenagoodboy = hasCompletedSurvey(me);
boolean needsqltool = hasSqlToolInstalled(me);
int i_am_ok=0;
int no_more_sql_4me=1

 

if (NOT hasbeenagoodboy AND needsqltool) then
  goto YOU_WILL_BE_SORRY
fi
if (NOT hasbeenagoodboy) then
  needsqltool=false;
  goto YOU_WILL_BE_SORRY
fi
exit(i_am_ok);

 

YOU_WILL_BE_SORRY:
print ‘WARNING !  says you will be sorry!’
delete(sqltool, me);
exit(no_more_sql_4me);

| translate style=“optional”

int i_am_ok=0;
boolean needsqltool = hasSqlToolInstalled(me);
if (needsqltool) then
  pleaseCompleteSurvey(me);
  print ‘thanks’
fi
exit(i_am_ok);

$

The result:  

As the development staff was cc’d, this initiate a barrage of similar “code emails” back to the IT Governance Team eventually causing the surveys to cease.

This post has been anonymously submitted.

Measure Flow Will Increase Trust and Collaboration

I hear more and more stories where Kanban has helped team to develop a continuous improvement culture. During 2012 the Kanban Leadership Retreat in Austria Mayrhofen, Pawel Brodzinski hosted an open space session dedicated to behavioural changes. The picture above was taken during this session. As Pawel explains in his blog post, we shared stories about emerging patterns from our Kanban experiences.

My goal here is not to cover all those patterns again, which mainly are still a work in progress, but to share a specific story about measuring flow.

In 2010-2011, I was in charge of a software development team located in Paris and Mumbai. We had several activities on our hands: business analysis, development, test and functional support. We were using the Kanban method to guide our collective work and our work improvement. We experienced most of the behavioral changes listed above and our cycle time was reducing. But we reached a limit: we were depending on a technical support team. They were not focusing on their lead time, they used a tasks management tool focusing on who is responsible for what and managing queues without limit or flow measurements. We were also not satisfied with the way we all were working and coordinating our clients. Thus one day we decided to automatically measure their Cumulative Flow Diagram (CFD) and make it visible. The average lead time was around 10 days for one very simple request.

At the beginning they were ignoring measures, just looking at odd graphs. But one day they had turn-over in their team, and as the new joiners were being trained, and the CFD showed immediately a bottleneck. We raised the point to them, our clients were very dissatisfied and at the end, our clients were also their clients. Without any explanations they immediately understood that the situation was critical, without even taking the time to explain anything, they started to make decisions and take actions. We already had experienced this kind of situation in the past without measuring flow (CFD) and it needed from us hours of negotiations, emails and escalations.

Since that moment the CFD became their own tool and they started to smooth the flow, without having been trained on Kanban and other stuff. We helped them to identify that they had to process 4-5 requests per day to keep the queues under control. It fully changed the way we interacted with them, it was not them against us any more, we all were focusing on flow, and measuring flow, trying to get things done in short lead time.

Lead time and flow were our common focus. Before that we were chasing the team to get things done, after that we were collaborating to better serve the client. Every morning both teams were looking at common metrics, agreeing on the 4-5 tickets to get done. More than that it also developed a serious gaming culture, where the team was playing at trying to reduce the queue as much as they can. Everyone was very confident with the process, and a high trust in the process emerged. We reduced the average lead time to 1 day!

 

That’s one hack introduced by Kanban: measure flow and you’ll see better decisions in the process, decreased negotiation and high social capital.

Firehacker

Our whole R&D team, around 80 people, were actioned for an all-hands-on-deck “operations” meeting, lasting 4 hours.  This is a mind-numbing meeting where each development team member would have a representative stand up and recite a 4-quadrant charts, “red” “yellow” or “green” status, issues, gantt chart changes, in poke-me-in-the-eyeballs-with-a-needles  boring details.

The tension:  This was a three-fold aspect of tension:

  • Everyone had to be pulled away from their work..nobody likes this.
  • Everyone was subjected to a conjectured, almost fabricated view of how good they are doing, to upper management for a critique….and usually of presentation style vs content.
  • In mind-numbing, boring detail.

I slipped out, noticed a bag of popcorn and a microwave. Hit 5 minutes instead of 2. Ran back into the room, and told a colleague “if you smell smoke in 5 minutes, run out and pull the fire alarm.”

Post-fire, I emailed the company fire-marshall on the risk of holding company meetings where “everyone in R&D” attended. Could we not just send representatives in case of fire as we saw last week?

The short term results of the hack:

  • The whole team was no longer pulled away from work…
  • The project managers represented the teams…(while this is a good thing in that the PM is no longer bugging the team during that review day, it is a bad thing we need PM’s at all.)
  • The lie of good progress still persisted….

The next hack I’d like to plan is one that promotes viewing the working software in a culture where status reports are preferred.

Suggestions on that are welcome!!

This hack was submitted anonymously

 

Fake Contract

Culture & Crack: It’s often hard to convince a buying department of a large firm that an agile approach to build a piece of software is less risky and the result may fit much better the needs of the users. I’ve been in a situation where the conflict between the entrepreneurial and agile mindset of the product manager who was asking for an internal tool to be build by an off-shore subcontractor and the strict purchasing rules of a fixed price project could not be resolved – at least not within a reasonable time frame and effort.

The Hack: Instead of trying to convince people of the buying department about the benefits of agile contracts we decided to create a fake fix price contract with made up milestones that we draw from an initial version of a product backlog just to please buying department rules. On a personal level the subcontractor, provider of off-shore development and the product manager agreed on an iterative approach including free changes after each iteration within the budget boundaries given by the contract.

The Result: Both parties knowing that the contract wouldn’t help a lot in case of failure with the project actually helped to create a bond within the team. The safety a contract would normally provide actually was found in the agile approach chosen, co-dependence of product manager and team as well as trust that has been created by colaborating on the product backlog with the whole team involved at the off-shore development site. After several increments shipped and changes to the product backlog the first version was delivered into production two sprints before last milestone given in the contract. The saved two sprints were then used for later maintenance and smaller improvements after the software was used in production for a while.

I would consider the hack close to red zone. All depends on agility of the team and luck. So I would think twice if it’s worth the risk before working on a bigger project that doesn’t have a valid contract and always prefer agile contracting clauses like change for free.

Hacking a Conservative Org with Lean Coffee

Culture: Highly conservative public sector organization, average employee age of 47, strong status quo and intentional as well as un-intention hiding of information throughout the organization.

In this organization the cube-farm is alive and well and there is strong separation between departments and an emphasis on job descriptions.   Making anything visible is not such a good idea and disruption to the existing culture is seen as “chaos”.

The Crack: We had started a Lean Transformation and a challenge was that in a 250 person department (4000 company wide) it was difficult to find out who the early adopters were.

The Hack:  I posted a “Lean Coffee” sign in various public and highly trafficked areas of the organization so I could learn:  Who were early adopters?  What problems did they have? What topics would they want to discuss?  Who would show up from which departments?

Hack Zone:  Green Zone Hack.  Very safe yet highly un-usual for this organization.

The Result:  9 people showed up.  A mix of developers, business analysts, project managers and 1 person from the project management office who had a background in lean manufacturing.

What it Led to: I ran this session weekly and over time, only business analysts kept showing up so we started a business analyst community of practice.  The community of practice led to me getting connected to HR to help create an “Expertise Directory” across the organization.  The connection with HR led to interest in getting Management 3.0 into the official leadership curriculum across the organization.

The connection to the person in the PMO led to our transformation team being able to bring Lean practices into the PMO and the removal and consolidation of status reports.  This connection led to being able to use a Lean Startup Business Model Canvas instead of more heavy-weight documents at project inception.

The success of this Lean Coffee session inspired a “Director Lean Coffee” session where any employee could come to a session and get questions answered directly from an executive.

Summary of the Hack

Most importantly, this “hack” allowed me to find the right people in the organization so I could establish a relationship with them and help them look at the organization with a different lens.  It was safe and simple and yielded positive results.

 

Minding Our Physical Space

Cube-landCulture: Cube-land requested by the CFO (Chief Facilities Officer) to ensure that managers can walk around developers and can observe work in progress. Developers had no walls surrounding their desk space, meaning there was no wall space to hang big-visible displays of how the product was coming together. The existing cubicles had walls 1 foot higher than the tables, team members were complaining about constant interruptions. Each cubicle was surrounded by a “patrol hall” where anyone could walk by (and interrupt work in progress.) The ultimate design reminded us of a prison architecture called  “Panopticon.”

The CFO’s floor space design was such planned so that “no high walls can surround the workers so that in the center of the building where the managers are, natural sunlight would still be present” (although they lived in offices with closed doors in the center of the floor!)

The crack: Altering, by any method possible, of the floor plans made by the CFO was not allowed. Period. No requests were honored.

The art: The contracting agency had “unused wall scraps” in pile on the lab floor of various colors, whereby if assembled could creating a wall collage of various sizes and colors.

The hack: The whole team came in at midnight and assembled the wall scraps, creating a collage of high walls surrounding the team and including the “patrol hall” space. We decorated the area as if it had been like that for years versus just put up over night. We were able to create an open workspace where within our area we could work or play uninterrupted.

The result: The CFO complained to the director of R&D to “put the office back the way it was.” The R&D director said to the CFO: “if you can put it back overnight go for it, if you have to take a work day to do it, forget it.” As for if it was a success or not: definitely for this team.

Silo Cruncher

The Silo Cruncher is hacking the culture of a startup which has grown into a structure of silos, each optimizing on its own behalf and not contributing to the whole anymore.

The crack is that product development is nearly stalled and connection to customer needs are lost. Endless discussions are not leading to any result. High tensions and toxic atmosphere exist within management team where everyone fights for his own unit. Everyone suffers from dysfunctional behavior, especially the CEO is desperate with the situation having clear idea what he wants from the team but nothing is delivered.

The hack is while introducing Scrum to make the CEO the Product Owner (1) at least as along as it takes to level the silos. The result is that the Product Backlog becomes the most important thing everyone in the firm pulls work from. Impediments get raised to the highest level and silo structure being a prominent one can be removed, so that teams can group better around work from the Product Backlog. The hack causes a lot of stress for the middle management and can create also a lot of damage. Another con is that the CEO is driven by shareholders and does not have the capacity to fill the Product Owner role fully. While teams are freed from silo boundaries the Product Owner becomes a bottleneck. A less brutal alternative is the Leadership Hack #1: Knitting together silos in your company.

(1) Product Owner is a role within the Scrum framework

Pass the P0 role

Product Owner Role

The specific culture of this hack can be characterized as money driven, lacking respect for people, focusing on individual capacity utilization, high valuing of acquittal and favoring direct control over establishing a shared vision and working agreements. A Scrum Product Owner (1) is seen as the waiter receiving orders instead of a leader responsible for making the best out of the Scrum Team’s efforts and holding the purpose of the group.

The crack originates from trying to replace the direct control oriented leadership style by the distributed authority model of Scrum and resistance against the change. Stuck in the middle of the change the Product Owner is not given the authority to succeed with his job, yet he is kept responsible for the outcome by the Development Team and his Managers alike.

First part of the hack is to make the authority dilemma visible to everyone. A useful tool to do this is delegation poker to create an authority board clarifying the delegation level of the Product Owner’s key decision areas. The second, part is investigating peoples happiness at work, e.g. creating a happiness index from 1-5 by regularly doing a quick 5 finger voting. And third, voila, a Product Owner of the team chooses to pass (2) his Product Owner role during a management meeting as a piece of art: P0 (null=no happiness) written on an empty role of toilet paper making elegantly exploiting the tension with fun.

The result is a honest discussion what the conditions of the role of a Product Owner is: freedom, fun and playfulness to live the role fully.

(1) Product Owner is a role within the Scrum framework
(2) Pass is an element of the Core Protocols

 

Hack the hack challenge

To launch this site with a degree of humor and art, Stefan and I would like to offer a Kindle Fire as a challenge to all of the business culture hackers out there.

Hack Queen or Hack King will be announced the last week of September.

Specifically the challenge his this: Can your business culture hack top this hack? Can you think of a business culture hack that changes behaviors so drastically? As you try and top this hack, keep in mind the motivators which must be teased with any good hack. For this example, the person sees the fly and is curious. There is a degree of power, a challenge perhaps, and maybe status (if succeed in removing the fly.) There might be a sense of goals bring achieved, or freedom to do what we think we need to do seeing the fly.

We will keep this hack challenge open until September 20, 2012.  Our Hack Queen or Hack King will be announced the following week!

Happy hacking!

Stefan and Catherine

Business culture hacking at ale2012

Oxygen supply hackThe aim of the business culture hacking event at the Stoos Stampede Amsterdam on July 6th and 7th 2012 was to catalyze action instead of accommodating the overwhelming mess Stoos has identified. While we have gathered insights about potential cracks and had fun at the two sessions, we also have created a queue of ideas, which are left in the darkness of the shadow world – at least for now. Moving ideas into the real world is the hard part – a crack, which was easy to sense at the second session at Amsterdam: business culture itself being a blocker for artful, fun and non-sens, type of actions like a culture hack.

So here is a view of the live line of the business culture hacking idea at Stoos:

On first meetup of Stoos satellite Berlin RE:LEAD, June 19th 2012, Simon said: ‘Let’s get a list of actionable things like hacks from the Stoos Stampede Amsterdam’ ———> idea scale for Stoos Stampede——-> Stoos Stampede Amsterdam July 6th&7th —>  … queue of ideas —> ?|||||#/%% hard part ”#§”||||?

Hacking means doing something and we are not done yet with the first cycle. Let’s meet at the event The Core and Culture Hacking and the open space of the ale2012 unconference to investigate cracks and actually implement hacks in the real world.

Sharing stories about hacking biz culture.