Archive for the Retrospectives Category

Agile Mumbai 2010 – A Review

Posted in Agile, Public Speaking, Retrospectives on January 19, 2010 by vikramadhiman

It is difficult to review a conference objectively, if you are also a volunteer organizer. Also, most of the people who were other volunteers are people I meet daily too. I will try.

First of all, I must say that this was definitely the best Agile conference I have been to. It is right at the top in my list of best conferences as well. There was a strange fluidity to the way the program went – there was hardly a moment when nothing was happening – one talk followed by another followed by activity followed by discussion followed by more talks and so it continued for the 2 days. It was also one of those conferences where the things just kept getting better. The best part of the conference was the intimate and close [and refreshingly candid] Q&A session with the 4 Gordon Pask Award winners. The food was nice and the breaks were lively with people coming together in huddles and discussing their experiences. I am sure every attendee went back with new acquaintances. We had a hard time bringing everyone back for the talks and once a speaker had to actually go to the tea break venue to let people know that his talk was starting. “Discussions” – that was the key take away from this conference. Unlike previous conferences, where most of the audience fell mostly into two slots:  skeptical or zombie; here everyone was brimming with ideas, thoughts and opinions. Probably, years of implementing Agile have now given the community a voice and the voice a community.

My thoughts on the talks I attended:

  • Outside the Code: Using Agile Ideas to Drive Product Success by Jeff Patton: This was a good start to the conference. Jeff Patton started the conference by focusing on “Product Success” and doing things which can help discover, identity and lead to success. Some of these things are not even related to coding. I thought this really set the pattern.
  • Monkey See, Monkey Do by Naresh Jain & Sandeep Shetty: I thought this was the best talk of the conference. It came from the heart and I liked it how Naresh was being provocative and Sandeep tried to then temper it down a bit :) I liked the provocative part of it – at presentation was WTF [way to fail I mean :D] but after about the first 30 minutes, everything started ringing a bell and then it was belling all over.
  • Adding Sanity to Your Agility: Doing What Works Over Doing What You are Told by David Hussman: David touched on several examples of how doing something that experts tell you, can be doomed. As he told story after story, you could see nodding heads in the audience – almost confirming what they have been waiting for someone to confirm. David also has a nice way to simplify what could be radical thoughts – to an extent, that you treat those as obvious and not radical.
  • Analysis Anti-Patterns by Tarang Baxi from Thoughtworks: Excellent. Each of the patterns came from experience and not from text book. They even challenged the audience to come up with names for some anti patterns [and there were gifts too]. I thought this was nice and the second best talk of the conference for me :)
  • Transcending Cultures, Timezones and Countries by Mahesh from Thoughtworks: Mahesh was patient and methodical. I thought he could have moved a bit faster, but it was a nice compilation nonetheless.
  • Using ToC and JIT to coach Agile Teams by Naresh Jain and J.B. Rainsberger: Sometimes college professorial, sometimes challenging and sometimes corporate workshop-like, this was one talk that had it all. I was a touch disappointed because it deserved more time. Maybe, next time they can do this over 2 consecutive sessions. However, what we saw was nice – practical to the core.
  • Stop It Or I will Bury You Alive In A Box by J.B. Rainsberger: This was another of the “shake you to the core” talk. I liked aspects of it, did not agree with others – but it was definitely the most energetic and lively talk of the conference.
  • Evolutionary Architecture and Design by Pradyumn Sharma: A simplistic and effective presentation for beginners. I thought there could be more depth, which I am sure would be added by the presenter for his next talk, based on Q&A round at the end of the talk.

I loved Programming with the Stars. It was fantastic. I thought all the teams were very brave and judges were honest and cool at the same time. Bengaluru promises to be even more fun :) Unfortunately, I did not attend any of the product demos. I don’t think they are recorded either. The sponsors : Xebia, Thoughtworks and BNP Paribas, participated enthusiastically in the conference and it was good to see actual people from sponsors rather than just their boards. As already mentioned, the panel at the end was superb. Topics like “Do employees really care about Agile”, “What do you think about Director of Agile Software Development titles”, “Are story points scalable” and “Is TDD for everything” started great discussions.

P.S. One of the highlights of the conference was the talk by Captain Planet. It was short, compelling and insightful. I am switching off one monitor already, abstaining from plastic and trying to do my bit by walking as much as I can. Do your bit too!!!

A Sprint Retrospective – The Ideal way to Start Agile

Posted in Agile, Collaboration, Retrospectives, SCRUM on September 17, 2009 by vikramadhiman

Is the Certified Scrum Master class I attended about 03 years back – Pete Deemer, the Guru who led Yahoo’s adoption of Scrum in multiple locations, said “Even if you did not do anything else but only Sprint Retrospective, you will see tremendous improvements in your process or way of working.” That is, even if you were not doing any of Sprint Planning, Sprint Backlogging, Product Backlogging, Sprint Reviewing or even Daily Stand Upping, you would be doing very well, by doing just one practice – Regular Sprint Retospecting. That is definitely a tall claim. And from my experience in the last 03 years, a true one too.

Let us look at the basics first. What is a Sprint Retrospective? Rather, what is a Retrospective? As per Wikipedia, Retrospective (from Latin retrospectare, “look back”) generally means to take a look back at events that already have taken place. For example, the term is used in medicine, describing a look back at a patient’s medical history or lifestyle. It is particularly useful to look at the medicine analogy here. Retrospective, in medicine, means looking back at medical history.  In Software Development, a retrospective means looking back at project history. This is typically, with a team and depending on the context it could include project managers, senior managers, directors, VP’s, whole team, testers, developers, business analysts in any combination. Extending the analogy with medicine further->typically, you will look at the medical history only if something has gone wrong or when the person has died [and you are doing an autopsy]. Unfortunately, most retrospectives in Software Development are also held, when something has gone wrong or at the end of a project. Agile Software Development uses retrospectives, like regular diagnosis [and not just when something bad happens]. After every iteration or sprint, the team gets together to discuss what was successful about the project or time period covered by that retrospective, what could be improved, and how to incorporate the successes and improvements in future iterations or projects.

Agile and Scrum are adaptive processes.Retrospectives and Daily Stand Ups are too practices which enable inspection as well as introspection – both necessary for adaptivity. Even if the team did not do a product backlog or sprint backlog or burndown chart and the team just did regular Sprint Retrospective, what will it unearth? One of the first things, they would probably identify is that we never knew where we are and what everyone is doing or where someone is stuck. They will come up with burndown charts [or some variant/ substitute] as well as more regular meetings [daily stand ups]. More features like sprint planning, sprint reviews, product backlogs etc. could come up. Some things like no change during the sprint could never come up. Hence, the team could come up with their own version of Agile – something that fits them the best.

The above paragraph assumes some critical things:

  • The team is empowered and capable to drive a retrospective as well as implement the action plans that are highlighted for the next iterations. Significant management as well as team buy-in for being process leaders rather than process followers is hence, required.
  • Given the nature of retrospectives, they can degrade from looking back to blame games quickly. Hence, good facilitation and guidance during a retrospective is required.

Some retrospectives can be more productive than others. We will take a look at more on retrospectives in the future articles. You might also be interested in the Start, Stop, Continue Technique of Agile Retrospectives.

A Successful Retrospective

Posted in Retrospectives, SCRUM with tags , , , , , on July 31, 2009 by vikramadhiman

Someone asked me when do you know if you just led a successful retrospective.

My first reaction was that I will have to think and come up with some metrics which optimize the complete value chain. However, I started answering sooner than later. I stopped in between, reflected and continued. On the flight back, I reflected again on what I said. I thought it made sense. Let me know what do you think?

An effective or successful retrospective should have the following characteristics “come out”:

  • No one should come out of the retrospective with ill feeling or negative thoughts towards anyone.
  • No one should come out of the retrospective thinking they have not been heard properly.
  • No one should come out of the retrospective saying they are not a party to this decision.
  • No one should feel that the real reasons or suggestions did not come out.
  • The team (and PO – if he/ she was present in the meeting) should be buzzing with enthusiasm in being part of something unique.
  • The team (and PO – if he/ she was present in the meeting) should come out of the retrospective with more understanding about each others roles, expectations and requirements.

I think this made a good checklist – mentally, for a Scrum Coach.

Scrum Exposes Bad Processes and Obstacles

Posted in Agile, Retrospectives, SCRUM with tags , , , , , , , on December 19, 2008 by vikramadhiman

In our last post, we discussed the Agile Retrospective technique of Start, Stop, Continue or SSC. In this, post we discuss a technique first tried by Pete Deemer [CST, co-leader of Yahoo's implementation of Scrum].

Often, as the end of a sprint, the team comes back and says things like

  • Its more stressful in Agile
  • Things are worse than before
  • Agile does not work
  • We were better off before

If as a Process Coach or Scrum Master you hear something like this, you can try this in your retrospectives:

  1. Ask the team to collectively come up with a list of things they thing are better than before/ is working well and also what is not working well/ worse than before. So, you have two lists : Better and Worse.
  2. Now ask each member to mark each item on both the lists from three possible options : Caused by Scrum [C]/ Agile, Exposed/ Made Visible by Scrum or Agile [E], Does not relate to Scrum/ Agile [U].
  3. Compile the score and let there be pin drop silence in the retrospective.
  4. The team may find a lot of C’s on the “What’s Working Well or is Better than Before” side of the board, and a lot of E’s on the “What Could Work Better or What is Worse than Before ”; this is good news, even if the “What Could Work Better” list is a long one, because the first step to solving underlying issues is making them visible, and Scrum is a powerful catalyst for that.
  5. The team’s opinion and acceptance of Agile/ Scrum would have undergone a complete 180 degrees turn.

It is often useful to keep a snapshot of the whiteboard where these lists are maintained and keep revisiting them in each of the Retrospectives. This is especially useful for the teams which are transitioning to Scrum or Agile way of working.

Agile Retrospectives Start Stop Continue

Posted in Agile, Retrospectives, SCRUM with tags , , , , on December 15, 2008 by vikramadhiman

Revisiting the discussion on agile retrospectives, it is recognized by some as the single most effective practice/ ceremony of Agile. This could be because this exercise:

  1. Brings the team together
  2. The team inspects what it has been doing
  3. The team tries to adapt for better results

On a score of 04 based on Agile Manifesto, Agile Retrospectives would score a 02. They are about individuals and interactions and help the team respond to change. In addition, Agile Retrospectives help the team focus on 02 other principles of the Agile Manifesto : Customer Collaboration and Working Software.

There are various approaches in conducting Agile Retrospectives. One of the most common approach that is advocated by many coaches is “Start, Stop, Continue”. A very simple approach, this type of retrospective is usually conducted as follows:

1. All team members make 3 lists – what is working well and they should Continue doing, what is not working well and should be stopped, and what is something that can be explored/ Started.

2. One-by-one everyone adds their points to a central whiteboard/ list. They can do a plus 1 if what they want is already on the list.

3. After everyone has completed this, the team picks up the items with most “plus 1″.

4. They commit to “some” or “all” items in the 03 lists – Start List, Stop List, Continue List.

5. In the next retrospective, they go back to this list and evaluate how they have done [this can be done in a variety of ways too - everyone votes on whether they were successful in implementing something or not and after this a new Start, Stop, Continue List is drawn].

6. Some people like to keep it mechanical – vote and decide. Others like a lot of brainstorming, discussions and debates. Its useful to have debate on what you are planning to do. The only downside of debates in retrospectives is that more powerful or vociferous attendees may overpower others. Hence, the Scrum Master has to be really good.

This is a relatively simple approach and helps the team inspect and adapt continuously.

P.S. If you are in India, and haven’t taken this “Are we Really Agile Survey” then, I recommend you do so right away : http://www.surveymonkey.com/s.aspx?sm=uFtT7z80mHpM7hGvLFJtZg_3d_3d [it will only take a couple of minutes and is straight forward multiple choice survey].

Next Group – Session VI

Posted in Coaching at Net Solutions, Retrospectives with tags , , on February 4, 2007 by vikramadhiman

This session was not about Agile practices but an understanding of what makes Agile work. It was suitably titled “Agile Thinking”. Agile Thinking focussed on retorspectives/ root cause analysis, energized environment and informative workplace. We focussed on how having the right information at the right time for the right people is key to being Agile. Another focus was on understanding how motivation, energy and intrinsic desire to innovate is the key to people delivering good quality output. We also discussed how having fun in the workplace was one of the key requirements for an energized workplace. Finally we focussed on how retrospectives can enable people to focus on the right things. The root cause analysis was discussed with two live examples as a technique to unearth the causes of problems/ obstacles.

Ours has traditionally been an organization which focusses on people sitting late as a sign of their hardwork. Focussing on energizing workplace allowed participants to come up with their suggestions on how to organize their lifestyles. One more important part of the session was a live use of root cause analysis.

One of our projects had been run under a lot of on the fly requirements, aggressive deadlines, unpredictable customer behavior and as you would know – lot of stress. As soon as the beta went live, customers registered on the website right, left and center. The website had too many bugs, feature requests, support emails and more importantly a harried/ stressed out staff.

1. We started with some symptoms first. The main one was “It was difficult client to manage”.
2. So we asked the first Why?
3. He was difficult because he was an intermediate client who was serving an external client and was communicating deadlines to them which we were not aware of. Also, he was unreasonable most of the time.
4. We asked the second why for the second part of above cause
5. He was unreasonable because he had an unstable mind and thinks of ideas all the time making our efforts unstable.
6. We asked the third why
7. We had coded in hurry so our architecture was not such that we could support rapid UI changes without affecting the underlying logic. And we were ourselves just following the client instructions.
8. We asked the fourth why
9. This was amongst our first dot.Net projects and the project was also domain specific.

At this point we thought we would do some SSC [Start/ Stop/ Continue] and came up with the following list:

1. Start to do:
a. Have better understanding of the end client deadlines
b. Refactor mercilessely and adhere to coding standards come what may
c. Start thinking about UI designs

2. Stop to do:
a. Stop coding in hurry and not obeying business layer logic
b. Refine the code in Data Access Layer

3. Continue to do:
a. Code fast and be as responsive as we have been
b. Follow the wireframing process

We intend to continue such exercises in future sessions as well.

Follow

Get every new post delivered to your Inbox.