Milena Mastrasso

All of you knows that working or studying for long periods of time is difficult, concentration grows down through hours, inversely anxiety for results increases. Francesco Cirillo create a technique to accomplish our tasks in the way we want to do those tasks in a schedule period of time. This method, called The Pomodoro Technique, is based in time-box periods of working time.

What a Pomodoro is?

A pomodoro is a kitchen timer, and we will use it to control and administrate our time. We will set the timer duration on 30 minutes, 25 minutes of work and a 5 minutes break.  When a pomodoro starts it can’t be stopped, it’s indivisible. After four pomodoros you have a longer break (15 to 30 minutes).

Maybe you are thinking about the title of my post, this means that the recess must be respected, and it based on the idea of Francesco put in his book:

This leisure time is fuel for our minds. Without it, creativity, interest, and curiosity are lost, and we run ourselves down until our energy is depleted. Without gas, the engine won’t run.

How can this technique works?

You have your timer and are ready to start working, but what you will do? You have to do a list of your planned tasks in order of priority and a section labeled “Unplanned & Urgent Activities” where any unexpected tasks that have to be dealt with should be listed as they come up.

If some interrupts the pomodoro it can’t be consider complete. When a pomodoro rings you have to do a cross next to the activity you have been working and take your 5 minutes break. This time allow you to disconnect from work and do other activities which take a little time.

When you finish a task you have to cross it out, and remember that a pomodoro is indivisible, so if you have time left use it to review all the things you have done, but if you finish it on the five first minutes of the pomodoro you can void it.

Up to this point all be right, but what happen with interruptions, sometimes appear and it can be consider a real problem, so you have to learn to manage all of them. Interruptions can be urgent or not, imagine you are in the middle of a pomodoro and realize that you are really hungry and want to eat pizza, or maybe you remember a concert and you want to call a friend to invite him.

This interruptions are different, but if you postpone them you don’t have to void your pomodoro. You take note of that and continuing working. To control the interruptions you have to do a mark on the activity, use different marks to different types of interruptions.

Francesco said:

The first objective to achieve in cutting down on interruptions is to be aware of the number and
type of internal interruptions. Observe them, accept them, and schedule them or delete them, as
the case may be.

The second objective to achieve in order to cut down on interruptions is to be aware of
the number and type of external interruptions. Negotiate them and reschedule them depending
on the real degree of urgency.

This is the first step of applying this technique, then you can set your available pomodoros and estimate your activities to do the technique more effective. You can download the book and continues improving.

How can it be related with software engineering?

Some people use this technique to do development tasks, and some mix it with agile methodologies, but some people said that it can bring some problems because individuals may tend to meet personal goals and not team goals.

I invite you to talk about your experiences using the pomodoro technique in both scenarios, personal and team work.

Software estimation is the ghost of the process, always is difficult to estimate how much time it will cost, you can do it in different ways, with different techniques, by intuition, by the quantity of code lines or story points, by experience of someone or because you compare the project with other projects.

In the last meeting of agiles@bsas we were talking about software estimation in agile projects, we were discussing some different techniques. One of them is known as Planning Poker and I found it very interesting and let me explain why.

Starting the Estimation Process

To start the process someone tell what are a user story about, then all the people think which is the cost of this story and tell to the others. Up to this point all be right excepting for something that I take notice after some projects: the first person who say which is his estimation influence the decision of the others.

Imagine that instead of saying which is the estimation of each member you write it in a peace of paper and facedown and then all the papers turn over, no one knows what is written in the other papers, so there is no influence.

Planning Poker

The planning poker is a funny way to do the paper games but using a deck of card like this one:

You can notice that there aren’t all the numbers. This is because the objective is that estimation is not accurate, so each card must be bigger enough  than the previous.

So, after the user story explanation, each member put his card face down, and all together turn over. If there are lot of differences between  the estimations they discuss his opinions and re-estimate. If there are agreement the estimation is over.

Some considerations

• If a user story needs one hundred card it means that is too big or is incompressible, so the client or the Product Owner must divide it to decrease the complexity.
• When someone put a zero card it means that this task is already done or should take no more than a few minutes of work.
• The cup means that the team member is tired to think and need a break.
• The question mark card means “I have no idea”. If this card is used too often, the team needs to discuss the stories more and try to achieve better knowledge spread within the team.

Sometimes you have to explain someone what agile means, you start talking but the other person seems to misunderstand every word you said. So how do you explain agile culture to this person?

I’m going to tell you what happened to me last night…

There are 8.45 pm, I arrived to my boyfriend home hoping that he has bought something for dinner. Fortunately he had!  He was craving to eat chicken with Champignons’ sauce,  easy to prepare if you have the right things…

So I open the fridge and start preparing the dinner. A bit of this, a bit of that… and suddenly… oohh ohhh! Where is the cream darling?

He forgot to buy it, chicken is cooking and the sauce is in middle of preparation… I have to replace the cream!

I open the cupboard, the fridge and start to look for something that can help. Thinking a bit I found some pieces of different cheeses, so I change the dinner… Chicken and Champignons with Chesses sauce!

I found this experience similar to agile software development, you have something to do, but you could found some issues, requirements could change and YOU, the agile team, must be prepare to adapt to this changes!

I want to share with you my first experience at Agiles@Argentina, this is a little (but growing) group of people that enjoy sharing their knowledge about agile practices and how they apply this on daily work.  In my last post I talked about this meetings.

Last time we were talking about “What do you do in your first iteration?” and I would like to present some of the models proposed in that talk.

Some of the participants announced that they were using Scrum. However, I found an interesting difference, all of them talked about short Sprints, but the duration of this Sprint various between one and four weeks depending on the speaker.

Another speaker announced that their projects always start with a Retrospective meeting where the team discuss about “Which are the objectives for the project?” and “What could and could not be done taking into the experience of past projects?”

I also note that almost always the project initiate with a pre-sales process where they can take the “big picture” of the client requirements and then they formally start the project delivering in the first iteration a piece of final product which is made of:

1. Architecture document
2. Product Backlog and User Stories
3. Iteration Planning

Now I invite you to tell me and all the readers what do you do in your first iteration? what do you deliver? and How do you estimate what shall you do in each iteration?

If you want to share or learn something about agile estimation this is the topic of the next meeting (Tuesday July 14) at Microsoft Argentina offices, you can register here.

I recently found a group called Agiles@Argentina, this is a yahoo group which discuss about agile software development methodologies and organize meetings to share our knowledge in different parts of Argentina.

Particularly in Buenos Aires, the meetings are scheduled the 2nd Tuesday of each month in Microsoft Argentina offices. This time they will discuss some related topics like:

• How to initiate projects
• What do you do in fist iteration?
• What do you deliver at this time?
• How do you estimate?
• What are your decisions?
• What are the activities you do at first time?

They use Lightning Talks, 3 slides in a slot of 7 seven minutes to share what you do and what you think.

I invite you to visit and join this group to take notice about the places where are organizing other meeting, some agile training courses.

See you!

I have recently read about a Post-Agile Manifesto by Jason Gorman.  Jason said that Post-Agilism is simply doing what works for you. And he explain that in this ideas:

• If it Works, do it!
• If it Works, do it! It woks
• If it seems to Work,do it! It probably woks
• If it seems to Work, do it! It probably woks (and might work again)

Really it is not a manifesto, there aren’t a group or association investigating and promoting that. So if it isn’t a manifesto… What it is? It’s a phenomenon around the world where people who have worked with different agile methodologies and have decided to move on. 

Investigating a bit more about this topic I found a Post-Agilism FAQ at Jonathan Kohl’s blog which said:

Post-Agilism is:

1. a growing movement of former Agilists who have moved beyond Agile methods, using a wide variety of software development tools and methodologies in their work.
2. an emerging era. Now that the Agile movement has moved to the mainstream, what’s next?

Some people think that the post-agilism is  a fallacy, and that the people who consider part of this group are anti-agilist and “process mash up”. In this same article Kohl explain why they consider that this accusations are false.

Personally, I use Scrum and consider that the failure of agile methodologies are because people try to change and mix methodologies to adapt it to their necessities.

What do you think?

I was reading some articles about software engineering when I found a Software Design Manifesto by Mitchell Kapor (also known as Mitch). He study different careers, he was the creator of Lotus 1-2-3, chair of Mozilla Foundation and founder of Open Source Application Foundation, between others.

In 1990, Kapor deliver a software design manifesto where he has eloquently made the case that we need to think of software design as a profession, rather than as a side task of a manager or a programmer.

The most important social evolution within the computing professions would be to create a role for the software designer as a champion of the user experience…. What is design? … It’s where you stand with a foot in two worlds—the world of technology and the world of people and human purposes—and you try to bring the two together.

Some important is that software design is not UI design. And neither software engineering nor computer science are software design.

Design disciplines are concerned with making artifacts for human use … One of the main reasons most computer software is so abysmal is that it’s not designed at all, but merely engineered

He consider that software designers are the architects of software which has the responsibility of integrate design and software development; architects and engineers are involved in building the application, and programmers are who develop the application. A perspective and skills that are critical to good design are typically absent from the development process, or, if present, exist only in an underground fashion.

A software design manifesto.

Mitch Kapor first presented his Software Design Manifesto at PC Forum in 1990. It got published in Dr. Dobbs’ Journal in 1991, and later appeared as the first chapter of Terry Winograd’s book Bringing Design to Software.

A good software design must have:

• Firmness: A program should not have any bugs that inhibit its function.
• Commodity: A program should be suitable for the purposes for which it was intended.
• Delight: The experience of using the program should be pleasurable one.

Mitch Kapor wrote this manifesto some time ago. Do you think this is still accurate? Why?

Sometimes I have heard about some business that are committed to their projects, so the employees must working overtime to deliver projects on time.

I have heard in some occasions a project manager telling someone that he is not committed with the project because this person doesn’t stay at office more time than expected.

Personally, I think if people often need to do overtime is a clear fault in project management. You know the capacities and capabilities of your team. If a team regularly need to do overtime there are a problem.

I have write some time ago about Scrum. This methodology works over personal commitment of each member on the team. Teams are self-organized. Each member knows his timetable, and commit to do what he is sure he could do in this time.

So, if a person is committed to the project success must do overtime to complete it? Answer is no. You have to be realistic on your commitments, you have to be committed to do this things that are possible.

Is known that any person can works as a robot for to much hours. As the hours runs the ability of concentration diminishes. Its not new. There are some studies that said that making overtime can improve the velocity and quality of the team works in the short-term, but with some days employees start to get tired and people make mistakes and lose incentive to do high quality work. Results gets down! 

Don’t confuse personal commitment with working overtime.

Personal commitment frequently leads to developers working overtime to finish their tasks. However, overtime is not a requirement of personal commitment. You can be really committed with the project, also with your time-box planification.

A personal piece of advice: Hard-working is ok, rest & social life too. Keep balanced.

I work as business analysis. I have learn traditional business analysis (like Unified Process, Cascade, between others), but I found some problems with this and other prescriptive methodologies. One of this problems, in my opinion the most important, is that this type of methodologies consider that the clients always know what they want, and could explain it in the right way.  In addition all the prescriptive methodologies consider that documenting before development is important, and this documentation won’t change. My experience said that it is unfortunately false.

Some time ago I used to be a .Net developer when I start reading about agile software development. I found it really interesting because it focuses on the working software, it allow teams to develop high quality software and produce retrospective in the short-term. I consider this important things to do a successful project.

So I start thinking about the business analyst role in agile methodologies, because one of the agile manifesto rules said:

Working software over comprehensive documentation

If business analysts don’t spend several hours of their working time documenting, modeling and writing about lot of requirements. What are their responsibilities?

The business analyst must collaborate with the team.

As I mention in one of my last posts about people factor at agile software development, collaboration between all the team members is essential. Business analyst is the expert on understanding client requirements, he knows what the client is expecting about the system behavior. He will spent more time collaborating with whole team working on how the system will behave instead documenting.

Some projects need to write requirements because organization formality requires it.

How does the business analyst document this without investing too much time on it?

Requirements and specifications are written as user stories. A user story is a description of a requirement, but it is not a full specification.

Besides user stories describe a functionality, this are also useful to prioritize requirements and estimate costs.

Each user story could be code in an iteration or increment, so the specification must be smaller enough to could develop it in a small period of time, but it must be detail enough to estimate the work. Every user story must have acceptance tests attached, allowing the developer to test when the user story is done and also allowing the customer to verify it.

In addition, user stories must avoid dependencies of other stories, but you can combine some of them to deliver in the same iteration.

Which skills are needed to be an agile business analyst?

I mention before that business analyst have to document requirements in a different way, less detailed. So he must learn a new way of writing and documenting.

He also have to improve his communication and collaboration skills because he has the responsibility of translate business requirements to the technical  members team. He is not the unique responsible of making specification, he must work in group and involve other team members in this activity.

If the business analyst have good concepts of software architecture will help to reduce the gap to the development team and the business. He can understand and explain better how the system will be implementing.

Is the business analyst needed in any agile software development?

Some projects don’t need a business analyst,  sometimes a product owner (view my post of Scrum) is enough. When the project has a grater need of defining requirements and writing specifications is business analyst is added in the agile team. However, including a business analyst can perform the team comprehension requirements.

Conclusion 

Software development processes are changing, any time much more business adopt agile methodologies. The biggest business (like Google, Microsoft, Yahoo) are using Scrum, other business are adopting this or other agile methodologies. They consider that adopting a methodology that give flexibility and quick response to changes is very important.

I think that a good business analyst must work on acquire and improve some skills to be competitive in the actual market. If a business analyst wants to work in a agile software development is completely possible.

He has to learn a bit about agile methodologies and is necessary that he wants to works in groups with cross-functionality. It is a way of sharing experiences and knowledge, this makes it possible to learn from each other.

Come on, it’s not so difficult!

Today I want to share with you a little about Scrum.

Scrum is an agile product development methodology, note that I say product and not software. One of the most important of this methodology is that can be applied in any product development but this has been thought to software development.

Some approaches of this methodology have been used for years. In 1986 Hirotaka Takeuchi e Ikujiro Nonaka wanted to increment the process flexibility and agility of they business, they used transversals team (like rugby) where the whole team “tries to go to the distance as a unit, passing the ball back and forth”. During some years it has been modified. In 2001 Schwaber y Mike Beedle wrote the first book where this methodology was officially called Scrum. This book is “Agile Software development with Scrum”.

How does Scrum work?

Any development project starts with a necessity, this necessity is expressed as a list of requirements that we must fit to satisfy the client, also the client specify which of this requirements are more important and prioritize them. This list is known as product backlog. This product backlog could change during the project; the client could add, remove or reprioritize requirements. When all the requirements of the product backlog where delivered the product is finished.

Scrum’s process starts with a meeting called sprint planning; there a subset of requirements of the product backlog (the highest prioritized in the list) are committed to done in a small period of time called sprint. This subset is called sprint backlog.

Each sprint is a time-boxed period of time (between one and four weeks – depending on the project) where team commits to transform the items in the sprint backlog into an increment of the product; all the requirements which are included in the sprint backlog can not be changed; consider that the sprint backlog should be shipping at the end of the sprint, so IT MUST BE REALIST.

During the sprint, a daily scrum meeting (also known as stand up) is done; there each member of the team has to communicate how his work is going. This has the purpose to synchronize the whole team.

When the sprint ends two meetings take place the sprint review and the sprint retrospective. At the sprint review the teams shows what is done during the sprint, at the end of this meetings the sprint retrospective meeting is done where the team looks for improvements in the process.

After the sprint is complete, the iterative process should start again in the same way. With each sprint you have an increment of the final product. When the product backlog is completely delivered the Scrum process is finished.

The Scrum roles

Scrum determinates two classes of roles, the committed roles and the involved roles. An easy way to understand them is with the very well-known “pig and chicken story”

 The involved roles in Scrum (chickens) are all the people who are interested in the project, who have something to gain if the project is successful. Some of this people are final users, stakeholders, business manager, etc.

Who make the project successful? All the people who are committed to do that (the pigs). The pig roles of Scrum are the following:

• Product Owner:  Something interesting about Scrum is that includes the client in the development process. The product owner is the client, or a client interests representant inside the team. He is who defined the product backlog and prioritize each requirement.

• Scrum Master: he has the responsibility of ensure that the Scrum process is met. He also has to remove impediments to the ability of the team to deliver the sprint goal. 

• Team: is a group of people who has the responsibility of transform the product backlog into a product. The team must be made up with no more than 7 persons, normally between five and seven, with cross functionality. The most important of the Scrum team is that they are self-organized; they must be capable of creating its own dynamic orderliness. In scrum there is not project leader.

Scrum meetings

All the meetings are time-box. What that it means? Each one has a fixed duration, in this time they have to solve all the items.  

• Sprint planning (8 hours or less, depending of sprint duration). This meeting is divided in two phases of 4 hours. In the first part of the meeting all (pig and chickens) are invited. There, the Product Owner explains the highest requirements on the product backlog and the team decided which will be the goal of this sprint, and put this in the sprint backlog. In this part only the pigs can talk. The second part of the meeting is only for the Scrum team; in this time they decided how they will develop these requirements, and which one is the responsible of each task. 

• Daily Scrum meeting (15 minutes). This meeting has the purpose of synchronize the whole team; each member in the team has to know how the sprint goal is going. In this meeting each member of the team must answer three questions to communicate to the whole team how the goal goes:
  1. What have I done since last meeting?
  2. What are you planning to do by the next meeting?
  3. Do you have any problems preventing you from accomplishing your goal?

This meeting is also known as Stand Up because the team members stay stand up to maintain the quickness of the process. Something important is that all team members must be punctual. Some teams tend to put a fine (e.g. 1U$D) for assure this rule is met. Everyone is invited, but just pigs can talk.

• Sprint Review (4 hours or less, depending on the sprint duration). At the end of the sprint the sprint review take place. During this meeting the Scrum team shows what they accomplished during the sprint. Typically this takes the form of a demo of the new features.

•  Sprint Retrospective When a sprint ends and after the sprint review the whole team makes a close retrospective meeting where they reflect about the past sprint and each team member must answer two questions:
  1. What went well during the sprint?
  2. What could be improved in the next sprint?

Who use Scrum actually?

Large companies like Microsoft, Google, Yahoo and Verizon. And others no so large like Thoughworks.

Conclusion

Scrum works because is made based on common sense, and considering that software is made by people, human beens.