Showing posts with label Scrum. Show all posts
I'll discuss in a couple of blogposts that I read recently in the book that I reference below, regarding how to improve the retrospective meetings.

What is a retrospective meeting?

In everyone's life, a retrospection is when someone stops and thinks about his/her life, evaluating good experiences, bad experiences and checking if he or she has learnt from those experiences in order to be a better person in society.

This, which most people do, in the agile methodologies of software development is called 'retrospective' and it is very useful in iterative development methods, to evaluate the progress made in every iteration. In this case we'll focus on SCRUM most of the time, but a retrospective can be applied to other Agile Methodologies.

Steps of a retrospective

A well-designed retrospective meeting should have the following steps:
  1. Set the stage.
  2. Gather data.
  3. Generate insights.
  4. Decide what to do.
  5. Close the retrospective meeting.
These phases don't seem special or mystical things and lots of teams try to commit to them, more or less. So, the question is, why don't they get good results anyway? Well, maybe the problem is how and not what.

Who leads a retrospective

A retrospective meeting can be led by the manager or by any member of the team, or even this role can be assumed by a different person each time the meeting takes place. The person who leads the meeting mustn't participate in the discussions that will arise during the meeting, because his/her position biases the rest of the people's opinion.

In addition to this, it is very important to analize which parameters must be taken into account in a retrospective meeting. Some examples are:
  • · Find ways to improve the practices.
  • · Discover what we were doing well.
  • · Understand reasons behind missed targets.
  • · Find ways to improve our responsiveness to customers.
  • · Rebuild damaged relationships.
To finish this section, let me mention two important statements that should be observed in every retrospective meeting.
  1. Avoid blaming someone for an objective that wasn't achieved.
  2. Try to make everyone participate in the meeting.

How long should it take

It depends.

It depends on the length of the iteration, on the complexity of the technology used in it, on the team's size, and the level of conflict that arise during the meeting. As a footprint: one week of iteration equals one hour of retrospective meeting. Anyway, there is no point in shortening or extending the meeting more than necessary.

On the other hand, the retrospective meeting must be prepared previously. The team must enter the meeting room with something prepared, at least some draft notes, and must be well informed about the issues to discuss.

How to prepare the retrospectives

The person responsible for the meeting must answer the following questions:
  • · What is the goal?
  • · Who will attend?
  • · How long will it take?
  • · Where will it take place?
  • · How will the room be set up?

How to convince the people to prepare the meeting

The leader can send a short quiz by mail to every person that will assist to the retrospective meeting. Thus everyone will have to take a couple of minutes to think about the last iteration. After receiving everyone's answers, which will be kept anonymous, the results may be read aloud during the meeting, so that they may be interpreted as a summary of the team's insights.

What to do after the meeting

Try to make someone responsible for every action that has been decided during the meeting. Lots of retrospectives fail because, despite giving good insights and making good decisions, everything is missed because nobody takes care of those decisions. So, assign responsibilites and make commitments about those actions to be carried out.

And in the next article...

... I opportunely made a workaround to avoid explaining in detail the steps of a retrospective meeting. I wanted to set the ideas and give some advice. In the next article I'll explain each phase.

Furthermore, I'll explain a list of activities that can be done in a retrospective meeting to promote the participation of every member of the team. This is the first objective of a retrospective meeting and the most important one.


Bibliography:

Agile Retrospectives: making good teams great

Esther Derby & Diana Larsen
continue reading
At Codice software we use a combination of software development practices and organizational strategies. Specifically we use CMMi (we are level 2 certified) and Scrum. An unlikely pair as one of these aims tightens up the development environment with strictly defined rules and process while the other aims to loosen the development environment and allow change to flow more freely and quickly.

While these two methodologies may seem diametrically opposed they actually work together really well. Pablo Santos the CEO, spiritual leader and in house motorcycle aficionado has talked about the marriage of Scrum and CMMi in our internal process's before. Recently he has authored a white paper that talks about the testing environment at Codice and how CMMi and Scrum have impacted the way we test.

CMMi summarized in a few short words is about setting up a well defined process, well documented process that is rigorously enforced. Agile, to summarize, is about being lightweight and adaptable. A marriage of these two spawns a process that is lightweight, adaptable but provides a rigorously enforced development process.

Used to be, back in olden times of a couple years ago, that coders would code and testers would test. The onus was on the quality assurance department to discover bugs before they went out the door. In the modern era of today and tomorrow there has been a paradigm shift that puts the onus on coders to find bugs before they even get to the testers. The testers are still responsible for putting the final stamp of approval on things, doing integration testing and regression testing, but coders are now being asked to only commit bug free code, or as bug free as reasonably possible.

As a result of this automated testing tools have really been a booming industry. Codice uses a couple tools for managing testing. A modified NUnit (PNUnit), TestComplete and an internal work item system. It is important to use a wide range of test methods even an in agile environment, see Edward Correia's first of 10 Myths of Agile Testing. White box, unit and load testing are accomplished with PNUnit. Blox box, functional and behavioral testing are performed manually or with automation using TestComplete.

A few words on TestComplete. I have been working with and around automated testing tools since 2001. I am familiar with a whole lot of testing tools and the better one's came from IBM and Mercury (now HP). TestComplete may very well be the best tool on the market. It has appeal for software developers as well as QA testers. It's part of of the next generation of automated testing tools that that uses intelligent object recognition for testing playback. This is huge in an agile environment where change occurs rapidly and users don't want to spend all their time maintains the automated test scripts.

Pairwise testing is also important to the Codice testing environment. Agile is about speed and its not very practical to think you can run 10 hours of automated tests with every build. It also makes continuous integration nearly impossible. Pairwise testing is a way to break up testing responsibilities using a matrix so that you can get good coverage on all the major aspects of a product without having to cover every single combination of things. A simple example, Plastic runs on Windows and Linux with MySQL, MS SQL Server and FireBird. To test every version of Windows and Linux with every database supported by Plastic would lead to an enormous number of testing combination's. This is simplified by using the Pairwise technique so that we test every system once and every database once, but not every system and database combination.

The result is a rich testing environment that is very broad in scope but not too time consuming. A robust testing environment is one that takes advantage of many different disciplines like pairwise, unit, functional and manual testing. Too add a minor wrinkle; the most important features can be tested during continuous integration during sprints, its not necessary to run an entire suite of tests.

If you want to learn more about this read our white paper about the Codice testing environment.

To try it for yourself I recommend these four tools.

1.) Plastic SCM - for version control
2.) TestComplete - for automated functional testing
3.) VersionOne - for Agile project management
4.) CruiseControl - for Continous Integration

Plastic, TestComplete and VersionOne are all products developed by companies who know each other, integrate where possible, and specialize in the products they make. It's an ideal combination for an Agile shop looking for robust testing. Plastic offers integration into VersionOne and CruiseControl.
continue reading
We've just published a new article on DDJ talking about our experience in CMMi using SCRUM.
We tried to tell which were the problems we found and how we tried to keep focus on being agile while still working on the CMMi evaluation.
Questions are welcome.
continue reading
It's been already nine months since we adopted scrum as our way of working. Nine months in which our software has passed from just a design (we spent several years planning before finally getting the capital to start) and some code to an almost finished product (we are finishing the last details, creating a first official release, although there are already some companies using it in beta status).

Sometimes you only see problems all around, but I see this happens in any project. But when we look behind we see we have managed to reach this close-to-production status: what are the things which helped us during our way? I would bet they were: agile methods (scrum), team spirit and having (some/lots of) fun (the last two being quite related). And if I have to make it simpler I would say: people, fun, competition.

I already had the chance to decide about the software process to adopt in my previous company, but this was the first time I had to take (shared with David) full responsability.

First time I heard about agile methods I have to admit I was very exceptical. It sounded to me like destroying all the hard-gained methodologies which I had studied back at college. Even I thougth it was promoting untrained people to do programming... I was deeply wrong. In fact, now it looks exactly the opposite to me.
Old-rigid-boring software engineering methods (or methodologies if you prefer) try to focus on the way things have to be done, instead of people. Those methods really push to have interchangeable software developers, managed by non-software people, replaced as if they were mechanical pieces... Precission, what they claim is lacking from nowadays software development, is the saint grail to look for. If you fail... just try a little harder, maybe some documentation was missing, maybe you didn't write some diagrams, maybe you didn't use the right case tools(they don't call them case anymore... wonder why?). They would never (well, almost never... :-P) ask whether people need a salary raise or a quiet environment. Stronger, harder, more precisse working... That's all.

And, at college, I believed that. Well, maybe I had some small doubts because I always liked programming, I've seen it as the cornerstone of software engineering, so the classic approach didn't fit perfectly on my mind.

It was only some time after when I first found code complete (first edition) and started noticing that there were well-known people having a different approach. (I wish I had found this book earlier).

Later, learning about extreme programming, rapid software development and so on, I realized that I was wrong about agile. Agile methods are all about people, about having good people. These methods don't enforce people interchangeability, something I find great.

We all spend a big amount of time at work (I won't look at the numbers... :-) ), so it is great if we can enjoy it. Yes, it can sound strange but think about it: maybe hundreds of years ago there were not so many jobs you could enjoy, but today if you are lucky enough to be working on something you like... why shouldn't you enjoy it?

Before starting this project I re-read Peopleware, and there were a couple of things I tried to keep in mind: set up the right environment for the people, and don't try to artificially create a team. So, creating a good working place was the first thing we tried.

Then there is the issue of making teams jell as Peopleware states... At the beginning we didn't know how to achieve it (nor we do today, it just happens... or doesn't). Is very easy to call a group of people a team, but a team is much more than a bunch of people sitting together. Now I think we are really working as a team, we share a same goal, and we are all really motivated (hope not to break it writing about...) and... to be honest, I still don't know how to achieve it. I guess that things like flexible timetable (people can arrange their time as they want, and they can feel free about arriving late or leaving earlier) can help (well, in fact I think we have a problem: workaholism, so we will try to force ourselves to leave at six, finally!).

But in my opinion there is something else to make (and keep) a team: the competition. When you feel you are racing against someone else: you try to push harder, to go higher, to make it better. Ok, maybe it depends on the project you are working on, but I bet you can always create the illusion.

In our case we all share the feeling of being making a world class product. Whether it is real or we are just dreamers only time (and market) will tell. Anyway, having a look at what others are doing in your field, and pushing harder to improve, seems to be a great incentive for people, and helps creating a common target, and then a team.

Well, I still have to write about what we did wrong... :-P
continue reading
Subscribe to: Posts (Atom)