Agile Only Works For…

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.


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.


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.


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


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.

Let’s Break Down The Silos

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.

7 Things Smart People Don’t Say

Here is an interesting Blog post again from Tenfold.

Its Sales Coaching Advice: 7 Things Smart Salespeople Don’t Say.

I likes this post not because its specific to Sales People, but because its is good advice overall.

The 7 things Smart People Don’t Say are

  1. “It Wasn’t Me” – Don’t pass the blame, or point out other peoples mistakes.  Provide a solution to the problem.
  2. “I Hate This Job” – This is something I need to take heed. You may think it, but don’t say it. Brush your resume off and look for something new. BTW, my linked in profile is here 😉
  3. “He/She Shouldn’t Have Done It Like That” – Analyzing someone else’s performance isn’t bad, but if you have nothing constructive to add, then it takes away morale. In these situations, its better to say nothing at all.
  4. “I’ll Try” – As Yoda says, “Do or do not, there is no Try”. Just give it your best effort.
  5. “This question is probably dumb, but…” – The only stupid question is the one that goes unasked. Also, don’t discourage people from asking questions by saying it is a stupid question. Better they ask and get straight then hold their mouth and be ignorant.
  6. “But that is how we’ve always done it!” – This is one of the most destructive phrases for innovation. It kills ideas. All this phrase does is promote stagnation and mediocrity.
  7. “Life Isn’t Fair” – No kidding. Get over it, under it, around it or straight through it. Try to overcome the problems and challenges.

Again, good advice from our friends at Tenfold.

Technical Difficulties

Apologies for the technical difficulties we had with the site over the last few days.

I decided to install Ruby and it clobbered the site. I didn’t realize until now.

We are back up and running, we haven’t gone away.

Thank you for your patience.



The Fragility of the Scrum Values

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.