Agile Training Toronto - Kanban, Lean, Scrum Coach » Craftsmanship

Workshop Results on Culture

Michael Sahota — Thu, 24 Nov 2011 19:49:27 +0000

I am really excited about my upcoming methods & tools article on culture and have been getting some great feedback from reviewers. Two comments requested clarification around supporting analysis for my thesis that Agile, Kanban and Software Craftsmanship have a cultural bias.

Here is what I said:

These results (Agile fits better with some cultures) have been validated through group workshops where participants performed the same activity after having an explanation of the culture model.

In this post, I will describe the workshop format, share the results, and provide some commentary.

For background context on this post, please see – Agile Culture Series Reading Guide.

Workshop Format

The workshop is very straight forward:

Handout the Schneider Model to everyone.
Form into groups of 4 to 6 people.
Each group selects a handout with either Agile Manifesto, Agile Principles, Kanban Principles, Software Craftsmanship or Declaration of Interdependence.
Groups draw Schneider grid on a flipchart.
Each principle is written on a sticky note and posted in the most appropriate quadrant.

Results

The following results were from an XPToronto User Group session earlier this year. I also ran this at SoCal LeanKanban and got similar results, but my camera sadly wasn’t working so I have no evidence.

Kanban

The results here are pretty clear – Kanban is centred around Control culture. So two groups with strong agreement with the proposed model.

Software Craftsmanship

The group on the left suggests that there is slightly more emphasis on Cultivation culture while the group on the right assigned the most items to Competence culture.

What support is there to the claim that Software Craftsmanship promotes Competence culture (as based on the manifesto)? In this case, I would say it is partially supported by the results.

These results indicate that language is not precised and that the experiment would need to be repeated several times with discussion and reconciliation of results to get a clear outcome.

Agile Manifesto and Principles

When I ran the workshop in Toronto, no group picked this, so we did a large groups swarm where40 people just wrote out an item and posted it. That’s why there are duplicates. There was a little bit of clustering like items.

The diagram shows Collaboration culture as dominant followed by Cultivation. The term “working software” appears in both competence and control. In my analysis, this terms was ignored because it doesn’t have a strong fit with any of the cultures.

This result supports the claim that Agile is about Collaboration and Cultivation Culture.

Declaration Of Interdependence

The results of this have been written up in an earlier blog post - DOI? Cultural Shotgun

Conclusions

These results provide some support for the hypothesis that each of Agile, Kanban, and Software Craftsmanship have a cultural bias. It is worth noting that this experiment suffers from method bias in that participants were using the same analysis process of assigning attributes from manifesto to the culture model. An alternate workshop/experiment (just invented) would involve having participants brainstorm what are the most important values and then map them to the culture model.

Software Craftsmanship promotes Competence Culture The rise of anemic Scrum was noted to dismay among...
Agile Culture, Adoption, & Transformation Reading Guide This is a reading guide to the series that explores...
Agile is about Collaboration and Cultivation Culture What is Agile Culture? In an earlier post, I talked...

Related posts brought to you by Yet Another Related Posts Plugin.

How to Make Your Culture Work with Agile – Screencast

Michael Sahota — Thu, 26 May 2011 22:09:44 +0000

Here is a video primer of the Schneider Culture Model and how Agile, Software Craftsmanship and Kanban fit in. It is recorded in HD so you may want to use full screen and 720p resolution to see all the slides.

For more information, please see Agile Culture Series Reading Guide.

How to Make Your Culture Work (Schneider) (This post is part 1 of Agile Culture Series –...
Agile Culture, Adoption, & Transformation Reading Guide This is a reading guide to the series that explores...
Agile is about Collaboration and Cultivation Culture What is Agile Culture? In an earlier post, I talked...

Related posts brought to you by Yet Another Related Posts Plugin.

Sustaining Agility Game

Michael Sahota — Fri, 15 Apr 2011 11:36:10 +0000

Have you been on a software project where each release gets harder and harder? Many projects fall into the tar pit of the Design Dead Core.

Why do nearly all software projects fail to balance short term choices with long term consequences?

Through game-play you will experience how hard it is to make effective choices. Game learnings will be tied into well-known models in and beyond software such as Technical Debt, Stephen Covey’s Production Capability, and Alistair Cockburn’s theory of competing games.

Recipe

Game Objective: Participants experience the attraction of short-term thinking and feel the long-term consequences. The game helps executives and managers understand the importance of investment in sustainable development practices. The game is intended to help them get through a Red Pill, Blue Pill moment.
Number of participants: 6 to 50 (Has been playtested with 40 at XP Toronto User Group Meeting).
Team size: 3 to 5 people per team.
Duration: 90 to 110 minutes
Materials: Game cards (can print or write by hand), pennies (15 per team), dice (two per team)
Setup: (optional) video projector, tables for group work, whiteboard or flipchart.
Credits: This game was created by Alistair McKinnell and Michael Sahota.

Session Timetable

Intro & Motivate Game [3 min]
Break into teams of four or five people. [2 min]
Setup Game [5 min]
Year 1 [30+ min]
Year 2 [20+ min]
Year 3 [15 min]
Debrief [15 min]

There is a backdrop story that motivates the game situation and is used throughout the game to provide entertainment and inject new rules.

What’s Your Choice?

Here is a photo showing the project choices available to management teams:

Game Narrative

You’re working at a large organization. (Although situation entirely applies to smaller companies). Your goal in this game is to get promoted within your organization through delivery excellence. You need 50 Career Points to get promoted. You’ll keep track of your Career Points as the game progresses.

Together with the other people on your team, you form the management team of a software development division. Your team is competing with other teams to get promoted.

[Handout Steady and Fast Cards and Scoring Sheet]
[Each steady project generates $3M revenue. Each fast project generates $4M revenue.]

[Optional Colour: You have two strategies that you can follow for any one of the projects in your project portfolio: (1) negotiate with the development organization and let them influence the deadlines; or (2) pressure the development organization to deliver to meet this quarter's business targets. You may choose a hybrid of these strategies for your project portfolio: running some of your projects with a steady, negotiated delivery pace and some of your projects with a fast delivery pace.]

Year One

Turn 1: Q1
Start of Turn: We are going to walk you through the first turn.
Allocation: You can fund 10 projects. When you take over the following strategy is already in place: 8 steady projects and 2 fast projects.
Scoring: Calculate revenue.
Calculate change in Career Points. Calculate cumulative Career Points.

[Each quarter, you get 1 Career Point for every $1M revenue over $28M and you lose 1 Career Point for every $1M revenue below $28M. You start with 12 Career Points. Need 50 Career Points to win]

Turn 2: Q2
Start of Turn: Your team has achieved more autonomy from the senior management team and you may choose whatever project delivery strategy you like.
Allocation: You can fund 10 projects. Choose an allocation strategy.
Scoring: as above.

Turn 3: Q3
Start of Turn: At the company town hall, your CEO shares her latest business thinking with the organization. Last quarter she attending a seminar based on The 7 Habits of Highly Effective People and going forward she wants the organization to consider not just production but also production capacity.

Some consultants have been hired and have started to put in place some metrics around production capacity.

The consultants present a report to your management team. It turns out that projects that are designated for fast delivery appear to be lowering the development organization’s production capacity by one unit of production capacity for each fast project.

[Fill in last 4 columns to spreadsheet: Invest, Delta Production Capacity, Production Capacity, and Fundable Projects. You start with a production capacity of 105. Update these columns for the first two turns (Q1 and Q2).]

[Each fast project reduces production capacity by 1. You start with a production capacity of 105. The number of Fundable Projects is calculated by dividing your production capacity by 10 and rounding down.]

Explain Invest. Your management team has been given a new portfolio management strategy: in addition to delivering project using either a steady or fast delivery strategy you may also invest in projects to increase your delivery capacity.

Scoring:
[Each invest project generates an opportunity to gain production capacity by rolling a 1d6 where each pip is a unit of production capacity. ]

[In order to avoid getting fired you must meet satisfy these 3 conditions: (1) no more than 5 Career Points lost in any one quarter.; (2) never two quarters in a row with Career Points lost; and (3) never allow Career Points to go below zero.]

Turn 4: Q4
Start of Turn: The consultants present another report to your management team. It turns out that projects that are designated for steady delivery appear to be lowering the development organization’s production capacity as well.
[Reduce production capacity by one for every 4 projects (steady or fast) (rounded down).]

End of Turn: Audit Event. Each team requires two independent auditors from other teams to verify the calculations.

Game Events (Year 2)

Beginning of Q1: At the all-hands meeting to kickoff the New Year your CEO exhorts everyone to work harder and to stay focused on delivery. She announces that Agile software development is on her radar and to stay tuned.The senior management team has set a revenue target of $33M for this quarter.

[Rules: You must meet it or loose an additional 5 career points (usual Career Point loss limit is increased to 10 Career Points). THIS TURN ONLY]

Q2
Beginning of Q2: Your management team becomes aware that an Agile consulting firm has been hired to help the development organization transition to Scrum. [Possible rule: you must do at least 3 fast projects while you still can]

Q3
Beginning of Q3: At the company town hall, as usual, your CEO shares her latest business thinking with the organization. Pick one option:

Discuss design dead core and how it gets created. [3 min] (http://www.agilitrix.com/2010/02/inventors-dilemma-and-the-dead-core/)
Show Schwaber video [11 min] The lights are dimmed and she signals the Audio Visual guys to play the Design-Dead Core video presented by Ken Schwaber. [Ken http://www.youtube.com/watch?v=IyNPeTn8fpo&t=35m38s (to 45:07)]

Beginning of Q4: CEO announces that promotion criteria are under review and they are working on revised policies for Q1 that reflect the need for sustainable development.

Game Events (Year 3)

Beginning of Q1: At the company town hall, as usual, your CEO shares her latest business thinking with the organization.Agile consultant explains Alistair Cockburn’s model of Competing games (current/next): Current Project (bounded game) and Product/Company (unbounded game)

[Rule change: Promotion Criteria is now 35 Career Points and 13 Production]

[CFO: Teams that have very low production capacity can revert to original game starting conditions]

Debrief

Here is an example debrief using ORID (http://pacific-edge.info/orid/):

What did you notice during in the game?
What emotions did the game raise for you?
What does this mean for you and your organization?
What will you do with these learnings?

Resources

Sustaining Agility Game Options – PDF to print 3″ x 5″ index cards (one set per team)
Sustaining Agility Score Sheet – Excel spreadsheet to print (one sheet per team)

Facilitation Tips

It is useful to create memorable even stereotyped characters to help participants connect with the storyline. e.g. CEO has a Texan drawl, CFO is from NYC, Consultant is from California.
Write Rule fragments on flipchart or whiteboard so everyone can see the rules. I suggest skipping text and just put keywords such as “Invest –>+1D6 Production Capacity”.
If you have not played the game before, I suggest you playtest it on your own.
It may be helpful to write up rules on flipchart in advance and then share them when it is time.

Feedback from first run (XPToronto)

“Fantastic, Magical” – Jorgen Baker
“Real pressures bottled up” – Alex Aitken
“Good fun, valuable, opportunity to learn” – Tom Huras
“Thought-provoking, Fun, Interesting” – Nick Faulkener
“Lively, Interactive, Team-focused” – Hedi Buchner

Feedback from second run (Agile Games 2011)

“This game relates hugely to my current work situation where we struggle daily to do thing the right way or increase our technical debt. This game can give great insight to our companies leader to make the right decisions as much as possible.” – A.F.
“Very interesting game. I’m going to try it myself.” – A.J.
“Good mix of presentation and game. Provided great thoughts about career goals, revenue and investing in production capability and the future.” – J.V.
“Great, practical game about strategy and the impact of long-term choices and short-term consequences” – T.M.

How to Facilitate a Great Game Debrief Ilja Preuß ran a peer workshop at Play4Agile on Tips...

Related posts brought to you by Yet Another Related Posts Plugin.

Software Craftsmanship promotes Competence Culture

Michael Sahota — Mon, 04 Apr 2011 19:07:44 +0000

The rise of anemic Scrum was noted to dismay among the Agile community and in particular by “Uncle Bob” Martin who coined the fifth Agile manifesto value of Craftsmanship over Crap(Execution). This gave rise to the much needed community of Software Craftsmanship.

Looking at an earlier post - Agile is about Collaboration and Cultivation Culture – it is clear that the Agile community was not addressing the Competence Culture. And we as a community of software professionals do need to pay attention to competence and technical excellence for long term sustainability. Uncle Bob recently wrote a good article on this topic – The Land that Scrum Forgot.

Cultural View of the Manifesto for Software Craftsmanship

The diagram below relates parts of the craftsmanship manifesto to cultures identified in the Schneider cultural model.

Not surprisingly, there is a big focus on Competence Culture. This culture is focussed achieving success by being the best. And craftsmanship is about being the best software developers possible.

The value of productive partnerships stands alone. I am curious as to what purpose this supports as it is not directly related to writing quality software. I am wondering whether:

this exists as a bridge to the Agile community?
is related to the strong XP practice of pairing?
is intended to appeal to the need for mentorship?

So what?

Craftsmanship needs to exist to make sure that the technical practices promoted by XP don’t get lost in fluffy bunny Agile culture. Things like: refactor mercilessly, do the simplest thing that could possibly work, TDD, ATDD, continuous integration, continuous deployment, shared code ownership, clean code, etc.

The existence of a separate movement to support competence culture that exists outside of the Agile, supports the assessment of Agile culture as focussed on Collaboration and Cultivation.

Caveats

I think that Craftsmanship is a good thing. I also believe it is complementary to Agile.

This is post is about understanding how Craftsmanship fits with Agile and company culture.

Agile is about Collaboration and Cultivation Culture What is Agile Culture? In an earlier post, I talked...
Kanban aligns with Control Culture In my last post, I looked at how Agile Culture...
How to Make Your Culture Work (Schneider) (This post is part 1 of Agile Culture Series –...

Related posts brought to you by Yet Another Related Posts Plugin.

Accelerate Your Team with Cross-Training Charts

Michael Sahota — Mon, 21 Jun 2010 19:48:59 +0000

Cross-training charts (also skill training charts) are a standard part of the Lean toolkit. They are used to identify limited skill sets that can lead to bottlenecks and work stoppage. See manufacturing example.

In Scrum (and some Agile), we have the notion of cross-functional teams and place value on generalists who can go where the work is. Cross-training charts can help get you there.

Technology and Domain skills

When helping teams assess themselves, I separate technology skills (who knows a library or tool) from domain skills (who know the frazzit module). Once teams do this, the lightbulb goes off – “Oh that’s why it takes so long when we need to do work on the frazzit – only Bill knows it and he is busy with other stuff”.

On the left is a legend I have used with a couple of wiki-enabled clients to track the matrix. (Excel works too and has a nice colouring feature under conditional rules but is less visible.

Consider the example cross-training matrix below for the developers. (QA, BA important too, but they have different technologies/skills). Across the top we have the names of the developers. As you can see, on the front end, they have an OK idea how to use SpringMVC and JSTL; there are no experts, though, so it may not be clear what their frame of reference is. Sometimes people don’t know what they don’t know. Very limited experience with UXD (User eXperience Design) which may be an area for attention depending on usability goals for the product.

What about the domain matrix? Well, it looks the same but with areas of the application outlined at an appropriate level of detail. You can put the whole team (not just dev) on this one.

Lottery/Truck Factor – Are you managing your risks?

Truck factor is about how many people on your team can be hit by a truck before you can no longer effectively support a piece of software.

The cross-training chart can be used to assess how well management is managing risk. Usually what I see is “not at all” and the result shows in terms of deteriorating code quality due to departures and growth.

How to spread knowledge?

There are lots of ways. My favourite is pairing. I also like to impose a limit on publicly declared learning goals – just pick one thing to learn at a time to provide focus.

My suggestion: give your team time to share knowledge and let them decide h0w they want to do it.

Footnotes

I keep talking to people about this so I thought I had better post on it. Most recent discussion was at a session at Agile Coach Camp in Waterloo.
See complementary practice of Timeline and Marketplace for understanding other team members.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

Deliberate Practice – a key to Craftsmanship

Michael Sahota — Sun, 11 Oct 2009 17:00:19 +0000

At Agile 2009, Mary Poppendieck presented on “Deliberate Practice” – how people become experts. The video and slides are available from InfoQ.

Consider the fifth value statement proposed for the Agile Manifesto by Bob Martin:

Craftsmanship over Crap

This presentation follows in the theme craftsmanship – How do we as a community bring it about?

The answer given in this talk is we need to consider what it takes to develop elite level skills in other professions – deliberate practice. Consider the visual note below:

It seems to me that virtually every company I have every worked for or with has done virtually nothing to bring about excellence in technical (or other) skills. Imagine what the world would be like if companies viewed their employees as assets and invested in them with mentoring and challenges so that they get deliberate practice. This requires companies to think about Production Capability and not just Production. More than just thinking about hitting the deadline. This is an essential component in build lasting success.

Ever heard of this crazy-sounding approach called eXtreme Programming (XP)? Maybe they were on to something.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

User Interface Engineering – Agile 2009 Banquet

Michael Sahota — Mon, 21 Sep 2009 23:57:22 +0000

Jared Spool gave a pretty good banquet keynote for Agile 2009 on User Interface Engineering. The main point is that is that very successful companies use amazing interfaces as a key competitive advantage. And the key to this is good user experience design.

Case and point is Apple. We watched an Apple video from the 80′s that showed Apple’s vision for the future of the computer (funny/sad was a plot element so long ago was about global climate change). Everyone at Apple knew what the vision was and could explain it. So what this means is that everyone is thinking about the long-term vision. Every time they have a choice to make on design they can take a step in the right direction so that the future can be achieved in part through many many tiny shifts.

Good design is INVISIBLE. NetFlicks is destroying their competition through a ridiculously high net promoter score (how likely someone is to refer a friend). No one ever mentions their Web UI even though it rocks – it’s invisble: It does what it needs to and it’s easy. How do they do it? In part through a culture of excellence – employees are the top priority and the CEO puts this ahead of board meetings. To support this they hire fast and fire fast. They also pass the culture test.

How do you learn good user interface design? Mentoring! Good designers know what good design is, but cannot explain it. Like chicken sexing. (Makes me wonder how much we are kidding ourselves that good design can simply be taught through patterns or what not.)

The company test is a recipe for successful cultures. All the companies with awesome user experience met the test even though they were radically different in many ways.

The last point about celebrating failure is critical. If people are not making mistakes, then they are playing it safe. And if they are playing it safe, the result is mediocrity not excellence. There is a similar field of thought around innovation – it also requires support for failure.

If you need help building better UI, start with #2 – spend some time observing your users and then make it better.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

I come to bury Agile, not to praise it

Michael Sahota — Sat, 12 Sep 2009 03:14:19 +0000

Here is the Visual Note (see earlier blog) of Alistair Cockburn’ Keynote talk at Agile 2009. His main intent is that as Agile is becoming mainstream we need to look at some of the larger issues of software development such as large teams, distributed, etc.

Alistair followed on Last Years Key note speaker Bob Martin in talking about Craftsmanship as a key approach in considering all the different skills needed in software development. He also spoke of developmental learning levels Shu-Ha-Ri that are key to a mentoring approach. This is also very relevant for coaching.

I strongly encourage you to watch the video or check out the slides.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.