The Unified Agile Methodology

Following a Scrum channel I came across one post about someone complaining about the excesive amount of papers, discussions and wisdom on the cloud that, for the comment's author, was just noise and the people writing those make just no sense.

I agree in part with that. You will find a lot of "gurus" that are trying to make a living as an Agile Confucius, throwing tons of aphorisms everyday to social networks (they love twitter!). They are always trying to sell you a brand, selling a brand is a important thing on their speechs and the practices and wisdom they give needs to have the brand name in it. At the end, you can be a certified agilist by paying them.

Also, you will find a bunch of managers and leaders that claim to do the correct Agile implementation, because, of course, that implementation works on their work environment. I like to call them the One Scenario Winners Agilists. They usually work for companies with a few old clients doing basically the same old thing over and over.

Finnally, there is a group of people trying to gather all this crap and try to build something better.

In my opinion, the true is that after a while, using any brand of your choice, you fail and succeed constantly and what changes is you experience. You learn to detect patterns around you to properly manage situations and conditions. Your senses become more disciplined and aware. After years of running around with practices, values, frameworks (you name it) you develop something called Situation Awareness.

Situation Awareness is the perception of the environmental variables surounding you and the capability to project how they are going to change on time and space. This is critical for good decision making, applied since the 1990's in aviation and traffic control to reduce the main cause of accidents: the human factor

My conclusion is that the Unified Agile Methodology will born from the correct study of the environmental variables and how they behave and change in time under certain conditions. Understanding that we will be able to predict, with a decent error degree, the impact of our decisions in chaotic and dynamic environments.

What will delay it is the cheap Agile Confucius talk, one scenario winnners that gives us lectures and the persuit of selling us brands and certificates rather than sharing appliable experience.

Open Space Training

Introduction

Defining training plans can always be a very intricate task for a company. On one hand, a company needs to provide training on its current products, methodologies and technologies, and on the other hand they have to manage it to expand their team's knowledge. Then there's the challenge of finding good external training (and by good I also mean cost-effective). Here's the story of how we managed to bring the Open Space methodology to our workplace.

About a year ago, some colleagues and I went to an Open Space on Agile methodologies (if you don't know what an Open Space is about, I'd recommend you read this). There were lots of people in the room, and we all had things we wanted to learn and share with the rest of us (back then we were mainly eager to learn actually). It was incredible how in a short time, not only we had a good amount of sessions defined, but an agreement on the sessions agenda was also defined. It definitely proved that it's a very effective way of resolving a complex problem like organizing an agenda of diverse topics, and a lot of people with different interests, backgrounds and knowledge. Of course, we only had one day to actually develop the sessions, but we had more than one room available, so we had multiple sessions at the same time.

Organization of an Open Space

So basically, the Open Space was organized like this:

1. The facilitator greeted everyone, and explained the methodology. He defined how the process was, and much time each part of the process would take.

2. We started with the first part of the Open Space process. There was a whiteboard, some post-it notes and a marker. When someone wanted to propose a session, they just stood up, said their name, and gave a brief explanation on what the session was going to be about (if it was a debate, if it was something he/she wanted to learn, or if it was something that he wanted to share or train others). After that, the person takes a post-it, writes the name of the session, his/her name, sticks the post-it in the whiteboard and sits down. This is repeated until the time assigned for this part finishes (the amount of time depends on how many people are there to propose sessions) or there are no more sessions to propose.

3. We were told that each one of us had three votes, and that we should approach the whiteboard and put a vote on the sessions that we considered were more interesting. Votes could be distributed among more than one session, but if you were really interested in one particular session, you could put all your votes there.

4. The facilitator organized the post-its with the sessions in order of the amount of votes. The sessions with more votes where more likely to be added to the agenda.

5. The facilitator would put the most voted sessions in the agenda, trying not to overlap the ones with most votes. People would chime in and make suggestions on how to organize the sessions better.

6. After that, we all went home. The next day, we arrived, and the agenda was there for all of us to see and decide which sessions we wanted to attend. My colleagues and I figured out that it would be a good idea to split and to attend different sessions so then we could share what we've learned. Not only it was a very satisfying experience, but we also saw the power of self-organization unleash. No one decided anything for us, the attendees. We organized our own agile event.

7. After the sessions where over, we made a brief retrospective on what worked, and what we could do better next time.

Our Experience

In early 2009, the local chapter of the company I work for was of about 18 employees. We were a diverse team of Developers, QA Analysts, Front-end developers and designers. We were small in order to develop complex training programs, but we knew that the urge for both having a periodical training program on the technologies and methodologies that we used, and there was also a need of learning new things. We figured out that we couldn't spend lots of time on training, but we couldn't ignore the need for knowledge. Then the idea came up...."Open Space training...why not?"

It was around April of 2009, when we gathered the whole team and explained the methodology. We would organize training ourselves, not only by defining what we want to learn, but also what we can teach others, or what do we want to debate.

"Wow...wait a minute...I'm sure everyone wanted to talk about any application/language/methodology that we will never use in our work, but things that could be really useful for the company". Actually, most of the sessions of the Open Spaces we have organized are about things that we commonly use and apply. From how our applications work, subjects like Quality and Development practices, to extending knowledge on the programming languages and tools that we use everyday.

Organizing an Open Space Training in the Workplace

So here's how we adapted the Open Space methodology to develop our training program.

1. Try to hold the organization session first thing on Monday. Send an email with enough time to the staff explaining what is it that you're going to do, and specify how much the organization session is going to last (it shouldn't last more than an hour, but of course, it depends on how many people is attending). Also define when will the sessions be given, and how much time is the Open Space agenda is going to last.

Tips:
* Try to have the training sessions be on Monday morning (9.00AM to 11.00AM).

2. When the time for the organization session starts, take your time to explain the methodology, and the steps that you're going to take in order to build your training agenda.

Tips:
* Session proposals can be about any technology related topic (not necessarily about things you regularly use. The idea is to lit the flame of curiosity and research too!)
* Be strict with the time frames defined for the different activities (proposal, voting, scheduling, etc).

3. Start with the session proposal. Get yourself some adhesive post-it notes, and a whiteboard (a wall or a window will also do the trick, as long as you don't clean them for a while). As explained before, the idea is that when someone has a session to propose, stands up, shortly explains the session, writes the title in the post-it note together with his/her name, and sits down.

Tips:
* Remind people that if they propose a session, they are responsible of obtaining the resources necessary for that session (whiteboards, projectors, notebook, snacks, etc). They are also responsible for finding an expert on the subject of the session, if that's what the session requires.
* Ask people to give a brief explanation of what the session is about (time is precious)
* As facilitator do not approve/deny session proposals. Trust the attendees, you'll be surprised to find out that your concerns are theirs too. Do not take more than half an hour for this.

4. Ask people to vote on the sessions that are more interesting to them.

Tips:
* In order to avoid conditioning, ask everyone to do it quietly. If people start talking, you can have them convince others to vote for a certain session.
* The number of votes that each one will have depend on how many people are there, how many sessions are proposed, and how long your agenda will be. Anyways, from 3 to 5 votes depending the situation will do the trick.

5. Organize the post-it notes from the most voted sessions to the least voted. Then start building the agenda.

Tips:
* Try to have at least two simultaneous sessions.
* Do not schedule more than three months of sessions for the Open Space. If you lost a really cool session because you decided to go to a different one, then you're a couple of months again of suggesting it for the next Open Space.
* If you're having more than one simultaneous session, do not put most voted sessions simultaneously.
* Let people suggest how the agenda could be optimized. They're the ones who will be attending the sessions.

6. Let the training begin! Here are some important things to have in mind for the development of the training sessions.

Tips:
* The people who proposed the voted sessions are responsible for moderating it. They should also be at the session on time, and if they require the presence of an expert (let's say that the session requires someone who will explain people how to optimize SQL queries), the expert must commit to attending on time and being prepared for the session. Ask the moderator to end the session on time.
* It's not a bad idea to provide breakfast or a snack for the session. Mostly if it's on a Monday morning. Don't make it the reason why people attend to the training sessions though.

Of course, this one is an adaptive process. No adaptive process is complete without a retrospective. Once the last Open Space training session has been finished, before organizing the next Open Space you need to do a retrospective. This is a key activity, since you cannot improve if you don't reflect on what you did. You can do the retrospective the same day that you organize the Open Space (always before, so you can close a cycle, and start a new one). Use your preferred retrospective techniques in order to find out what worked, what can be improved, and what does the staff commit to do in order to actually improving the process. We'll talk more about retrospectives in future entries.

Final Thoughts

In our personal experience, it's been more than a year that we are using the Open Space technology to organize our training, and it has proven to be an engaging activity, which gives a lot of value to your team, and is a constant resource of knowledge. Cost-wise, you're using the talent of your own staff to train itself, and you're only spending as much time as you dedicate to the Open Space sessions.

This self-organizing training activity will be a rewarding experience for both your experienced team members, and the more novice ones. You'll see referents for different topics emerge as they teach others about the things that they know, and at the same time they will learn from others about technologies, methodologies and practices that may become useful if not immediately, in the near future.

Refactoring Workshop

Introduction

One of the challenges as a leader is how to make members of a development team understand the value of agile practices. In my effort to do that I tried something I start calling the Refactoring Workshop.

What is that ?

The goal of this Workshop is to practice Refactoring in a group session fashion using a projector and a computer the team can share.

During practice, the goal is to work one hour per week, and to do as much Code Refactoring as possible of something a team member developed through the last week.

The sole use of the team's code has some important benefits:

* less time to understand the intention of the code
* the team can act as reviewers and give instant feedback to the author
* being able to see how Refactoring affects your own code is key to understand  faster and better its value
* and the most important: the Refactored Code must be used after the session

You will need to count with a senior level developer in the session who is familiar with concepts as Refactoring, TDD and Clean Code. Him should guide the team to find the path if they get stuck and facilitate the session.

Workshop Agenda

The session should take no more than an hour for two main reasons:
  - longer sessions generates longer discussions. The team will understand after a few sessions (if not in the first one) that they need to focus to get some job done
  - easier to get that time frame for training or the team can just use the lunch hour from one day of the week. If the facilitator brings the food even better ;)

So far, the Workshop agenda that worked for me is this:

* Last Session Overview: 5 min

Talk about the Code Refactored the last session and discuss its impact on new development and the overall project. Don't just forget about the code already done, get back quickly to ask questions like:

- "How was the impact on maintainability ?"
- "Does it make new development easier ?"
- "How was the users reception of the refactored code ?"

* Code to be Refactored Presentation: 10 min

Open the Code to be Refactored during the current session and pass the keyboard over the author who must give information enough to the team to understand the domain, scode and requirements.

* Code Refactoring: 40 min

During this window the team must do a refactoring applying good programming practices.

As facilitator, make sure to coach the team to learn all they need to do a good refactoring but must of all allow the team to teach themselves if they can. It will be easier for them if a team mate share the knowledge and also it will increase collaboration.

* Session Review: 5 min

Leave time at the end to discuss what was learned during the session and the pros of the worked code against the original draft.

Final Thoughts

After two or three sessions most of the participants unfamiliar with good programming practices should understand their value and start applying them on day to day work.