Author: Gerry Kirk

Daily post (weekly)

Daily post (weekly)

  • If you could suggest a unique idea that would help as many people as possible, what would it be?

    It’s a question worth considering. Never in history have so many people had so much information, so many tools at their disposal, so many ways of making good ideas come to life. Yet at the same time so many people (in all walks of life) could use some help, in small ways and big. In the midst of this, new studies are reinforcing the timeless wisdom that beyond a basic level of material wealth, the only thing that seems to increase individual happiness is… helping other people. In other words, help helps everybody.

    tags: no_tag

  • a simple tool that helps groups determine which questions should be asked at all hands meetings, conferences, Q&A sessions, etc. The idea is that there are always lots of good questions to ask in a limited period of time, but it’s hard to know which questions the attendees are most interested in hearing discussed. Moderator lets users add questions and vote on the questions of others, so the cream rises to the top.

    tags: crowdsource, vote

  • Scours social networks and web sites for people you are looking for. Great way to find and learn about someone.

    tags: people

  • “experiential learning games that accelerate the adoption and understanding of Agile principles in a fun and interactive way.”

    tags: agile, learn, game, fun

  • effective charts to communicate scope, schedule, cost change to a client

    tags: reporting

Plone Conference 2008: My Session Picks

Ok, time to start figuring out what sessions I want to go to at the Plone conference. I work mainly as a project manager / scrum master, so I tend to avoid the techy stuff. Here is my preliminary list:

Wednesday

  • The 10% manifesto and further — Methods for organized contribution to strategic development of Plone. I need to get better at this, interested in approaches to “building in” time to contribute back to Plone.
  • Usability Testing: From High End to the Dirt Poor. An area I don’t have formal knowledge in, always interested in how to better capture what users need.
  • Real world intranets. It’s Joel Burton. ‘Nuff said.

Thursday

  • Hybrid Vigor: Plone + Salesforce Integration. We (ifPeople) have done a couple of Salesforce + Plone projects, thanks to Andrew and ONE/NW’s fantastic contributions. Interested in doing more of these projects.
  • What Makes a Great Development Team? I’ve heard great things about Michael, who works with Martin Aspeli. I’m passionate about Agile, so interested to hear his talk, which I expect will have an Agile flavour to it.
  • The Future of Plone’s User Experience. Being Alexander Limi, I expect something entertaining and visionary.
  • Simplifying Plone. Some bleeding edge thought and real examples from Martin Aspeli and those attending.
  • Using Deliverance to Theme a Website. Ok, finally getting my geek on here. I’ve been wanting to understand Deliverance better, never got my head wrapped around it. There is your challenge, Mr. Bicking, one really smart cookie.

Friday

  • Repoze.bfg – a Zope explosion. Geek fix #2. Probably won’t ever code with it, but want to understand when it is a good solution.
  • Plone.org Documentation Team Panel. Interested in how the panel wants to make documentation on plone.org rock even harder. Hope to contribute some thoughts.
  • High performing teams: What’s the secret sauce? Good idea to attend my own presentation in case no one else does.

So that’s my list. What interests you? Let’s get some discussion going.

Of course, the discussions that happen outside of sessions are valuable also. I’m looking forward to seeing *so* many people, this being my first Plone conference after 5 years of being in the Plone community. Lunch anyone?

High Performing Teams: What’s the Secret Sauce?

Agile definition and value illustrated. View full size poster

I’m really looking forward to Plone Conf 2008 for many reasons, one of which is presenting on a topic I am passionate about, namely Agile development, in particular Scrum, an Agile software development framework.

What is Agile?

For people unfamiliar with Agile, Scott Ambler defines it concisely this way:

Agile is an iterative and incremental (evolutionary) approach to software development

which is performed in a highly collaborative manner

by self-organizing teams

with “just enough” ceremony

that produces high quality software

in a cost effective and timely manner

which meets the changing needs of its stakeholders.

Scrum, not just for rugby teams

Scrum is a framework that helps teams work in an Agile fashion. Development is time-boxed into iterations lasting 2 – 4 weeks. Each iteration delivers fully working (and tested) software that is “potentially shippable”. Work to be done is defined in a list, or product backlog, prioritized by the client so the most valuable features are done first.

At Agile 2008, I was fortunate to attend Jeff Sutherland’s (co-founder of Scrum) presentation on Agile contracts. His research has shown that teams firing on all Scrum cylinders can generate 400% more revenue than a team using Waterfall methods. (1) That’s some serious competitive advantage. Early retirement, anyone?

(1) See slide 19 of Jeff’s presentation

What do you want to learn about Agile and Scrum?

45 min goes by quickly so I’m soliciting input on my talk in advance. If you were thinking of catching this one, here is your chance to maximize your time investment. Let me know

  1. if you are currently using Agile and to what degree (see the Nokia Scrum test for a self evaluation)
  2. what you’d like to know in particular about Agile and Scrum

What I am thinking of covering:

  • Introduction to Agile and Scrum, if most of audience is unfamiliar
  • How Scrum leads to high performing teams
  • Quick demonstration of Agile tools built with Plone or built by Plone solution providers using other technologies. Pending list: Plum, XM, Agilito, RoadRunner. Anything else that should be in the list? I may use the tools in the other parts of the presentation to illustrate Agile / Scrum practices

Plone Conf 2008: The unofficial social calendar

Plone plays frisbee too
Plone plays frisbee too

Part of what makes conferences like Plone Conf 2008 so great is the chance to meet and hang out with many of the people we only “see” online from a distance. This is especially true for me. I’ve been involved with Plone since 2002 but have yet to attend any conference / sprint. Thankfully, that will soon change!

My organizational personality twitch wants me to make it easier for people to meet and do stuff, so I created a page for people to suggest and sign up for activities to do, things like ultimate frisbee (maybe we can design a Plone disc – yeah!).

Maybe you want to visit the Smithsonian, tour the national monuments, or go for a walk up Mt. Vernon after sitting on your butt all day in sessions.

To add something to the page, request access to the project.

We do Agile, but Where is the Quality?

This post is an assemble of notes from sessions at Agile 2008, including Paving the Way for Agile Testing, Expanding Agile Horizons, The Five Dimensions of Systems by Mary Poppendieck, Natural Laws of Software Development – Deriving Agile Practices by Ron Jeffries & Chet Hendrickson plus keynotes from Uncle Bob Martin (Quintessence) and Alan Cooper (The Wisdom of Experience).

There is plenty more to consider than what is written here to on the topic of quality, of course, but these stood out for me in the sessions I attended.

Do the Engineering Fundamentals

Of all the things I heard at the conference, these were repeated again and again, in varying contexts. Why? They are proven to work. Bob Martin argued that these should be embodied in the Agile Manifesto by adding a 5th Value: Craftmanship over Execution. He argued that those who work in software development need to take more pride in their work, and insist on doing the things that must be done produce quality work.

Refactoring

  • Allocate time in advance for refactoring
  • Need to ensure customer understands need to to increase technical debt, even though refactoring may not have “business value”. You either make small ongoing payments to keep debt manageable or face huge debt later. May want to have customer sign off on this.

Test-Driven Development

  • Kent Beck’s definition: First, you should write new business code only when an automated test has failed. Second, you should eliminate any duplication that you find.

Continous Integration

  • Without CI, small releases are difficult to do, integration problems aren’t found until much later.

Acceptance Tests

  • These describe what the stories should do, with real examples that can be executed in code.
  • Need to be automated, becomes more critical after each successive iteration.
  • Acceptance TDD – acceptance scripts written ahead of the code, written by testers and devs, FIT / Fitnesse recommended tool

Need Technical Leadership

From Lean thinking: have a development manager, someone who is a technical leader who is responsible for successful engineering practices. I see this person overseeing the use of the engineering fundamentals listed above. There needs to be leadership in our teams, from both a technical and management perspectives.

Definition of Done is Foundational

Everyone on the team, as well as the client, needs to agree on when a story is considered complete.

  • Define your Definition of Done (DoD) before the first iteration
  • A definition might include:
    • Unit / integration tested
    • All acceptance tests pass
    • No increase in technical debt
  • Example definition at Menlo Innovations:
    • Developer asks the QA/HTA pair for a “green dot”, but before asking, all unit tests must pass, code must work on machine other than developer’s own
  • Keep the definition visible for the entire team
  • Only a strong DoD (with many automated tests) will be maintainable
  • Maintaining a definition of done begins by first building trust. Trust might be demonstrated by granting full access to modify docs and code, providing the tools and support the team says they need. “The first thing to build is trust” – Brad Appleton

Specialized Testers Can Ask Questions that Need to be Asked

  1. Actively seek out defects
  2. Provide feedback, saves time
  3. Test-specific knowledge and techniques, can help others to test better.
  4. Good at asking questions during iteration planning
  5. Can offer feedback on documents and unit tests
  6. Can assist customer in translating requirements into acceptance criteria, writing acceptance scripts

At Menlo Innovations, QAs spend their time (in order of time spent):

  1. Asking questions
  2. Understanding user needs
  3. Understanding development implications
  4. Do some testing

Interaction Designers Can Turn Raw Data Into Useful Requirements

Alan Cooper argued that interaction designers (ID) bring an essential element to the team’s success:

  • Interaction designers can make sense of human behavior in the same way that a programmer can make sense of a computer’s behavior.
  • Their key contribution is translating research into actionable sketches and narratives that programmers can use. Their work frees programmers from communications failures, management misunderstandings, and wasted work. Those sketches and narratives are like user stories except that they are more accurate, more precise, more detailed, more correct, more complete, more readable, and more understandable by managers as well as by programmers.
  • Research shows that users don’t really know what they want or need. Where interaction designers can deliver significant, unique value is in their ability to distill useful answers from the distorted, raw data extracted from, or contributed by, humans. Interaction designers use ethnographic research, user models, scenario construction, role-playing, and other specialized tools for the distillation process.
  • “The operation was a success, but the patient died”. It is not uncommon to have a successful, Agile development project that still fails to satisfy the user.

Other Tidbits

  • A method to prioritize bugs: place bugs in one of 4 quadrants: likelihood of occurrence vs. importance to client.
  • To verify a build:
    • Generate a list of questions, like “Can a user log in?”
    • Answers not provided, as they may change
    • Questions generate conversation