The Price Of Leadership

There are many leaders and managers out there that think that the purpose of leadership is to direct people on what they should do. These sorts of leaders think that their job it to tell, and then have their minions follow. To some extent they not only tell their minions what to do, but also how to do it. Now, there is a time and a place for this sort of leadership, but there is a price. The price isn’t necessarily paid by the leader, but by those that are under them.
This is especially true where those “minions” work under positions that require high demand. There have been many studies that show the link between low control and high demand jobs and how unhealthy they are, but a study released in November 2016  linked the demand of the job to the amount of control of the job to the mortality rate.

What it found was that those in high demand, but low control jobs. The type of job where the leader is directing you, there is a 15.4% increase in the mortality rate than those in low control, low demand. The surprising thing found was that those under high demand, but high control, where you have a say in how you work, there is an 34% decrease in the mortality rate. High control leaders are literally killing their people. Not to mention increasing the chances burnout, stress or other unhealthy psychological issues.

I hear you say that the demands on a leader are high too, yes they are, but, so is the control. The price of bad leadership is paid for by not by the leader, but by those under them.
This is not always the case, some people have a high tolerance for no control, others may not. If you combine this with an environment where you cannot discuss issues, openly, where the culture is to hide rather than make open then the higher price is more likely to be paid. Especially if those that are under strain hide it well, then no one at work will know, not until things really boil over, then it may be too late.

I have no doubt that leaders of this type have good intentions. It may be to make sure the work is being done. Make sure that the work is being done right, but the question I ask is “Is it worth the price?”

So how do you give control to those under you while still getting the work done? One answer may be to set the outcome required, the constraints, make them clear, but leave enough wiggle room for those doing the work to do it how they want. Not how you want. Let them make the decisions on how they do the work.Those under you may fail, they may do the wrong thing, but make an environment where the damage is limited.
Let people figure out problems themselves, if they ask for help, don’t take over, give them enough to lead them in the right direction where possible.
This helps those under you learn. They learn to make the right decisions. They learn to do the job better. They work because it benefits them in the form of mastery, they become more engaged This benefits the leader too. No more managing everything, you have more free time. Stuff gets done quicker as people do not have to wait for your input and decisions.

This may be one method, but I suggest thinking through your own way to give your people more control. Dare I say it, include your people in the discussion. Let them help you figure this out.

This is a big step. You yourself are going to fail, your people will stumble, and there will be temptation to go back to controlling everything, it is so much easier to do. It may take months or even years to turn, but the benefits can be worth it. What you had previously was leadership through fear. Those under you feared losing their jobs, peer pressure kept them from speaking out (although it may not have stopped them from talking about you behind your back). What you are building now is leadership built on trust and trust can be hard to gain in this circumstance.

For further reading, I highly recommend:
Turn The Ship Around by L David Marquet
Team of Teams by G Stanley McChrystal
Multipliers by Liz Wiseman
Leaders Eat Last by Simon Sinek

 

The Ignored Parts Of Agile

Some people think that Agile is a process that you follow. You do the stand ups, have the board, ceremonies etc.  Even if you do these things, even if you follow Scrum, Kanban, Lean Software, Crystal, DevOps or whatever, you are only looking at part of it. Even if you follow these procedures to the letter, you are still only looking at part of it.

One of the other parts that gets missed, but is implied in these new ways of working is the psychology. It is the human factor. It is looking at what motivates us to work. What makes us want to do our best, what gives us drive. Then there is the other side, what demotivates us. What makes us unhappy, in a state of despair. What makes us grumble about our work and how we can get away from that and get back to being happy.

I’m not talking about being happy little vegemites (here is the meaning, I’m also one of the few Aussies that doesn’t like Vegemite) mindlessly happily working like we have drunk the Kool Aid, although that is part of it. It is also not working hard because of a strong work ethic, although that is part of it too. A person with a strong work ethic will keep working even if they are not happy with the work. No, this is something that transcends that. It is working for a purpose.

Purpose and Control

For those Gamers out there, you know the situation. You are playing a game, you spend the whole day (or night) playing. Totally consumed, totally unaware of the time. You look up, its day, you look up again it’s night, you look up again and its day again – where did the time go? You are playing with purpose. You want to master the game. If you didn’t want to master the game and the only purpose was to complete it, set the game to “Easy”. You can complete it in no time. Also, you control when, how and what you do in the game – you are constrained by the rules of the game. But you are still in control.

Yes, it’s only a game, but imagine that drive, that motivation being redirected to work. Not through manipulation, but through a shared goal, vision or belief in what you are doing. This is why in the Scrum Guide there is talk about the Sprint Goal, the Product Vision. In Scrum, it is the Product Owner’s job to firstly have that vision and then inspire the development team to have that shared vision. That same goal, the want to be part of something that will make a difference. When a person has an understanding of the overall goal, and where they fit in the goal, how they can help bring about that goal, that change, that vision, then mountains can be moved.
There are many leaders in history that have been able to lead this way for both good, for example Martin Luther King, and Evil, Adolf Hitler to name but two prominent people.

Fight or Flight

The next human factor is one where we want to do better. It is much much easier to just keep things they way they are. Everything is predictable. The way you did something yesterday will be the same way you will do it today. It is generally how modern day management works. Keep things at steady state, limit the variation and all will go smoothly. There is some variation, you change things slightly if the new way is proven. If it sounds like a good idea, and feasible, but doesn’t really change things all that much. This method of working is fine. It gets things done, makes it predictable – generally. Evolution is slow, but still happens.
The problem is that there are some people out there, in the industry that you work in, that are trying to accelerate the work evolution. Not only that, they are doing the equivalent of gene splicing by constantly trying new ways of working. Experimenting constantly. Trying to determine what works, what doesn’t, what is better and then adopting those as their new steady state for the short time before it gets changed yet again. This is one of the ideas behind the “iteration”, but we are talking human factor here, not process or procedure. So how do you get that drive to constantly try new things, get better? One way is through crisis. One way to deal with a crisis is to accept things are going to happen and just live with it or run away. What will be will be. This is not the attitude we want. It is the equivalent of laying down to die.
The other way to get through a crisis is to fight it. Those that fight will try to find a way out of the crisis. When the odds are against them, these type of people try to find unconventional and innovative means to fight back.
In Scrum, this is the Scrum Masters role. To inspire the team to fight back constantly against an enemy that may be a competitor, another team or even themselves. The team must fight back using unconventional and innovative means to get the work done better and quicker. Never to be content with the current situation, or be taken over by the enemy.

Strength

The final human factor I wish to talk about is using people’s strengths. Too often people are brought in to fit roles. Most of the time, these same people can offer much more, just not in the role that they have been placed in. To make things worse, these people are overloaded with work. This invokes a situation that Liz Wiseman in her book Multipliers calls “Over Worked, yet Underutilized”.
This is very demoralizing for a person. I remember a story from 2 second lean, where Paul Akers talks about an engineer who gets an award for 30 years of service. (The details may be sketchy as its from memory). The Engineer sits down and cries. When asked why? He says, “They had the work of my hands for 30 years. They could have had the work of my mind for free”. People have ideas on how to make their work lives easier. Not all of them revolve around them shirking work.
I bought this book Strengths Finder 2.0 a while ago. It comes with a test you can do online. You answer a number of questions honestly otherwise it doesn’t work and you have wasted your money, and based on your responses, it works out what your top 5 strengths are.
Mine are to summarize...
Learner – I like to learn stuff.
Deliberative – I take care of making decisions.
Ideation – I am fascinated by and constantly have ideas
Connectedness – I can find the links between things.
Intellection – I am introspective and appreciate intellectual discussions.
These pretty much sum me up quite nicely. Freakily so.
Another type of test is the Briggs-Myers test. I personally haven’t done this one, but it gives similar responses.
Having team members do these types of tests can help identify their strengths and thus be able put them to use. Since you are utilizing the specific strength of a person, people feel better utilized.

Engagement

A significant number of people who work are not happy with their jobs. If you do a google search on “How many people are disengaged with their jobs” you start to see numbers around the 70% mark. This means you have 70% of your workforce not giving their all. This ultimately affects the bottom line. You can’t order these people to give their all, they need to give it willingly. You could try to compensate with the “Carrot and Stick” approach by giving bonuses, but this only works for a few and only short term. It also disengages people more if the bonus is removed. The only way to get full engagement is by creating an environment where people are inspired to give their all (while taking into account their circumstances such as family, work life balance etc – we are not slave drivers) can only help. Look at the open source community, Wikipedia, etc. people are so inspired that they work for free!
Ignoring the psychology of the people, means people are not as motivated to do their best. Some may have even worked in this situation so long that they may not even know what their best is. The problem arises that more resources will be required. This means more expenditure. It also means that those companies that do do take into account their people get the upper hand over you as they do more with the same amount of people. This. Hold mean that your company’s actual survival may be at stake, which is not good.

The Fish-Bone Diagram

One of the many things that is common between Lean and Agile is that they make problems visible. Most of the time when we as humans see a problem, we look for the most obvious solution and implement that solution. Sometimes, especially with complex problems, the most obvious solution is not the best solution. Sometimes you have to dig deeper to get to the actual root cause.
There are a number of techniques to analyze problems and try to get more information or a better exploration of the issue. The most common is the 5 whys method where you ask “Why” 5 times. Another method which I would like to discuss is the Fishbone diagram, also known as the Cause and Effect diagram.

The fish-bone diagram is a graphical method to view possible causes of the problem. It does not help you solve the problem, only identify potential root causes. You can then experiment to determine the actual root cause and possible solutions.
The diagram gets its name from its shape. It, well, looks like the bones of a fish.
To draw the diagram is quite simple. At the head of the fish is the problem, also known as the undesirable effect. It is better if you phrase the problem as a question rather than a statement. “Why did <problem> happen?” rather than just “Problem”. Sometimes phrasing things as a question gets a better thought process than just a statement. Once you have the head, then you have the spine and from the spine, the ribs which represent the groups of causes. The causes then branch off the ribs.

As you can see, the diagram is quite simple and quickly shows how potential causes relate to one another.

There are two popular brainstorming methods to getting the fishbone diagram.
The first is to brainstorm possible causes and write them down on “Post-It” notes on a wall. Group the post-its together by relationship to one another. Those relationships become the ribs of the diagram.
The second method is to pre label the ribs. An example may be to use “People”, “Process” and “Technology” (You don’t have to have an even number of ribs). This method helps focus on possible causes, but can limit thinking to only within these groups.

Below is a completely fabricated example where the problem/undesirable effect was that a calculation of 2 numbers led to the wrong value.

As you can see, there is no “solution” to the issue. We are just looking at possible reasons as to why the defect occurred.
The next step in the process is to discuss, and analyze the possible causes and then find ways to mitigate them from happening.

The Fish-Bone diagram is a simple but effective method to help view problems in a new light. This can lead to better root cause analysis and innovative solutions.

When do you know you are Agile?

I got to thinking, how do you know when you are agile?  The following is a list I came up with in a brainstorm.

Optimizing the work

This is about getting the most out of the work that is being done. Most of these are covered by Scrum and Kanban frameworks. I consider this to be the start of being Agile, but not the end game.

  • Backlog is in priority order
  • Backlog is groomed regularly so that items can be worked on straight away
    • Items are of a reasonable size
    • Details added, but not details on how to accomplish the task, but the outcome desired
    • Acceptance criteria
    • Discussed with Team
  • Team picks items off backlog/Sprint backlog (self organizes)
    • Items are Not assigned
    • Not grouped by project
    • Everyone works on everything
    • No handovers as not required
  • There is a greater goal to work towards for the Sprint
    • Not just work to get things done, a real goal
  • Ability to change with little to no disruption to flow, although productivity may suffer
    • Eg loss of a team member to a project.
    • On leave
  • Definition of done exists and is adhered to
    • Determined by whole team
  • Team has principles to guide work along with goal
  • Standards change frequently as they improve
    • Standards are not fixed but reviewed and questioned regularly
  • No silos/roles (cross functional)

Improvement and growth

The second important thing that I think when you become Agile is that you take care of your team’s and the members of the team’s ability to grow. You no longer just do the work. You are trying to find ways to increase the skill set of your team. The team itself becomes a learning team. Mistakes are seen as opportunities to see gaps in knowledge and teach.

The team itself becomes a learning team.

  • The Team measures in such a way it can determine if there is improvement
  • Everyone continuously looks are doing things better (continuous improvement as often as possible – daily)
    • Small (save 2 seconds) to large improvement
    • Improving quality
    • Reducing waste including processes.
    • Learn to see/Open mind
    • Optimizing flow
      • Work is done by single piece flow.
      • Improve cycle time
      • Limiting work in progress
        • Getting things done before moving onto the next thing. Ie no multitasking.
          • For this to work, task sizing must be optimal
  • Experimentation encouraged with measurable results
  • Self learning is encouraged
  • Team reflects on the work done regularly
  • Information is shared openly.
    • Team teaches/trains each other
    • Skills and techniques are shared
    • Information is shared
    • Lack of knowledge is seen as an opportunity to teach, not berate
    • If someone doesn’t “get it” change teaching technique. Everyone learns differently
  • I intend… very well. Members do not have to ask permission to do something. They just need to state what they are doing and be trusted to do it. See “Turn the ship around
  • Problems are seen as challenges, not issues
  • Autonomy, mastery and purpose fulfilled

Teamwork and Emotional Stability

The final section is where the Team and its members feel safe to express their differences and those differences are explored rather than suppressed.

  • Team is happy.
  • No blame
  • No fear of failure – fails frequently (means we are pushing the limits, and learns from the failure)
  • Trust within Team
    • Can openly discuss without being shot down
    • No idea killers. Ideas are explored – even the crazy ones
      • Experiment to rule in or out on merit, rather than rash judgements

This is my list of what I think being Agile is. Doing Scrum or Kanban or SAFe or any other framework alone does not make you Agile in my opinion. Learning and having an environment where you can explore, try, fail and discuss is also just as, if not more important. Myself, I am not there yet, but I am trying. It is also possible that this is an impossible goal. That may be so for some organisations, but my thinking is that you need to keep trying. It is the trying that is important, not the achieving.

It is most likely possible that when all the above is achieved, there will be more criteria. This is not suppose to be a list that must be adhered to to say that you are Agile, but a guide to help you get there.

At least in my opinion.

Let me know what you think in the comments.

What Is Emotional Intelligence?

Another guest posting from our friends at Tenfold. This one is on Emotional Intelligence.

Emotional Intelligence (EI) is ones ability to recognize emotions within themselves or within others.  It is the ability to use emotional queues to guide thoughts, behaviors and actions.  Emotional Intelligence is being seen as another form of intelligence and can be measured similar to IQ (Intelligence Quotient) called EQ (Emotional Quotient).

Emotional intelligence was coined in a paper by Michael Belodoch, Clinical Professor of Psychology in Psychiatry at Cornell University. It became a buzzword by Daniel Goleman in his book Emotional Intelligence published in 1995.

In the book, Goleman claims that EI matters more than technical expertise when it comes to job performance and leadership.

I suggest you read the full article on the Tenfold Website.

 

No Post This Week

No post this week as I have written an article that has taken all my time for the Scrum Alliance.

Please keep a look out in a few weeks time for an article on Work Groups and Teams on https://www.scrumalliance.org/community/articles

14 Persuasive Words And Phrases

Here is another interesting post from our friends at Tenfold.

Its an interesting list of 14 words and phrases that can be used to help with a sale, but I think could be used in more general when trying to be persuasive to someone. I’ll have to give it a go in the new year.

Advantage

Show the advantage of your offering over competing offerings, how it can improve and help. People like to gain an edge generally. You need to show the value and back it up with case studies or statistics.

Amazing

Everyone wants to be amazed. The word tugs on the emotional strings and encourages action. People don’t generally want something ‘good’, they want something that will ‘wow’ them, especially if they are paying a premium. But remember not to oversell it. Its better to under promise and overachieve then over promise and over achieve. So use the word sparingly.

Avoid

There is always something people try to avoid. Be it loss, complexity, the unknown or trouble. We want to avoid risk. So show how risk can be avoided. People are more interested if you can show protection against going backwards from the status quo.

Because

This is an interesting one. An experiment (See the post on Tenfold for the link) was done where the experimented wanted to use a copy machine first to make copies for himself before the person who wanted to use the machine at the time.

The experimented made a request using 1 of 3 scripts.

  1. Excuse me, I have 5 pages. May I use the photo copier?
  2. Excuse me, I have 5 pages. May I use the photo copier, because I have to make copies?
  3. Excuse me, I have 5 pages, May I use the photo copier, because I’m in a rush?

With the first line, they got 60% compliance. With the second, they got 93% compliance with the request, and with the third line, they got 94%. The study concluded that the word ‘because’ was the key differentiator in getting a stranger to comply with the request. The mere fact that a reason was conveyed, even if no information was given is enough to receive a specific outcome.

First

People love new things, and having exclusivity can grab peoples attention. The first look at a new product. Just look at how much interest rumors of  the new iPhone spread. If someone believes that being first is in their advantage, they are likely to listen.

Fix

People want solutions to their problems,, When you suggest you have a “fix” for their issue, you can have a captive audience. But remember, in order for them to have loyalty, you need to live up to their expectations, otherwise things can backfire.

Free

Dan Ariely insists that zero has a special price. People become more interested in free. They just have to have it. I’m no exception. I have a Udemy account full of free courses. Most of which I probably will never get around to starting, yet alone completing. But I must have them – just in case. Free gives a no or little risk option, so why not grab it – just in case.

I don’t know

I lot of people try to avoid this phrase. I know that I was taught never to say this phrase, but being honest and simply saying “I don’t know” can be used to build trust for the simple reason you are being honest rather than trying to guess or make something up. Simply admitting although sometimes embarrassing, that you have a gap in your knowledge eliminates the risk of having to backpedal on your words at a later point if you are wrong.

Imagine

If someone has an understanding on how they will implement something, they will be more likely to agree to having or using that something rather than not. If you imagine the need for something, you are more likely to want it rather than be persuaded if you don’t.

Now

Everyone wants something sooner. Time is too short to wait. By creating a sense of urgency without aggressive pressure, people are more likely to agree sooner rather than weeks or months later.

Just by simply asking for example “What would you do if you had this now?” or similar, you are planting the seed of urgency.

Save

Everyone is cost conscious. So, showing how you can save money, save time or trouble can be seen as a win for the person. This can be similar to “Free”

Simple

When you think of simple, you think that there is a small or non-existent learning curve. When it is simple, people are more open to the idea, but be careful if there is a sting. For example, Scrum is simple to Understand – but difficult to Master.

Unusual

Sometimes people want to try something different. Some on the other hand do not like to deviate from the status quo. A lot of people like to show their individuality, if you show them how they would be different to the rest, some people are willing to listen.

We

We is a very powerful word. It shows that we are all in the same situation. We share the same, we are together. It puts in a team oriented mindset. Other words like “our”, “together” and “us” also have the same meaning.

Words like “I” or “Your” or “You” take on an adversarial structure. “You should do this” for example. This invites aggression type tendencies back making it hard to be more persuasive.

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.

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.

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.

Thoughts, Tutorials and Learnings specifically with regards to Agile, DevOps and SOA/EAI