I was told the other day that Agile only works for Web Development. And guess what, they guy was right.
Agile only works for Web Development, and…

Developing Cars

Wikispeed is an automotive manufacturer that develops cars through modular design. The company was founded by Joe Justice to produce a car that would compete for the Progressive Automotive X Prize competition in 2010. They came in 10th place, no mean feat given they were competing with major world wide car manufacturers.
Wikispeed uses Scrum development techniques to improve productivity and development of their cars.
Yes, Wikispeed is a small car manufacturer, run by volunteers, but they are making ripples in the car industry with their rapid development times.
Toyota, this goes without saying. The Toyota Production System is the basis for Lean which is then in turn the basis for Agile Development. Toyota has been in the agile game for over 70 years. They are now the Third Largest (In 2017) car manufacturer. Down from top spot.

Education

Eduscrum is a version of Scrum modified for education in schools. Developed in the Netherlands it teachs kids to be self organizing of their learning.
Students plan and determine their own activities and keep track of their own progress The Teacher determines the assignments, coaches and gives advice.
Students that work under eduScrum have better grades, better understanding of material than their non-Scrum counterparts.

Law

Lonely Planet, the company that develops those travel books, thier legal team here in Melbourne uses Agile techniques to manage their workload.

A Whole Town

Grow Cornwall is an experiment for a town in Cornwall England to introduce Agile techniques to businesses. The process has helped companies and businesses improve their workflow, throughput and thus profit.

Law Enforcement

The Ghana Police Service began adopting Scrum practices for its Police Force in January 2017(Not its IT Division) to become a world class police service. Their goal is to be come one of the top 10 police services world wide in 4 years time.
With roughly 33,000 police offices and an additiona 14,000 community support officers, the task isn’t easy, but they have taken up the challenge.

Sales

Tenfold is a software company that has applied Agile to their sales process.

Manufacturing

Agile Manufacturing means that things have come full circle. Using techniques from Agile, companies are applying these techniques to manufacturing and are seen to be taking Lean Manufacturing to the next level.

Yep, Agile only works with Web Development – NOT!

Let me know in the comments if you have any other examples of Agile use outside the IT Sector.

If you have a look at the structure of an IT department, well actually any department within a large organisation and you will see everything is usually grouped based on specialties.
For example, you have the people who are in charge of the CRM systems. The ERP systems. Billing systems, Integration systems etc which is all fine and dandy for day to day operation, but what happens when some new work needs to be done? New work is usually done within projects. How are these projects resourced? Well, sometimes people will be taken out of these departments, and they are put onto the project. Other times, resources will be outsourced to the likes of Wipro, Capgemini, Accenture and so forth. This is all well and good, and gets the work done, but what happens at the end of the project?
Handovers are done to the support teams, you may have a warranty period where the developers are around to fix any “defects” and inconsistencies, and eventually the teams break up or in the case of our outsourced resources, they go back to the proverbial bench to be picked up for the next project.
What happens to all that learning on how the system works, the improvement of the development process, the working as a cohesive team? Well, quite frankly it all goes “poof”.
It doesn’t matter if the project is a Waterfall project or an Agile project. All the learning of how to work together, work cohesively, improve the development process all disappears. The worse thing is that this is considered normal.
This is siloing of resources.

This is the concept of Bring the people to the work. You have a job or a piece of work that needs to be done, so you gather the people that have expertise. Do the work and then once they are done, disband them. I see the allure of doing this. You only keep the people you need for the duration of the work to be done. So costs are reduced.
The problem with this paradigm is that it works well with manual low skilled labour or where there is a specific one off job.

The problem comes when the work is more ongoing. Specialized. For example, building a house, or creating software. Sure you can get away with bringing in people short term, but what you will find is that if you bring them in for the long haul, then things get better.

For the example of building a house, a building company will have its own carpenters, plumbers, concreters, bricklayers, electricians etc. They still move from house to house, but the team remains pretty much constant. The team when done right will work cohesively. They work together in each others interests. They get the job done quicker and better.

The same with Software. You have a team that consists of multiple skills. Developers with a range of technologies and systems (CRM, ERP, EAI and Billing systems etc), DBA’s, testers, BA’s etc. Then when you have a new project that needs to be worked on, you bring the work to this team. This team knows how to work together. If they have used Agile methods, they have improved over time. They know how to get things done quickly. This team is long lived.
You may have different teams with a slightly different mix. They work on other segments of the same project or on different projects. To make things even more interesting, these teams also run the system, not just do project work. In this scenario, all learnings during the project remain and continue to the next project, and the next and the next etc. If the people also run the systems, then there is little to no handovers required.
If you use external vendors, then rather than keep these people on the project for the full duration, slowly replace them over time with your own people and have the vendors teach them the technology that you are not proficient with. I have seen too many times where external vendors a brought in, do the work. Hand over to the BAU team, bug out then the BAU team is left scratching their head when something goes wrong because they lack the one thing that would have helped – Experience.

The second problem is within the teams. You have developers, DBA’s, BA’s Testers etc. Each person does their specialty. If the skillset is not present, then everyone continues and work banks up until that skillset comes back.
This is the second level of Siloing and it prevents things from getting done.
In Scrum, there is the concept where there are only 3 roles. The Scrum Master, Product Owner and Developers. There are no sub roles such as Tester, DBA, BA etc under Developers, just Developers. It is expected that each person with that role is willing and capable to an extent to do the job of all roles. Some may be better than others, some may have no experience, but that is irrelevant. Those in the role of Developer are encouraged to understand all disciplines even though they may specialize in one.
For example, say a project has no tester – they are on sick leave. Programmers (as opposed to Developers) continue coding. Work mounts up ready for testing. Nothing gets tested and then at the end of the sprint/iteration, nothing is marked as complete. What happens then? From my experience, either someone external is brought in to do the testing at the last minute – it may even be the scrum master or product owner or the work is taken to be OK and is marked as “Done” or any issues found later and bug tickets are raised or everything goes back onto the backlog until the tester is back. Then they have a large batch of work to get through.
One thing that I have never seem in my limited experience with Agile is for the developers to step up and do the testing. I don’t see the problem with this. There are no sub roles in scrum. Everyone is a Developer, everyone is a tester, everyone is a BA. Everyone has the duty to test. This is the tearing down of the inner silo.
I know, if you test your own code, you may still have bugs from misinterpreting the requirements. Well, testers can have the same problem if the requirements are not clear enough. The concepts of Specifications by Example should take care of situations like this.
Another reason I have been told that this isn’t a good idea is that as a developer testing your own code, you can just pass it through. My thinking on this is that if you are willing to do this, then you are not being professional. Secondly, if you are willing to do this, then there must be an underlying problem with the team, is the team not feeling pride for its work. It may be because the team are being dictated to and have therefore lost engagement, team members may have personal problems, team problems such as not getting along or something else altogether. I don’t believe anyone wants to sabotage their work intentionally.

If you still are unhappy, then have another team member – any member of the development team check the work.
I’m not saying get rid of testers, but I’m saying that if there is no one else available you need to step up and help.
This also holds true if the tester is inundated with work. Step in and bring that WIP down.

I’m reminded of a story in Team of Teams, at least I think that is where it came from. I’m paraphrasing here but…
If you are shot in combat, you don’t want to be sitting there bleeding away while the medic is either working on someone else or shot them self. You want for example the communications officer to be able to patch you up even though they do not have the full training.

So break down the silos. Everyone should learn a little about everything, even though they may specialize on one thing. We are all in it together, we should be helping each other out.

The following article first appeared on the Scrum Alliance Member Articles

To better understand the Scrum Guide, I’ve been deconstructing it by writing it longhand (yes, longhand — I’m a little crazy that way). I worked on the 2013 version of the guide, but I decided to backtrack a little, so I started with the section on Scrum values.

When the values of commitment, courage, focus, openness, and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.

This got me thinking about the Toyota House metaphor that has the foundations of commitment, courage, focus, openness, and respect. Its pillars are made of transparency, inspection, and adaptation. Then, we have the roof of trust.

To me, this is the Scrum Team House.

It has been a while since I listened to Patrick Lencioni’s audiobook The Five Dysfunctions of a Team. This book is one of those fictional management novels that tells a story to get a point across. After reading the above passage, I saw the connection between Scrum values and Lencioni’s work.

The five dysfunctions of a team

Lencioni’s book describes the following five dysfunctions of a team.

Absence of trust

This isn’t the type of trust whereby a manager trusts his people to do the job right, although this is part of it. This is the trust whereby a weakness, be it personal or professional, will not be taken advantage of. This is the kind of trust that makes you feel that your team members have your back rather than stab you in the back. If something goes wrong, they will not attack, criticize, blame, and shoot you down. Instead, they will help, they will encourage, and they will listen.

A lack of trust also leads to lack of respect for other team members. Would you respect someone who used your weakness against you? Do you show respect for someone when you have exploited their weakness?

Fear of conflict

Lack of respect causes fear — fear to voice opinions lest you be criticized. Fear to speak out when you think something is wrong or when you disagree with the team. Fear to try something new.

Things become opaque, convoluted, and complex. Knowledge is hoarded and ideas are not expressed. This lessens the team’s courage to lead constructive discussions and constructive conflict to help problems become openly discussed and explored for alternative solutions.

Lack of commitment

Fear leads to lack of commitment. Would you commit to something you had no say in? Would you commit to something you didn’t believe in? What you end up getting is compliance. People doing the minimum requirement. Work then transforms into being just a job — something you do for a paycheck. When this occurs, no one will want to take ownership of anything.

Avoidance of accountability

To avoid blame, finger-pointing ensues. Why would anyone want to take responsibility for something going wrong if you get in trouble? The blame game prevents the inspection of problems and thus the proper resolution to those problems. You will have one of two outcomes: Only superficial resolutions will be put in place, or the problem will be swept under the proverbial rug.

Inattention to results

We have a saying in Australia, “Head down, bum up,” which is a figurative expression for working hard (think of a child kneeling down on the floor, working in deep concentration on something like a drawing). So in this climate, people are working hard, just doing their job, not worrying about their surroundings, and not focusing on results. They do only the hard slog (another Aussie slang term for doing grueling work). The team cannot adapt if it has this mindset.

I can see now that the Scrum values are precise. They exist to help build a team that lasts. They provide the foundation for a high-performing team. But as we also can see from Patrick Lencioni’s work, it does not take much to tear down a high-performing team until it becomes a mediocre team or worse — a team, or at least some members, that actively works against the group’s best interests.

By simply removing the “roof” of trust, a team can deteriorate quickly, and when that trust is gone, it is difficult to get it back. If the cycle repeats, each time trust is lost, it’s even harder to regain it, until trust will eventually reach the point of no return.

At the turn of the century in England, milk was delivered in open glass bottles. There were 2 birds that loved to drink the cream that would settle at the top of the milk. These were the Blue Tits and the Robins.
Then after world war 1, milk was delivered still in bottles, but with an aluminum top to prevent the milk from spoiling.
This also prevented the birds from drinking the cream. At least temporarily. You see, the blue tit learned how to peck through the aluminium foil, where as the Robin did not. Throughout England, Blue Tits would get the cream, but Robins could not figure it out. Now you would probably think that Robins are not as intelligent as Blue Tits, which is why they could not get to the cream, but this isn’t the case.
Robins are territorial birds. They come together when mating, but then quickly stay on their own in their own territory driving off other Robins. This means that they do not get a chance to share knowledge. Whereas Blue Tits are social birds, when one bird figures something out, it is shared among other birds. So if one bird figured out you peck through the aluminium foil to get the cream, soon all birds would know. For a Robin, if one bird figured out how to get to the cream, only that bird would know. The group misses out.
The same can be said with Humans. Those that hoard knowledge may be smart on their own, but the overall system looses out. Whereas those that share knowledge as a group, all benefit and get better.
The same goes for anyone who defends their territory (Those unwilling to learn from others) will also miss out on gained knowledge.

We can see this play out socially at the moment in Facebook. A mother shared how she removes splinters using a syringe by usig suction instead of jabbing her children with a needle to fish the splinter out. This simple tip has made it across the world and is being shared by news organisations, newspapers etc. It just shows how infectious learning is.

So share your knowledge. Write blogs, do talks, not only within your own team, your own company but with all who will listen. In the long run, we all benefit.

I was recently contacted by a company that had read one of my posts and wanted me to share one of their posts. Usually I would think this is spam and move on, but I do check first.

The reason I’m telling you this, is that the post I think is interesting and I’m willing to share for that reason.

Here Patrick Hogan, one of the co-founders of Tenfold outlines how Agile can be used in sales. Sales in general, not only Software sales.
This fact alone I think deserves a mention. It shows that Scrum and Agile in general is not limited only to Software Development, but not only that. I think he is right.

Its been over 7 years since I worked for a vendor, but I worked for one for over 10 years (SeeBeyond then Sun Microsystems), and although I didn’t work directly in sales, I was on the implementation side – I did work with the sales reps. Especially when we implemented Proof Of Concepts and being a small office, we got to know one another quite well.

I remember the sales process was all about wooing the customer. Telling them and sometimes even showing them how well the software would fit in their organisation and solve their problem. Sales cycles would be in months if not years. Especially in Australia.

Now, things are different. At least I see it from a customer perspective now that I work on the other side of the fence. There is so much open source out there now, customers are more informed. The sales process is much harder.  It requires that sales people adapt and change as required and what better way to adapt than to use Agile methods and processes.

Patrick has given a high level overview on how this can be achieved for a sales team.

I suggest you read the article for yourself.

https://www.tenfold.com/sales-leadership/agile-sales-teams

This article was originally published on the DZone Agile Spotlight blog as part of the DZone Bounty competition.

Scrum and Kanban are but two out of many Agile methods currently in practice. They are both completely different in implementation but have fundamental similarities. Here we explore the differences, the similarities, and how they relate to other Agile Methods.

Scrum

Scrum, developed by both Ken Schwaber and Jeff Sutherland was introduced to the world in 1996. The inspiration of which was Jeff’s time as a fighter pilot in Vietnam, an article in the Harvard business review, and basic observations on how people actually work to get things done. Not the processes that are enforced that tend to both manage how the work is done and actually slow down progress.

Scrum got its name from a rugby scrum where teams huddle together to try to get the ball.

Given that Scrum was introduced in 1996, and in development much sooner than that, it predates the Agile Manifesto by at least 5 years. This means that Scrum helped influence the Agile Manifesto. Not the other way around. In fact, Jeff and Ken were one of the original founders.

Scrum is a cyclic framework that tries to solve problems and accomplish goals through experimentation. The Scrum “process” starts with a planning session, where the Scrum team plans the experiment. The Scrum team consists of the Scrum Master, who makes sure that the Scrum process is followed; he role is required to prevent reversion to old habits. There’s also a product owner, the person who holds the vision of what the team tries to accomplish. And, finally, the development team. Not developers in the software development sense, but developers in the product sense. In other words, the software developers, testers, architects, etc.

Then, during an iteration, i.e. a period of work, of between 1 week and 1 month – usually 2 weeks – known as a “Sprint,” the development progresses. Teams hold a daily, 15 minute meeting between to plan each day’s activities. The experiment is to try a better way of working, it is executed by, well, doing the work. At the end of the iteration, the stakeholders review the work done to make sure it meets what they require, and the team then reviews how the actual experiment did and then determine the next experiment. Whether it is a modification of the current experiment or a new experiment.

I’ve highly simplified and modified the description of Scrum here, but I wanted to show that there is a process to how Scrum works.

Kanban

Kanban was created by David Anderson and was released to the world through David’s book “Kanban: Successful Evolutionary Change for Your Technology Business” in 2010.

Kanban is a Japanese word that means signboard. The system has its roots in the Kanban cards used by Toyota to indicate when components on the assembly line of car manufacturing need to be replenished.

When an assembly line worker runs out of bolts on the line, for example, a Kanban card attached to the bin is taken and brought back to the factory store, where it triggers the replenishment to the assembly line worker. Another Kanban card which was attached to the replenishment triggers an order from the supplier, who then replenishes the factory store. The system is designed so that only when parts are used are they replenished. The system is a pull system where the use of a component triggers the pull of additional resources for replenishment.

The Kanban system works in a similar way. The Kanban cards here represent the work being done as opposed to components. The cards are then pulled from one process to another. The other component of Kanban is the visualization of the work being done. This usually takes the form of a board with the columns labeled: to-do, in process, done.

Kanban, unlike Scrum, is not process driven. Also, the starting point of Kanban is actually to start with the way you work at the moment, whereas Scrum completely changes the way you work.

So with Kanban, you visualize how you work and the different stages the work goes through, via the Kanban board. You have your Kanban cards that represent the work and then move the cards as the work progresses through each stage.

Very simple, but this is the easy bit. This is also the point where many implementations of Kanban stop.

The hard bit of Kanban is to track and monitor the progress of cards across the board. This includes the determination of bottlenecks – where cards bunch up – and determining the overall time a single card needs to progress across the board, recording both the time the card is actively worked on and the time it is idle.

Then, using various techniques and experimentation, you continuously try to improve the flow of cards.

As you can see, Scrum and Kanban, although completely different, do have some fundamental similarities. These being that, through experimentation, you continuously try to improve how you work.

The strange thing is that practices from one method start leaking into the other. You would be hard pressed to see a Scrum implementation that doesn’t have a Kanban board (either physical or virtual) to see how work flows through their team.

With Kanban implementations, you may see teams do regular reviews every couple of weeks. They may do daily stand up meetings to plan the day’s work. Some even have a single person who is in charge of the backlog of work. They may even be called the “Product Owner.”

These methods are different to Waterfall, which is very process driven. Follow the process ad infinitum to do the work. Everything is determined up front, there is no change during the process, and no review, at least not until the end of the project.

Everything Else

The similarities between agile methods are not just common to Scrum and Kanban but are actually fundamental to most Agile implementations (of which there are many). Craig Smith has a great presentation on 40 Agile Methods in 40 minutes – and this is still only a small portion of the number of Agile methods out there! Many of these methods vary on the degree of process, for example, XP has practices including Test Driven Development and Pair Programming, among others. While others such as DevOps and SAFe (Scaled Agile Framework) have a basis in other Agile methodologies, but expand on them.

Just like between Scrum and Kanban, practices in Agile methods bleed into one another. Test Driven Development, User Stories, Continuous Integration, and even pair programming from XP are pretty standard practices regardless of which Agile method has been adopted.

Lean software deals with the elimination of both wasted effort and time and is resource based. DevOps deals with automation. These are both ways of improvement adopted by agile development teams.

Those methods that do not have these fundamentals tend to have no benefits other than making the company “feel” like they are doing Agile.

Now, it doesn’t matter which methodology you choose, or if you make your own. What is important is that you have the fundamentals of Continuous Improvement through experimentation and actually reviewing the experiments. This is known as the Agile Mindset.

The Agile Mindset requires that you actively try to continuously improve and that you verify that improvement.

The various methods, be it Scrum, Kanban, or something else, are but methods to help implement the Agile Mindset. Without the Agile Mindset, no matter what method you choose, you are most likely to fail in the long term.

For more information on the Agile Mindset, I suggest searching for “Linda Rising Agile Mindset.” Linda has done a number of lectures on the Agile Mindset which is heavily based on Carol Dweck’s book “Mindset,” which looks at the difference between the “Growth” mindset and the “Fixed” mindset.

I recently passed my PSM 1 certification and I thought I would go through my study techniques for anyone interested.

Now, these study techniques are how I learn, and not necessarily how you may learn, but my thinking is that it doesn’t hurt.

I should mention too that I completed my CSM certification a little over 18 months ago, so I’m not a complete newbie. I’ve also been reading quite a lot about Lean. TPS, Agile Methods and taken quite a number of courses online. I follow podcasts, recorded conferences and follow blogs such as DZone’s Agile Zone, The Scrum Alliance blog. I have even written several articles for both. I have had experience with Agile “Projects” both as a member of the Development Team and as Scrum Master.

I should also mention that getting your certification(s) does not make you an expert in Scrum or even Agile. It only confirms your knowledge of Scrum. But saying that, once you learn the techniques it should go a long way towards understanding. I think of the certifications as a step along my Agile journey. Not the destination.

I don’t want to debate the merits of certification here also, I will leave it as a personal choice, which I think it should be.

The Exam

The exam itself is an 80 question multiple choice exam with a time limit of 1 hour. In order to pass, you need to get 85%. The exam itself covers what is in the Scrum Guide, some scaling of scrum questions and some situational questions that are not covered in the guide, but require understanding of Scrum to answer.

The Scrum Guide

The first obvious thing I think someone should do is read the Scrum Guide. The exam itself is one the scrum guide. So read it.

Now, the next thing I decided to do was deconstruct the Scrum Guide. How did I do that, Well. I wrote out by hand (yes! By hand) each paragraph of the Scrum Guide and after the paragraph, I wrote down my understanding of what was being said. I even went another step further and started writing out from a skeptic’s point of view (as best I could) why certain practices would not work. I based these on what I have heard from other skeptics and I also tried to put my mindset in that mode. This I must admit was difficult at times as some of my skepticism didn’t really make sense.But the mere voicing it out I think was a benefit. I would then counteract if I found it was needed.

Now I only got half way through the Scrum Guide before I decided to take the test, but this did help with understanding. The “writing” actually allowed my reading to slow down rather than typing and my thoughts could gather around what is being said.

Books

Another thing I did was listen to Jeff Sutherlands book “Scrum, do twice the work in half the time”. The book goes through from Jeff’s perspective how he developed Scrum. More importantly, the reasons behind the practices. This I found important as it gives a basis as to why certain things in Scrum are done that way.

Another book I read was “Scrum And XP From The Trenches” written by Henrik Kniberg. This is a free book that goes through Henrik’s experiences in implementing Scrum and XP. this can give a practical perspective.

Practice Exams

The last thing I did was do a lot of practice exams.

I started with the Open Assessment provided by Scrum.org. This is about 30 questions to be done in 30 minutes.

The first time I did this practice test, I think I got 60 something percent. A failure, but as you lean, keep re-doing the test. Soon you get 100% each time.

The problem is that the questions get repetitive and you start knowing the answers without knowing the actual context. This should be avoided. When you get a question right or wrong, understand why.

The other practice exam I did was Mikhail Lapshin’s practice exam. This practice exam has 2 modes. The first is the Learning Mode where as you answer the questions, you get told if you were correct or not straight away. Then the reasons for the answer.

The second mode is the actual exam mode where you answer 80 questions in an hour.

A few days before I started doing the PSM exam, I would do this practice test on the train on the way to and from work.

Now, these 2 practice assessments, I would repeat to the point where I could do the Open Assessment in 5 minutes with a 100% pass mark, and Mikhail’s practice exam within 15 minutes with a pass mark of 100% also. Any question I would get wrong, I would try to understand why. Even if it was a silly mistake. Go back to the Scrum Guide and find the section where the topic is covered and re-read.

The final practice exam I did was the TestAhoy exam. This exam I left to the last week before taking the test. This I saved to check how I would go. That way the questions would be some way of a surprise. I actually did this exam the afternoon before I was going to take the test. I took the test that evening around 9PM when all was quiet.

Finally, a few days before you plan on taking the test, read and re-read the Scrum Guide.

Finally

Now, when I decided I was actually going to take the test, I had it in my mind that it would not matter if I failed. I would say to myself that it would not matter, it’s no big deal. Just try again. I was trying to calm my nerves. I think it helped a little, but I was still nervous, and then got a little careless. Once I completed the test (in a little over 30 minutes) I didn’t bother reviewing my answers. I just hit submit and let what will be will be. Thinking back, I’m not sure if this was a good or bad thing to do. If I start reviewing, would I change my answers? Would I second guess myself? Would I have got more correct answers? I will never know, but I did pass with low 90’s score. The frustrating thing is that you only get told the sections you did not do well in. You do not find out what questions you got wrong,  or their correct answers. Why would you, it is an exam. But it is still frustrating. At least for me.

So, if you decide to go and do your PSM 1 Certification, good luck and I hope this guide was helpful.

This post first appeared on DZone Agile Spotlight. Its original title was “What is an Agile Retrospective” and was entered as part of the DZone bounty competition.

The first time that a lot of teams do (and what my team did when they had their retrospectives after they tried to implement Scrum or any agile process) is try to answer the following questions:

• What went well during the sprint?
• What didn’t go well?
• What can we do to improve?

We would go around the room. Each person answering the question if they wanted to. To mix it up, the manager would elicit responses, note the responses down, and then move on. The whole process took about 15-30 minutes at most and was completely USELESS!

What we did then was go by the letter of what a retrospective was, not by what its intent was.

So, What Really is an Agile Retrospective?

The retrospective is a time to reflect on the past work that has been done, and through self-assessment, determine how things went and how they can be improved. The above 3 questions may always be asked (not necessarily in the one sitting), but it is why they are asked that is as important as to how they are asked to get the most benefit from them. The goal of the retrospective is to have an action plan in place to try to improve productivity in the next iteration. I say “try” because the action plan is an experiment. Through the implementation of it in the next iteration do we determine whether or not the action plan is successful.

What Went Well?

Part of a retrospective is to look at what went well during a sprint. This serves 2 purposes:

• The first is to celebrate your success. No matter how large or small, you did something good and it should be acknowledged.
• The second is to see if this success can be replicated in other areas. Also, can it be sustained?

I recently completed a Scrum project. Now, we are a BAU (Business As Usual) team, where we mainly take care of systems rather than development, but during a recent project, it was decided to use Scrum. It was the first Scrum project for this team. For the final retrospective, one of the things I wanted the team to reflect on was, what practice could the team bring back from the Scrum project into their BAU work?

What Didn’t Go So Well?

This means “to acknowledge one’s own mistake and pledge improvement.”

One portion of the retrospective is a bit like this. When done properly, Agile uncovers problems. Problems may be small, problems may be large, but part of the retrospective is to acknowledge those problems and find ways to resolve them.

In western culture, even though it isn’t really said, mistakes are seen as a failure. They are seen as bad. So, they either get ignored, stigmatized (through blame and ridicule), or worked around. Very rarely are they directly addressed, and only then is it done so begrudgingly. Yes, all systems have problems, but it’s how you deal with those problems that is important.

One method I like to bring up to help answer the question of what didn’t go so well is to spend about 10 minutes letting the team throw out anything they didn’t like during the sprint. One example could be that planning didn’t go so well. Another could be that the sprint felt hectic. There were too many interruptions. The deployment failed. Tests failed. Anything and everything are fair game.

The next thing I like to do is have the team prioritize the top 3-5 problems and then explore what the root cause was. Based on that root cause, we brainstorm what can be done to try and determine a fix. And finally, one of the important results of the retrospective, we map out an action plan to alleviate the issue. I only focus on 3-5 problems and make sure that they are in distinctly separate segments of the development cycle simply because focusing on any more than that starts to become too much for the team to handle. You will also find that several problems have a common root cause.

For the action plan, there must be at least 1 action that needs to be done in the next sprint, but no more than 3. Any more than that, and again it is too much for the team to handle.

What Can be Improved?

The final question asked is to try to look at what you did during the sprint and see if there is a better way to do it. Improvements can be in the form of automation of tasks, or trying a different method or a different development language. It can also be as simple as explaining something a little better.

For improvements, I like to use the lean methods of eliminating waste where waste is:

• Defect
• Overproduction
• Waiting
• Non-utilized talent
• Transportation
• Inventory
• Motion
• Extra Processes

If a suggested improvement actually increases one of these wastes, it really needs to be justified.

Other Things to be Taken Into Account

An agile retrospective can take other considerations into account that help improve productivity. These can be the level of happiness of the team. A happy team is a productive team. The amount of learning the team has made during the last iteration is one example to look at the productivity level. There are many methods to do a retrospective. I’ll include some resources at the end of this article.

Rules

Within Scrum, a retrospective should take no more than 3 hours for a 1-month sprint. For shorter sprints, the time allocated should be less. For example, for 2-week sprints, I set the retrospectives to 1 hour 30 minutes maximum. Now, this is specifically for Scrum. For other agile methods, these rules may not apply.

Personally, I have two other mandatory rules:

• No blaming people. This isn’t a witch hunt. We’re all trying to solve problems and not point fingers.
• No excuses. I don’t care if you had to spend 2 days on a production problem and couldn’t do your work. What can we do to prevent the production problem from interfering again?

The final optional rule is:

• No one gets a doughnut until they speak.

This brings me to the final thing that I think should be at a retrospective. Food. The simple act of having food around relaxes the team. It invites discussion. Some Scrum Masters prefer to play icebreaker games. Me, I find that just having the food around helps.

One last note: a retrospective is only useful if the actions brought up during the retrospective are actually acted upon. If they are not, and they just get noted down and filed away, then the meeting itself becomes useless. It is through the actions being implemented that the team improves, and if you do it continuously (Kaizen) your team only keeps getting better.