Preparativos para un Open Space

Vuelvo del Visual Management Open Space 2011 más feliz que un anís. Aunque con un pero. El mismo pero con el que volví del Agile Open Space 2011: hay muchas conversaciones interesantes que no llego a mantener por no conocer a buena parte de los asistentes.

¡Y eso que montamos una divertida red social unplugged (Gamestorming: Lo-Tech Social Network)!

Me gustaría que a la próxima reunión a la que asista llegue sabiendo algo de los asistentes a los que no he visto antes en mi vida. Me gustaría encontrarme buscando caras de algunas personas a las que no conozco pero a las que sé que quiero conocer.

Una posibilidad son las listas de twitter con los asistentes, como las que amablemente confeccionó David Bonilla antes del AOS2010 y del AOS2011 (e.g. http://twitter.com/david_bonilla/aos2011). Son útiles y facilitan los preparativos... pero están llenas de avatares irreconocibles, de nombres crípticos, de gente muda -sin twits, ni bio, ni ciudad-, de gente verborreica...

Otra posibilidad que me gusta más es hacer que los asistentes tengan que rellenar un "positioning paper" para registrarse. Se trata de un cuestionario mínimo en el que los asistentes explican algo sobre ellos, sobre qué esperan aportar a la reunión y sobre qué esperan sacar de ella. Al parecer, se trata de algo bastante común. En el Agile Coach Camp Norway 2011, nos hicieron rellenar uno, y a mi resultó muy útil.

Como ventaja adicional, esto hace que el coste del registro sea mayor que un simple click, lo que hace más improbable que la gente se apunte demasiado a la ligera y deje a alguien más interesado sin plaza.

Pushing agility from the business side?

Pushing agility from the business side?, originally uploaded by -Xv.

A possible scenario:

1. IT happy with status-quo: Big Design Up Front and Waterfall.
2. Stakeholders accept non-agility as a fact of life.
3.Tell stakeholders that they are entitled to learn, to defer
decisions until the have more info, to change their opinion. That some
of their competitors use those right to their advantage.
4. Stakeholders will push agility upon IT

Just in case it helps Ferran Rodenas to get some idea to break the status-quo

Back in the U.S.S.R.

East Germany may no longer exist, but now we have companies featuring central planning by Troikas, mission statements crafted by apparatchiks, quinquennial planning, no right to choose leaders in companies, no democracy in the workplace, a clear distinction between intelligentsia and peasants (top CEOs make 512 times the median salary and enjoy company 'dachas', jets and limos), and 'state' monitoring (time clocks, dress codes, drug-screening, 'employee assistance' plans, e-mail monitoring, smoking and personal conduct rules, as family-life audits). [1]

This is not a quote from a labor union leader, an anti-globalization essay or a witty comedian. It's from a proponent of democracy and transparency in the workplace that happens to be a business owner putting his money where his unconventional mouth is [2]: Ricardo Semler, in The Seven-Day Weekend [3].

I loved this book, even if its writing style is not that great. Its main point is showing how Semco, Semler's company is run. When Semler and Clovis Bojikian started changing the traditional command and control ways,

"We wanted to demonstrate that the workplace could be a place of satisfaction, not of suffering. Work should be a pleasure, not an obligation. But this wasn’t just some humanitarian thesis. We believed that people working with pleasure could be much more productive.”

To Semler, it's not about values: it's about competitive advantage.

Hurry up and read his book, or take a peek into The Semco Way by reading a 1989 article by Semler in the Harvard Business Review or a 2006 article about him in Strategy+Business. I'm sure that it will give you lots of food for thought.

[1] Soviet/Corpororate parallels quote: It's a funny coincidence that I read this during International Workers' Day
[2] Unconventional mouth quote: by Geoffrey Colvin in a Fortune article
[3] Even if Semler is a best selling author, I never heard about him until I recently read a post by Jon Lister. Thanks so much, Jon!

Yay! Barcelona Python Meetups are here!

Back from the first Barcelona Python Meetup Group event. The event was good, with two talks:

• Maik Röder, based on the Eight tips to start with Python. Maik added an additional tip (use PyFlakes, a faster PyChecker) and asked the attendants for our own tips: IPython (a great shell that I should be using again) proved to have many fans! I mentioned my love for ctypes.
• Ramon Navarro Bosch, on Design Patterns in Python. Ramon recommended us Alex Martelli's Google TechTalk video on the topic.
  

If the event was good, the post-event (beers, croquetas and bravas) with Maik was great and I'm bringing home lots of food for thought. Most of the talk was about Funittest (Making it easy to go from use case to functional test). Maik uses daily a high level Test Driven Development flow:

• write the functional test, to get aligned with the user's needs/customer value,
  
• write unit test, that can be driven faster and focus in the approapiate level of abstraction
• write the code

My impression is that his ideas have lots of commonalities with Fit and Fitness, and the story-based-testing that they advocate. Maik said that Funnitest's theoretical foundation can be grasped in The Braidy Tester articles; I'm adding them to my to-read list...

Beyond functional testing, the programmer's flow, the business-technical gap, Barcelona, Sevilla, tele-working... an intriguing an promising idea: the I-told-you-that-this-was-a-wrong-decision year-end bonus.

Virtual gaming, leadership and agile software development

As I was reading the excellent Virtual Worlds, Real Leaders by seriosity and IBM's Global Innovation Outlook (GIO) team, I was struck with the similarities of the leadership attributes that they found in MMORPGs (Massively multiplayer online role-playing games) and those that are familiar to me from working in agile software development projects.

I'm quoting two summaries that appear in the report:

Online gaming environments facilitate leadership through:
1. Project-oriented organization
2. Multiple real-time sources of information upon which to make decisions
3. Transparent skills and competencies among co-players
4. Transparent incentive systems
5. Multiple and purpose-specific communications mediums

In fast moving distributed environments, leadership can be:
1. A temporary phenomenon
2. Task-oriented
3. Dynamic and constantly changing

Doesn't this make you think about how the daily scrum/stand up meeting and collective code ownership provides "transparent skills and competencies among co-players"? About how the leading roles in an agile team changes constantly among team members depending on the task at hand? About the fluid communications in the noisy room where the team is sitting?

Coding Contest in Second Life

Just good an email from Christoph Steindl, a former IBM colleague, where he used to co-lead the Agile@IBM community and write an excellent blog.

Are you familiar with the Coding Wars in Tom DeMarco and Tim Lister's Peopleware? Christoph is into something similar: the cool Catalysts' Coding Contest (CCC) that his company is running:

• Who is faster? Who is more efficient? Who is more effective? Who is more productive?
• Does "Pair Programming" really make you faster?
• Does "Test-Driven Development" really lead to fewer bugs?
• How many ways are there to solve a problem?
• Is it right that good developers only write 30 lines of code for which mediocre developers need to write 300 lines?
  

Catalysts organizes a coding contest to go further into some of these questions.

They will be running the contest in Linz, Austria (with post food and beverages) and in Second Life (do avatars drink and eat?).

Looks like a bright idea to me. I bet that having participants with different backgrounds, and letting anonymous participation will provide coders and organizers useful insight. I don't know if other companies do this sort of thing internally, but it looks like very interesting way to get information, a honest measurement not linked to rewards and punishments (note to self: bring this to IBM's internal ThinkPlace).

I'm even considering ignoring my usual too-busy-with-real-life-to-get-me-a-second-life to be able to participate via Second Life.

Evangelizing and toilets

One of Google's little secrets that has helped us to inspire our developers to write well-tested code: we write flyers about (testing techniques) and then regularly plaster the bathrooms all over Google with each episode, almost 500 stalls worldwide.

We've received a lot of feedback about it. Some favorable ("This is great because I'm always forgetting to bring my copy of Linux Nerd 2000 to the bathroom!") and some not ("I'm trying to use the bathroom, can you folks please just LEAVE ME ALONE?")

Stumbled upon this evangelizing technique in Introducing "Testing on the Toilet", while googling trying to decide which JavaScript unit testing framework use (yeah, shame on me, I've been doing lots of JavaScript lately without doing Test Driven Development).

They not only use a surprising evangelizing technique, but also have a great banner and motto for their blog: "Debugging sucks. Testing Rocks."

Planning Poker

I'm reading Mike Cohn's Agile Estimating and Planning (amazon.com amazon.co.uk); so far, a great book. Jim Highsmith's foreword is well worth reading.

On the chapter of techniques for estimating, Cohn describes Planning Poker, something that feels so simple and effective that you almost have to run to join your team and give it a try. You can read the description at http://www.planningpoker.com/detail.html. The site hosts a tool to enable distributed teams to play Planning Poker. Disclaimer: I still haven't played poker nor checked the tool.

One the nice things of Planning Poker is that it is not tied at all to software development: projects from other domains that have to be sized by guestimates (like writing a complex report) fit nicely in this approach.

Mary Poppendieck: Competing On The Basis Of Speed

I watched Mary Poppendieck's talk at Google: Competing On The Basis Of Speed. It is a good talk, but it does not compare well to Mary and Tom's most excellent Lean Software Development: An Agile Toolkit (amazon.com amazon.co.uk safari).



I took some messy notes, way too powerpointish :-(. My advice: go for the book.

Intro

• Fast companies (e.g. Dell, Toyota, Google)
• competitive advantage
  
• lower costs
  
• large barrier to entry for competition
  
• Speed's enemy: complexity
• 3 faces of complexity [1]:
• waste: anything that depletes resources without adding customer value
  keep it simple
  
• inconsistency: anything uneven, unbalanced, irregular
  make it flawless
  
• overload: excessive burden
  let it flow
  

Keep it simple (video 5m45s)

• Common infrastructure:
• Architecture
• Conventions: naming, coding, security, logging, ui, configuration management...
• Tools
• Refactoring to keep simplifying
• Sustainable simplicity: change tolerance (video 7m52s)
• 60%-80% of code is written after the first release
• the development process has to anticipate change
• decide as late as possible, when you have more info
  
• make decissions reversible whenever possible
• make irreversible decissions at the last responsible moment
• set-based development: explore the whole solution space at once (Toyota worked on 10 motors at once for the Prius). Keep multiple options, and one has to work at the last responsible moment.
• paradox: these redundant solutions are not waste

Make it flawless (video 18m28s)

• 2 kinds of inspection
• to find defects -> waste
• to prevent defects -> essential
• Mistake-proof every step: detect defects the moment they ocurr
• don't track defects on a list: find them and fix them
• test first, automated test suites
• Role of testing (video 21m55s)
• manufacturing:
  
• a quality process brings quality into the products (unlike in software development traditional view)
  
• finding process in verifcation -> you have a defective process
• focus on preventing defects. Cannot be at the end of development, adding waste in the form of test-fix churn. It has to be integrated into the development process.
• 4 kinds of testing
• unit testing: developer intend. Automate them.
  
• acceptance/regression testing: business intend. Automate them.
• exploratory + usability testing. Manual by definition.
• property (response, security, scaling....) testing. Take advanteg of tools.
• Technical debt (video 26m55s)
• anything that makes code difficult to change
• the longer you acquire debt the worse it gets
• cost ofcomplexty is exponential
• regression deficit: more features, longer testing, until it dominates the release cycle
• unsync code branches: the longer apart, the longer it will take to merge
• Build Quality in (video 33m17s)
• configuration management, one click build, automated testing, continuous integration, frequent depoyment
• nested synchronization: test as early and often as possible
  
• every check in - unit tests
• evrery day - regression test harness
• every week - operations test harness
• every iteration - deployment ready code

Let it flow (video 43m40s)

• cycle time : customer problem to customer solution.
• software development cycle time: requests to deployment
• process capability: wether you have or not a reliable and repetible cycle time for a given set of problems
  
• delays: hint of opportunities for cost/waste reduction
• queuing theory
• total cycle time = number of things in process / average completion rate
• shorter cycle time: ability to add new features
• small tasks and slack decrease the total cycle time
  
• utilization paradox (48m23s) - not having slack increases the cycle time. This is one of the ideas behind 3M's 15% of free time rule (Google's 20% precedent). Organizations targeting 100% utilization are meassuring the wrong thing.
  
• Keep a honest queue/to-do list: short and in the realm of the things that can be reasonably expected to be done; no useful purpose for long queues
• Stablish a regular cadence, limit work to capacity, minimize the size of things in the process.
  

System meassurements

• cycle time (lean classic) - process capability
• business case (are you making money) - business return
• customer satisfaction — sustainability
• net promoter score [2]

[1] From Matthew May's The Elegant Solution: Toyota's Formula for Mastering Innovation (amazon.com amazon.co.uk)
[2] Frederick F. Reichheld's The Ultimate Question (amazon.com amazon.co.uk)

OpenUP: a short intro to the Open Unified Process

I listened to Introducing OpenUP, a very interesting ibm internal presentation by Per Kroll and Ricardo Balduino, and hosted by the Agile@IBM community. I'm highly impressed. The slide set used has quite in common with this powerpoint, available in the Eclipse Process Framework Project (EPF) community news page.

Take the RUP principles, borrow freely from XP, Scrum, Agile Modelling and DSDM, shake, and you get a methodology that makes lots of sense despite having a mostly ungoogleable name...

OpenUP/Basic is organiced around 4 subprocesses: Collaboration, Intent Management, Management, Solutions Development. It has 6 different roles.



Did you notice that the tester role works in the intent management?

OpenUP/Basic is minimal, complete and extensible.

• Minimal means that it is not the kind of methodology where you have a huge role and workproduct initial list that you have to cleanup for your project (and that usually makes you shop more than you really need...): 6 roles, 18 tasks, 20 work products, 200 printed pages.
• Complete: can be manifested as an entire process to build a system (scrum does not deal with the solution construction subprocess)
  
• Extensible: can be used as a foundation on which process content can be added or tailored as needed. In fact OpenUP consists of
• A base process - OpenUP/Basic
• Extensions to this base process, such as Model Driven Development content

The main worproducts and their realtion to roles/subprocesses can be viewed here:



The Work Item List is very close to the scrum backlog (not only for the current iteration, but for all the project). Of course, it is iterative, a la RUP:



But adaptable! The project plan is a 2 pages doc, describing the goals for the different iterations. And, since each iteartion brings its learning, the plan changes:



I really like the concept of "Stakeholder Satisfaction Space".

Other things that I'd like to highlight:

• daily meetings
• test driven developemnt
• use case based
• promotes a readable representation of the architecture. Much of the architecture can be
• Selected instead of designed (patterns)
• Referenced instead of described

OpenUP/Basic instantiates the core values of the agile manifesto in some slightly more concrete core principles:

OpenUP/Basic Key principles	Agile manifesto
Collaborate to align interests and share understanding	Individuals and interactions overprocess and tools
Evolve to continuously obtain feedback and improve	Responding to change over following a plan
Balance competing priorities to maximize stakeholder value	Customer collaboration over contract negotiation
Focus on articulating the architecture	Working software over comprehensive documentation

Does it work? I cannot tell, but at least looks like its building blocks have proven to work often.

No lo leerán

No sólo este blog, sino gran parte de la documentación que se escribe en los proyectos de desarrollo de software.

Después del No Lo Necesitarás, el No Lo Leerán. O YAGNI (You Aren't Gonna Need It) y TAGRI (They Aren't Gonna Need Read It). Dos grandes principios que es bueno recordar en el desarrollo de software, al escribir artículos y correo, al hacer la carta a los Reyes, al ir a la ferretería...