Archive for the Agile Category

How to Prioritize Requirements YouTube Video

Posted in Agile, Business Value, Project Backlog, Release Planning with tags , , , on July 24, 2010 by vikramadhiman

I have written about how to prioritize before:

As Agile Product Managers, you are constantly prioritizing requirements to get higher value items out sooner. One approach I saw recently, seems very promising. Here is the video. Go ahead and watch it.

Basically, divide your requirements into four quadrants with Y-axis being Business Value and X-axis being Complexity. Hence, you would ideally do quadrant number 1 first and quadrant number 4 last. You can take a call between quadrant number 2 and quadrant number 3 – depending on what your current business strategy/ pull is. Simple. Do it over and over again and we will always provide higher value first.

Team Leads or Project Managers as Scrum Masters

Posted in Agile, Change, Project Backlog, SCRUM with tags , , , on July 22, 2010 by vikramadhiman

In organization after organization, transitioning to Scrum, you see one common pattern. The pattern has existed for at least 03 years now. The pattern is seen in all organizations [at least in India] – established big names as well as upcoming talked about/ blogged about startups. There is a team and there is a Product Owner [or Manager]. So far so good. There is also a Scrum Master – who is also the Project Manager/ Development Manager/ QA Manager/ Program Manager/ Project Lead/ Team Lead/ Developer/ Tester. This raises some questions.

Why is this happening?

I haven’t quite figured out [as yet] why if you are transitioning to Scrum, would you want this to happen – especially when Scrum Master is defined as a full time role in Scrum. The feedback I get is mostly around these lines:

  • There are not enough Scrum Masters available. We can’t just keep waiting for them to turn up. Hence, we identify people internally who can play this role. And, no one wants to do this role full time or take on this title officially. So, there we go. Do your 2 plus 2 is 4.
  • There does not seem to be any value in this role being a full-time – it is something you can do part-time. How much time can removing obstacles for the team actually take?
  • Serving the team, Protecting the team, Helping the team, Guiding the teams use of Scrum is something, which everyone should do and different people are already responsible for these things.

It is easy to dismiss or scoff at these [especially the latter], but these arguments actually seem to be true. I know for a fact that there are not enough Scrum Masters available [possible topic for another blog post]. I also know, that in an organization internally, not enough people are kicked enough to play this role. And, no matter what argument you give, the management is never convinced that this can be a full-time role especially when they see others doing this role.

Is this a good practice?

My views on “doing something just because ABC or some book or some user group discussion says so” are well known. Don’t do it. It is also said, that having no Scrum Master is better than having no Scrum Master. Before we address the question – Is it a good practice for Team Leads/ Project Managers/ Developers to be also Scrum Master, we must see what is it that a Scrum Master does. Like most things, lets start with Wikipedia, “Scrum is facilitated by a ScrumMaster, also written as Scrum Master, whose primary job is to remove impediments to the ability of the team to deliver the sprint goal/deliverable. The Scrum Master is not the leader of the team (as the team is self-organizing) but acts as a buffer between the team and any distracting influences. The Scrum Master ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of rules. A key part of the Scrum Master’s role is to protect the team and keep them focused on the tasks in hand.” Scrum Masters use soft power, servant leadership and trust to help the team become better. Scrum Masters also surrender complete control to Product Owner and the Team.   Some of the qualities we look for in a Scrum Master are humility, staying in the background, integrity and gain trust. We obviously see the clashing red flags here – the Scrum Master is not a leader. However, typically, the Leads/ Managers are that. The team is reporting to them. However, nothing that we talked about in Scrum Master’s role says that you can not have that with the team reporting to you or you working part-time as a developer/ tester. In fact, some people could argue otherwise. If you are a developer and you are convincing everyone to test, you can lead by example. So, let me stick my neck out and say – “I don’t think it is a bad idea.” It is always better to get the right person play a Scrum Master – like role half time than getting no Scrum Master or lousy full time Scrum Master. However, I won’t probably call them Scrum Master. I’ll call them Scrum Evangelist or Process Owner or Scrum Owner or something like that. Why a different name? Because, the team does not report to Scrum Master [yes, just because of that]. And, anyways, it wont be the name, but the intent and the action of the person that will play out louder in the transition scheme of things. Also, you should get these people [and the rest of the team and Product Owners] good coaching.

Some of these people [Process Owner or Scrum Owner] will make Scrum a bad word in the organization. But, so could many Scrum Masters and Product Owners [and even the teams for that matter]. The hope is that organization will pick the right people for this role. Like the rest of the organization, these people [whatever you have called them] will also transition.

Have you gone Beyond Agile Yet?

Posted in Agile with tags , , , , , , , on February 20, 2010 by vikramadhiman

Modern Agile. Post Modern Agile, Post Agile, Beyond Agile, Agile 2.0. Buzzwords 2.0 are flying right, left and center again. At conferences, at workshops and at twitterverse. This at a time, when people and companies, are still getting used to decentralizing and moving faster. But, do we need another movement, another thought process – at this time

Part of Agile’s [or agile's] philosophy is “inspect and adapt”.  Agile is basically the agile manifesto and the values. I read the manifesto and the values many times over : whenever I am confused, whenever I have a question or whenever someone tells me that what I am doing or saying is not”agile”. From the clutter that surrounds discourse around Agile 2.0, the one clear voice seems to be that it depends : “You should be able to question the values too.” Being liberal at heart, I will concede that. Let us look at some values and see if you could do away with the values as such.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. There can be situations where “continuous” is not relevant and probably “early” in not relevant either.  Where exactly? For instance, in a financial application where tax laws are changing 3 months from now – you want to make sure you work towards that rather than focusing on early delivery [before the laws change in bits and pieces or focusing on usability releases while not having time for migration issues at the end].

Welcome changing requirements, even late in development Agile processes harness change for the customer’s competitive advantage. Ok! when you will word the last part of the sentence the way you have worded – pretty much no one will argue against it. However, the same phrase also means that you want to welcome changing requirements because it “can” lead to customer’s competitive advantage. What if it does not? What if its jut a whim of a product manager? What if it delays launch by a few weeks? What if the impact of change is not fully understood?

Just two examples and the generally dismissive note that people ascribe to post modern agile starts appearing like a judgment pronounced a bit too early. But 1+1 does not prove things sometimes. Hence, let us pick from the manifesto itself. The manifesto reads:

  • Indivuduals and Interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

As much as I think and re-think, I can not fault any of these above, in any context if I take out the mean and wicked sense that is. However, there maybe a need to be street smart in some situations. Hence, you want to make sure that your contracts are negotiated well even if your customer collaboration goals are high. Similarly, comprehensive documentation might be required in an outsourcing context. Responding to change vs. following a plan depends where you are. Too early in your product development, changing things frequently could result in chaos. And if your software team is fixing support bugs all the time, processes and tools might take precedence over interaction. The context varies and hence, your values would vary too. The keyword here is “context”. You might have to look beyond Agile Manifesto/ Values sometimes. Is that a radical thought?

I guess if we renamed everything to “contextual” software development or “contextual” management. Or, maybe this sounds creepy. Let’s just say Agile [consider it as an umbrella term] is one of the option available. The key is to realize that Agile [and not agile] is “one” of the option and “not” the option.

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!!!

Agile India Conferences at Mumbai and Bengaluru – Program Updates

Posted in Agile on January 4, 2010 by vikramadhiman

If you haven’t already heard about Agile India [ASCI] conferences at Mumbai and Bengaluru : Jan 16-17 and Jan 22-23 respectively, then you can find more information about them here: http://www.agileindia.org/agileindia2010

I was looking at the Program Agenda in the conferences and it seems like these are heavily oriented around People and People Management. There is only one direct topic on Product Engineering on one/ more of the many popular engineering techniques.

Let us look at the Mumbai conference:

  • Jeff Patton, is a renowned figure in Agile Product Design. He would be delivering KeyNote 1 on the topic: Outside the Code: Using Agile Ideas to drive Product Success. As a product manager, this seems like a great topic. Excited :)
  • Monkey See, Monkey Do : [earlier titled a bit more provocatively] : promises to be a provocative look at the world of Agile coaching/ experts and even some practices. Go in, with no expectations and be surprised [or startled :-)].
  • Getting Ready To Produce – What is Needed Before Iteration 1 is a great topic and would definitely be helpful to all the teams. I know this, because a lot of teams ask me this question all the time.
  • Continuous Monitoring (for Continuous Improvement) is another excellent topic and something that all managers would love – how to track/ meet tracking requirements
  • David Hussman, another renowned figure would be delivering Keynote 2: Adding Sanity to Your Agility: Doing What Works Over Doing What You are Told. Humn! Go for the speaker and not the title. You will benefit for sure :)
  • Analysis Anti Patterns, a great topic [and rare to see Analysis topics in Agile Conferences]. I am sure it would be a must for all the BAs and PMs out there.
  • Agile Adoption with Augmented Distributed Team for developing on top of existing application, is a heavy duty title and also a case study. Hence, this would really be exciting. I am sure everyone who works with distributed teams would take back important tips.
  • A Critical Look at CMM and Agile Through Gen Y is a talk I am looking forward to personally. The title says it all and working with Gen Y for many years now, I think I can do with all the tips anyone can share.
  • Scott Shaw, kicks of the second day with Lean Concepts for IT Professionals. With everyone focusing on “Next Generation Agile”, it is good to go back to the basics.
  • Using ToC and JIT to coach Agile Teams is for all the Agile Coaches and would be coaches.
  • User Story Mapping is the second topic focused around planning and analysis. Again, would be useful for anyone involved in planning, estimating and analysis.
  • Test Automation strategies for Agile is the only engineering related topic in the schedule. And probably the most relevant one too.
  • Agile Fiascos – Art Gallery is the second most awaited talk for me in the conference.
  • Agile Adoption Failure Modes is for you if you are into a few years of your Agile adoption. It might just hit a nerve or motivate you or do both.
  • Evolutionary Architecture and Design just about sums about the Product Design/ Analysis theme perfectly.

Some of the above talks are not featured in Bengaluru. Analysis Anti Patterns, Test Automation Strategies for Agile, Lean Concepts for IT professionals and Evolutionary Architecture and Design are not there in Bengaluru. However, they have some exhilarating talks nonetheless.

Above all, I think it will be great in both the locations, although I will want to be at Bengaluru too :)

Good Enough Software Does Not Mean Bad Software

Posted in Agile, Business Value, Collaboration on December 17, 2009 by vikramadhiman

Software to be released should be just “good enough” and not perfect. You hear that a lot these days. “Good enough” from whose perspective? From the perspective of people who release software or from the perspective of the people who will use software? If it is latter, then who decides what comprises “good enough”?

The thought for this post came from one of people I follow on Twitter @enkerli. In the time I have known Alexandre, I have found him to be extremely patient [he is a teacher of repute and of some experience too]. Yesterday, he tweeted -> “enjoys draft æsthetics yet wishes more developers would release stable products. / adopte certains produits trop rapidement.” You can not but realize that he must have signed up for some web application [we will be using web application scenario in this post] expecting the best, only to be let down by an application where either things are either not there or just do not work. Personally, this happens a lot. I type out the web address of this supposedly great web application after reading a review, blog post, news article – and immediately see tonnes of HTML issues – inconsistent fonts, links not linked [with a # key that seems a favorite of development teams these days], pages that are under construction [with no dates of when you expect these to be working], server bandwidth issues [with web applications unable to handle a few thousand users], forms that won’t submit no matter what you do, pages that go haywire when error messages appear at the top and emails that confuse you further. It is almost as if the teams are not asking if it is “good enough” but even if it is “bad enough”, we can always claim that this is “good enough” for now, more is coming later.

I understand the rush of releasing now than tomorrow, why teams would want to adopt this. If you see lot of people using your application, you know the major risk “Are we building the right thing the right way” is minimized. Further, if the major feedback is on product direction [what the heck is this, abandonment rates are high, XYZ do this better], it is nice to be able to figure out these issues sooner than later. There are multiple ways of checking that [for instance focus group meetings, stakeholder meetings, exclusive previews and private beta]. Probably, like all things that mean no harm, “good enough” is being used by people in a way that suits them. Hence, it is important to understand what exactly “good enough” means. One of the good definitions of “good enough” can be found here. It is more a measure of software quality [and code] – simple, correctness, consistency and completeness. Another good definition can be found here: good enough software is the best software we can write given all the external constraints (money, time, resources, inadequate information, etc) placed on us. It’s certainly not the best software we can write before we clock out to go see our son’s ball game or the best software we can write because we don’t understand the problem space and can’t be bothered to ask. James Bach of Satisfice Inc. describes “good enough” software as making rational choices in the face of market-driven projects. The idea is that it’s okay to ship with bugs as long as you ship with the “right” bugs; that, given enough benefits, the minor problems will be overlooked. You have to be able to distinguish between important and unimportant, necessary and unnecessary. According to Pete McBreen, “The decision to ship is based on the risk of shipping a software product that will be seen as low quality. Once that risk is low enough for the organization, the software is good enough to ship. Conversely, if there are not enough valuable features in the software, even if the defect count is zero, the risk of shipping is too high and the software is not good enough.”

Now, that we saw that “good enough” is not a cosmetic 2 minute pop philosophy concept – the next argument would be “it takes time to write such a software”. Yes, it does. All software needs time to think and write. How much – depends on competence of the people. Like most things Agile, it takes maturity and courage to accept shortcomings to write software that is “good enough” – in a true sense.

Agile India 2010 – Mumbai [Jan 16-17] and Bengaluru [Jan 22-23]

Posted in Agile, Public Speaking on December 7, 2009 by vikramadhiman

Agile India, is organizing Agile India 2010 Conference in 2010.  It is the first two day conference from Agile India and would be held back to back [consecutive weekends] as below:

Mumbai, Jan 16-17 at Narsee Monjee Institute of Management Studies

Bengaluru, Jan 22-23 at Symphony Services

You can find more information at the Agile India 2010 Conference Page [more information coming soon, but if you are interested to speak at the Conference then see here : http://www.agileindia.org/agileindia2010/agile-india-2010-proposal]. The conference tentative schedule would be up soon.

Product Vision : The Key Role and Responsibility of Product Owner

Posted in Agile, Business Value with tags , , , , on October 19, 2009 by vikramadhiman

Continuing with the discussion on Product Owner role and responsibilities, and based on two excellent comments from Martizza and SJJH, let us review the key role and responsibility of the Product Owner. One can argue that the four skills/ competence areas highlighted in the Who can become a Product Owner post along with people management and interaction skills, help the Product Owner articulate, defend and refine the Product Vision. One can also argue that this is a separate skill and competence area and some people can just be better at this job even if they do not have the domain knowledge, are not technically sound or have the necessary experience. What will these people then typically possess? I think it would be a mixture of ability to learn [learn very fast], a highly analytical mind [capable of drawing analogies], intuition [strong emotional connect with real and abstract] and a thinking mind [one that can think even when it does not know it is thinking]. These people would generally believe hopelessely in what they are working on – and it is this belief and the conviction that helps them exude the product vision. Hence, when one is looking to appoint or hire someone for Product Owner position, one should see if they identify with the product and what are the ideas they bring to the table. If the connect is established, the rest of the work would flow a lot better.

So, what exactly does a Product Owner do with the Product Vision. They do 03 things:

1. Define the Product Vision – This involves close connect with the customers and market needs. Hence, domain expertise and exposure to tech support/ marketing comes in handy. Further, exposure to some sort of modeling methods helps the Product Owner define the product vision. Often, the Product Vision phase can take long. As a Product Owner, you may consult other domain experts, technical team or embark on marketing feasibility studies to confirm and reconfirm the vision.

2. Articulate the Product Vision – This is more important than 1. Typically, the Product Owner should be available to the development team anytime and everytime. The Product Owner should be able to sit down with different team members – together, in groups or alone – and discuss aspects related to the product – what will happen in 02 years, 02 months and what do they think could happen. This helps build the trust and orients the developers from a Product Owners perspective – a key requirement to build a great product. One of the means available with the Product Owner, to articulate the Product Vision is Product Backlog and ceremonies like Sprint Planning, Sprint Review help achieve this too.

3. Refine the Product Vision – Each time the Product Owner meets people from marketing, sales, technical support, development team, testing team or customers – they will keep uncovering new things about the product. It could just be new technology [Google Wave was launched a few days back for instance] or a new trend [micro-blogging and social media]. This can represent opportunities or threats. Product Vision is not stagnant. It is dynamic.

If a Product Owner can take care of the Product Vision, the Product would largely take care by itself.

Who can become a Product Owner?

Posted in Agile, Collaboration on October 14, 2009 by vikramadhiman

Who is qualified to become a Scrum Master or Who can play the role of Scrum Master, is one of the most frequently asked questions in the Agile community. I believe the more important question and often the one that does not get asked is, Who can become a Product Owner? Why is this question more important? It is because, what you are building (and why you are building this) is often more important that when are you building and how are you building it. The last two questions are important but only after the first two. The first two questions also help frame the vision for the product as well as:

1. Chronologically, Product Owner role starts before any other role in an Agile or Scrum team.

2. Depending on what is your vision for the product, you could outsource a part of whole of it right at start or at a later date.

3. You build the product to achieve a particular purpose. The person responsible for the same is the Product Owner.

If this is such an important question [and correspondingly role], then what are the qualifications one should look for when selecting a Product Owner? I have been a Business Analyst and Product Manager. I have interacted with many Product Owners too. There has been an interesting discussion on who can be a product owner on the Scrum Development Yahoo Group recently too. Based on the feedback collected from all these sources, I have compiled a list of who would make an ideal Product Owner:

1. Product Owner is a part of the team and should hence be available as much as possible to the team [close to 100%]. Hence, PO can only be someone who is available to the team 100% of the time.

2. Product Owner needs to understand the big picture – the philosophical as well as practical aspects of what is being built. This would often require excellent domain knowledge.

3. Product Owner should know what will work – hence, exposure to marketing and sales is important. This is also often called Voice of the Customer. Basically, Product Owner should deeply empathize with customers – their needs, their frustrations and their wishes.

4. Finally, any exposure to technology – programming, UI, QA is an additional bonus [in most cases a required bonus].

The next question is which of these is the most important requirements? I think all 04 and in given order of priority.

One additional requirement, which I believe all people should possess and so should Product Owners and Managers : People Management and Interaction.

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.

Follow

Get every new post delivered to your Inbox.