toniBlog

A weblog about Methodologies for Development

The unknown variable, Che Guevara theories applied to agile teams

In Che: Part One, Ernesto Che Guevara states:
In War and Peace Tolstoy remarks that military science assumes that bigger armies with more men wield greater force. On the other hand, only vaguely, do they recognize that during military combat the final strength of an army is also its true physical capacity multiplied by one unknown variable. One unknown variable. This variable is none other that the spirit of the troops measured as their greater or lesser desire to fight and confront danger. Men with the desire to fight who also understand why they are fighting regardless of who they are fighting whether under military geniuses or those of normal intelligence fighting with clubs or machine guns that fire 30 rounds a minute these men will put themselves in the best positions and so they will win.
Immediately after hearing this I've started a comparison with agile projects. It's obvious in these days, with agile becoming mainstream that bigger armies (expensive tools? costly hardware? costly solutions?) and bigger teams don't imply success in software development. What is then the unknown variable in an agile team? I would compare the physical capacity with the knowledge base of the team, with the general collective intellect. The desire of fighting is nothing else than desire of success and play with risks and issues in a project. But then, it's in the understanding of the why they are fighting the most interesting part. I've seen teams over-performing in few different situations: some were strongly committed to the success of a startup, feeling part of it (my experience at Fluidtime), some other were committed to reach excellence (a common behavior at ThoughtWorks). The why can be different from team member to team member, some people need to feel that they are part of a whole, some others need recognition and differentiation. Some others are carrier driven, some others have a strong desire to learn, improve. Finding the right motivation in your team members will make your team run faster and smoothy, the unknown variable will boost your speed and quality.

5S and Software Development

Phase 1 - Seiri, Sorting: Going through all the tools, materials, etc., in the plant and work area and keeping only essential items. Everything else is stored or discarded.
  • Remove unused code
  • Uninstall useless software
  • Remove unused libraries
Phase 2 - Seiton, Straighten or Set in Order: the intent is to arrange the tools, equipment and parts in a manner that promotes work flow.
  • Build Scripts
  • Shortcuts
  • Symbolic Links to reach dev paths
  • Labelling of builds / deploy to QA
Phase 3 - Seiso, Sweeping or Shining or Cleanliness: Systematic Cleaning or the need to keep the workplace clean as well as neat.
  • Keep desk clean
  • Keep the OS desktop clean
  • Sort out emails
Phase 4 - Seiketsu, Standardizing: Standardized work practices or operating in a consistent and standardized fashion.
  • Patterns
  • Communication, common language
Phase 5 - Shitsuke, Sustaining the discipline: Refers to maintaining and reviewing standards. Once the previous 4S's have been established, they become the new way to operate. Maintain the focus on this new way of operating, and do not allow a gradual decline back to the old ways of operating. 5S definitions are taken from wikipedia

choose your next car: fiat duna, toyota prius or ferrari f60?

[caption id="" align="alignnone" width="950" caption="Mass Production"]
Media_httpuploadwikim_tpezm
[/caption] [caption id="" align="alignnone" width="600" caption="Lean"]
Media_httpwwweveryjoe_jexir
[/caption] [caption id="" align="alignnone" width="776" caption="Craftsmanship"]
Media_httpwwwgothamdr_rchrk
[/caption] If  you're lucky, you can afford Craftsmanship, good for you. You'll have top quality, in a hand crafted sports car. Or if you didn't follow the market in the last 20 years you'll opt for a second hand Fiat Duna, mass produced in Brazil in the nineties and you will spend almost nothing (well not including costly maintenance): nobody wants a Duna! Maybe you want to go lean. You want to spend a little more and be environmentally friendly (the Prius is a Hybrid) and get a sweet piece of technology. The challenge for the Craftsmanship movement is to keep the cost low, the challenge for the lean movement is to show to all the world how great the quality/price relationship is. There's no hope for you if you're following mass production/waterfall process: you will end up with an ugly broken car.

A very long list of Agile, Lean & C. books

I've used to have this list on a Google Spreadsheet, it took me quite a while to sort it (the first 3-5 books for each category are more essential than the others) and place the links, but here it is, more than sixty agile-related books! Agile Process Additional Context Agile Development Lean

Kanban with Pomodoro, it's like spaghetti with sushi but it might work

I've read a couple of tweets today (demonstrating that Twitter perhaps sometimes makes sense)  and I'm aggregating them here: Jason Yip twitted a link to this short, clever blog post from Matt Wynne defining kanban:
  • There are no iterations: only now. Work at a pace you can truly sustain.
  • Done means it is in the user’s hands. Nothing less.
  • Limit the Work in Progress. This forces you to get things done, or you’ll have nothing else to do.
  • Get better all the time. Keep tuning your process and tools to fit the way you need to work today - make kaizen a culture, not an event. Everyone is responsible.
  • Decide with data. Collect the data you need in time to make responsible decisions.
What scares me is the lack of iterations in the Kanban system, how can you keep the focus high on the team? Just few minutes earlier Henrikk Niberg was twitting:
Ouch, Kanban + Pomodoro hurts. Tells you exactly how inefficient and behind schedule you are, and why. Pain leads to learning...
What's scares me about the pomodoro is the too fined grained knowledge of what's going on, with the big risk of introducing waste in the process... And its rigidity... It seems that a lot of people around the world are now using those two techniques, anybody has some real experience of using them together in a project?

Observational learning in teams

On wikipedia there's an amazing page about learning, and I'm more than anything else interested in the Observational learning.
Learning is the acquisition and development of memories and behaviors, including skills, knowledge, understanding, values, and wisdom. It is the goal of education, and the product of experience.
Why Observational learning? Pairing in an XP team is the perfect environment for Observational learning.
Example can be a motivation for learning. Imitation of a role model is a natural mechanism for infants and children, when learning from experience. Child's play is another method for learning by the example of other children, who naturally gain satisfaction by playing the role of teacher or mentor to a less-experienced child.
What's the Example then? Talking about code it's the code base.The code base is your friend, coding having a look on how solving the same problem has been already solved makes easier to solve it again, keeps the code base consistent and helps to find patterns, to tackle the technical debt, etc.Talking about Methologies, it works well as well. The Example it's just the behaviour of the coach/mentor. It's again very interesting on the page what are the required conditions for a successful learning:
  • Attention to the model
A person must first pay attention to a person engaging in a certain behavior (the model).
  • Retention of details
Once attending to the observed behavior, the observer must be able to effectively remember what the model has done.
  • Motor reproduction
The observer must be able to replicate the behavior being observed. For example, juggling cannot be effectively learned by observing a model juggler if the observer does not already have the ability to perform the component actions (throwing and catching a ball).
  • Motivation and Opportunity
The observer must be motivated to carry out the action they have observed and remembered, and must have the opportunity to do so. For example, a suitably skilled person must want to replicate the behavior of a model juggler, and needs to have an appropriate number of items to juggle at hand.
What really works well in an XP team as well is the Informal way we teach and learn stuff and we the spread the knowledge across the team. The performance over time in an XP team is different from the one shown on the picture.

Some stuff you might try in your team

In the team we are used to be Agile, and especially what I call being Agile doing Agile stuff. Which means being not dogmatic: stop doing a practice when it does not give us enough value and starting it again when we feel that we are missing it. Not only: we also try always to introduce something new. Since the beginning of the project we had 2 swim lanes on the wall, one for actions  to do and one for actions done, we just added a third column, the keep doing actions, it's like having a star fish always there. The waste bin. Yeah, we are interested in what's going on with lean, so now there's a box on the wall, if someone in the team feels that is wasting (s)he can put a card there, we'll discuss it during the retrospective. As a reminder, the seven lean waste types:
  1. Overproduction = Extra Features
  2. Inventory = Requirements
  3. Extra Processing Steps = Extra Steps
  4. Motion = Finding Information
  5. Defects = Defects Not Caught by Tests
  6. Waiting = Waiting, Including Customers
  7. Transportation = Handoffs